Titre de l'exposé : OCaml: pourquoi c'est (presque ;-) le meilleur langage du monde.
Comme on peut le deviner, l'exposé sera parfaitement objectif. :) Plus sérieusement, j'essayerai de présenter les points forts et faibles de cet excellent langage.
Aller plus loin
- Gulliver (3 clics)
- MCE (3 clics)
- Plan pour venir (1 clic)
- OCaml (2 clics)
# Pérénité
Posté par Sytoka Modon (site web personnel) . Évalué à 3.
- Pérennité du langage ? Je me souviens d'un super langage (Sather) qui est mort, si je me souviens bien, parce qu'on a coupé les crédits à l'équipe universitaire qui le développait. Quid de OCaml à l'INRIA ? Et dans la même veine, quel est l'intérêt pour l'INRIA de développer OCaml ?
- Autre aspect, la grande force de Perl (et de TeX) est à mon avis le CPAN. Pas besoin de chercher midi à quatorze heure, tout est sur le CPAN. Je ne comprends pas pourquoi les autres langages ne font pas de même. Ce n'est pas la place disque et un serveur qui doivent manquer à l'INRIA. Je sais qu'il y a un embryon de base commune pour OCaml mais ca n'a rien à voir avec un CPAN où tous les fichiers sont sur le même serveur.
A mon humble avis, l'absence d'un équivalent CPAN est rédhibitoire. Certes, des langages comme Python ou php se développe mais c'est "grâce" au lacune de Perl ;-)
[^] # Re: Pérénité
Posté par Anonyme . Évalué à 1.
"Il est développé et distribué par l'INRIA depuis 1985."
donc 20 ans cette année ... La communauté existe et les applications developpées en caml sont assez nombreuses (une petite recherche sur le web pour t'en convaincre). De plus il est beaucoup utilisé par l'enseignement en informatique. A titre d'exemple mldonkey est ecrit en caml.
Pour le CPAN, je te repondrais simplement que la distribution complete de caml contient deja presque tout. Si tu y ajoutes la documentation tres bien faite, tu obtiens un environnement de developpement tres complet. Mais c'est vrai qu'une base equivalente serait un veritable plus.
[^] # Re: Pérénité
Posté par Croconux . Évalué à 1.
OCaml a fait assez peu parler de lui en 20 ans, un peu comme hurd dirons certains...
La communauté existe et les applications developpées en caml sont assez nombreuses
Je n'en ai pas trouvé beaucoup. C'est sans doute du au fait que Caml oblige à penser différemment. C++, Java, C#, tout ça se ressemble. Quand on a touché à l'un on passe sans problème à un autre langage. Caml est vraiment différent. La façon de coder ressemble plus à un énoncé mathématique. Les matheux purs adorent, les informaticiens n'arrivent pas à s'y faire. En général quand on cherche à sortir un truc sensé changer la face du monde mais totalement différent de tout ce qui existe on se prend un bide.
De plus il est beaucoup utilisé par l'enseignement en informatique
C'est à peu près le seul endroit ou j'ai pu croiser du Caml. Et encore, j'ai eu des profs de l'Inria...
[^] # Re: Pérénité
Posté par gph . Évalué à 1.
Tu as vu ca ou?
Moi j'avais lu de très bon compartif avec d'autres langages (enfin implémentation) sur Ocaml.
Je n'en ai pas trouvé beaucoup. C'est sans doute du au fait que Caml oblige à penser différemment. C++, Java, C#, tout ça se ressemble
Oui c'est comme programmer en Java t'oblige à penser différemment que programmer en C (objets vs impératif pur.)
Les matheux purs adorent, les informaticiens n'arrivent pas à s'y faire. En général quand on cherche à sortir un truc sensé changer la face du monde mais totalement différent de tout ce qui existe on se prend un bide.
Je ne suis pas d'accord du tout avec toi, les informaticiens adorent. En tout cas les gens qui font de la recherche en informatique ont tendance à aimer ce langage. De plus comme tu le dis le langage étant assez proche des mathèmatiques, ce qui est pratique pour les chercheurs: ça permet de mettre en oeuvre facilement leurs solutions.
Je vais prendre un exemple: je suis élève à l'ENAC, et au labos d'informatique de l'école, tout est developpé en OCaml. Ca va de programme de simulation de trafic et de résolution de conflit, à un drone écrit par deux personnes de l'ENAC en partie en OCaml.
C'est sur que c'est un langage moins utilisé que le C, mais il est performant et convient très bien au besoin de chercheurs, donc je pense qu'il n'est pas pret de partir à la trappe comme tu sembles le dire.
[^] # Re: Pérénité
Posté par fmaz fmaz . Évalué à 3.
Pas le choix, c'était OCAML imposé. Il y a eu un tolé général:« c'est
quoi ce langage que personne ne connait! Nous, on veut être
crédible au près des boites, on veut du C++, du JAVA... »
La prof a tenu bon. Trois mois plus tard, quasiment toute le module
trouvait qu'OCAML roxositationnait des maman ou et même des papa
ours, ta mère en short.
OCAML est vraiment un bon langage. Son principal problème est
fonctionnel et que les informaticiens sont plus habitué au paradigme
impératif. Ceci dit, c'est justement très bien qu'on impose ce genre
de langage dans les cursus universitaires. C'est beaucoup plus
important pour former un gars polyvalent que de lui apprendre
C, C++, Java, Basic, Pascal, Cobol...
[^] # Re: Pérénité
Posté par Stéphane Traumat (site web personnel) . Évalué à 3.
Sauf le perl... ca j'y arrive pas.. Mais ca doit etre un truc dans mes genes
http://about.me/straumat
[^] # Re: Pérénité
Posté par fmaz fmaz . Évalué à 2.
impératif (par exemple le C), tu peux rapidement être opérationnel
sur n'importe quel langage impératif.
La situation est semblable avec les autres paradigmes de
programmation.
De ce point de vue, je pense qu'il est bien de montrer à des étudiants
qu'il existe des langages fonctionnels, logiques, à poil raz.
Messieurs Turing et Church étant passé par là, on peut tout faire en
COBOL. Ceci dit, il peut être intelligent de ne pas TOUT faire en COBOL
(même si on adore COBOL et qu'on le connait par coeur).
Par exemple, un langage fonctionnel comme OCAML est très pratique
pour écrire un interpréteur ou un compilo.
[^] # Re: Pérénité
Posté par Philippe F (site web personnel) . Évalué à 2.
Genre un jour, tu vas tomber sur un projet. Tu vas commencer a te prendre la tete avec des objets et de l'heritage et tout d'un coup, l'illumation te viendra: c'est un probleme qui doit se resoudre avec une approche beaucoup plus fonctionelle. Meme si tu codes au final la solution en C++, tu utiliseras des techniques de programmation fonctionelle qui te donneront une solution plus elegante qu'une solution en style objet.
C'est pour ca que c'est important d'avoir touche a OCaml.
Si tu vas voir la page du "Great Language Shootout", tu verras que OCaml a le meilleur score dans de nombreuses configurations.
Meme si je n'en ai pas fait beaucoup, ce que j'ai aime dans ce langage, c'est l'inference de type. Alors que python introduit des bugs subtils et indectables par sa resolution dynamique des attributs, OCaml a une approche hyper clean qui te permet de trouver des problemes subtils tres tot dans le cycle de dev. Et surtout, il ne te force pas la main sur les types (contrairement au C++ ou a Ada ou tu dois vraiment _tout_ dire) mais se debrouille lui-meme pour deduire des infos que tu lui as fourni, les types qui sont utilises.
[^] # Re: Pérénité
Posté par reno . Évalué à 2.
OCaml a aussi un probleme de syntaxe: par défaut sa syntaxe est assez pourri..
J'avais essayé d'apprendre ce language, mais j'ai abandonné car Ocaml c'est quand même assez bof-bof au niveau syntaxe.
Je ne dois pas être le seul a leur avoir fait la remarque, apparemment il y a une syntaxe "alternative" possible, mais j'ai découvert Ruby entre temps et je n'ai donc pas regarder à quoi ça correspond..
[^] # Re: Pérénité
Posté par Anonyme . Évalué à 1.
[^] # Re: Pérénité
Posté par Anonyme . Évalué à 2.
Je connais des craques en C qui ont mis plusieurs semaines a ecrire un interpreteur alors qu'avec des langages de plus haut niveau (dont Caml, mais aussi ruby, prolog voir meme perl ou python) cela ne leur aurait pris que quelques heures ...
Je pense que tu confonds deux choses : La connaissance d'un langage et la connaissance de paradigmes. Cela ne sert strictement a rien de passer sa scolarité a apprendre un langage particulier sous pretexte que c'est ce langage qui est utilisé dans l'industrie. Au contraire, mieux vaut survoler a peu pres tous les langages. Cela te donnera une ouverture d'esprit et te permettras de faire les bons choix.
A titre d'exemple je n'ai eu que 1 mois de TP sur le C et un cours sur le C++. Cela ne ma pas empeché de faire des stages et plus tard d'etre employé par des sociétés ne developpant que dans ces langages.
[^] # Re: Pérénité
Posté par Philippe F (site web personnel) . Évalué à 1.
Si tu n'as fait que survoler du C++, j'espere que quand tu as commence ton stage, tu t'es achete un bon bouquin et tu as comble tes lacunes.
Pour citer un exemple, j'ai fait passer des entretiens a des stagiaires qui avaient fait du C++ mais pas de C, ou bien du C++ mais pas de pointeurs. Ca me parait tres tres limite et je ne comprends pas trop le raisonnement de leur prof. Si ils veulent leur eviter les pointeurs, qu'il leur fassent faire du Java.
[^] # Re: Pérénité
Posté par reno . Évalué à 1.
Survoler un language, c'est bien, je l'ai fait aussi (Lisp, Prolog) à l'époque mais il vaut quand même se batir une "culture" sur un language utilisé: je n'ai jamais utilisé ni Lisp, ni Prolog, et je ne pense pas jamais les utiliser alors à part savoir qu'ils existent bof..
Pour ce qui est d'écrire des interpréteurs en C, je l'ai fait aussi, pourquoi?
Je n'avais pas le choix du language! Donc les languages exotiques, c'est bien, mais ça reste peu connu et donc peu utilisable.
Dans mon projet actuel, j'ai bien essayé de vendre Ruby, mais trop peu répandu --> shell + C.
[^] # Re: Pérénité
Posté par Olivier Grisel (site web personnel) . Évalué à 2.
Je ne connais pas bien CPAN donc je ne peux pas te dire si c'est equivalent mais il existe une distribution source et cross plateforme (Linux, Solaris, FreeBSD, NetBSD, Cygwin, HP-UX, MacOS X) de OCaml et de ses principales bibliothèques : GODI
http://godi.ocaml-programming.de/(...)
Ca marche super bien. C'est basé sur le système des ports bsd. Y a deja pas mal de paquets dispo mais de nouveaux packagers sont les bienvenus.
http://godi.ocaml-programming.de/toc/toc-3.08.html(...)
Si on ne veut pas passer par GODI, debian/ubuntu est de loin la meilleur distrib en terme de pacquets pour OCaml.
[^] # Re: Pérénité
Posté par Sytoka Modon (site web personnel) . Évalué à 2.
http://www.cpan.org/
C'est pas du tout pareil que le reste. Il y a TOUT, tout et tout. Tout le monde peut mettre son module, ses sources. Bref TOUT.
Dans les autres langages, il faut aller piocher ici ou là les infos. Les sites web vont et viennent, les versions aussi. C'est pas fiable en général.
On me dis que la distribution OCaml a déjà beaucoup de chose, je suis d'accord. En pratique, il manque toujours quelques choses ;-) Là est l'intérêt d'un CPAN, toute nouvelle classe, module, bibliotheque... faisant partie d'un programme peut y être intégré dans l'espace de nom commun à tout le monde et être utilisé par la suite par d'autres projets.
Le CPAN, c'est quelques "main" et des milliers de modules. C'est relativement anarchique : un espace de nom est affecte au premier qui le prend mais n'importe qui peut le completer. En pratique, cela marche tres bien et les bons modules ont des espaces de nom tout a fait correct.
[^] # Re: Pérénité
Posté par Nicolas Chapin . Évalué à 1.
Un langage se développe principalement par l'effet marketing (voir Java et .Net) et le fait que les programmeurs ne veulent pas sortir de leur zone de confort.
Mais dans une vrai approche d'ingéneirie on défini d'abord ce que l'on veut (Le besoin et les contraintes ) et comment on va le faire (la technique) et le langage utilisé doit donc être choisi en fonction:
* du besoin qu'il adresse (PHP permet de créer rapidement et facilement des sites dynamiques, C est proche du matériel donc convient pour le développement Système, Erlang pour de la forte concurrence).
* La facilité et les métaphores qu'ils proposent (assembleur, procédural, objet, fonctionnel).
* Un framework puissant (CPAN pour perl, Bibliothèques C, package Java).
De ce point de vue OCaml est à mon avis l'un des meilleurs langages du moment:
* C'est un langage de type fonctionel avec de jolis concepts
- Induction des types
- Fonctions d'ordre supérieur (on peut passer des fonctions en paramètres à des fonctions)
- Filtrage par motif
- j'en passe et des meilleurs
* Il y a un bon framework
* Il réponds à la pluspart des besoins
Un bonne example et celui de Paul Graham et de l'utilisation de Lisp pour coder un moteur de magazin online (Racheté depuis par Yahoo!):
http://www.paulgraham.com/avg.html(...)
[^] # Re: Pérénité
Posté par Sytoka Modon (site web personnel) . Évalué à 1.
De plus, OCaml et Perl ne joue pas dans la même cour du tout... J'ai toujours entendus beaucoup de bien d'OCaml, et j'utilise l'excelent programme unison, mais je n'ai quand même pas l'impression qu'il décolle.
J'entend aussi beaucoup de bien d'Haskell. Quelqu'un connais les + et les - des deux. Je crois que ce sont tous les deux des enfants de ML ?
Enfin, contrairement à l'un des post ci-dessus, vu l'état de l'INRIA (et du CNRS et de toutes les EPST...), je n'ai pas absolument confiance dans sa pérennité. Si l'INRIA décidait d'arréter, cela gènerait'il vraiment beaucoup de monde ?
Qu'est ce qui motive l'INRIA dans OCaml ?
[^] # Haskell VS OCaml
Posté par brouillon . Évalué à 2.
leurs differences sont profondes.
- OCaml est un langage fonctionnel à évaluation stricte et possède par la même occasion des traits impératifs. Le fait que celui-ci melange les deux approche, le rend particulierement agreable à utiliser, on a les avantages des fonctions d'ordre superieurs et du moteur d'inference de type avec la simplicité de la programmation impérative (que certains trouverons plus naturel et plus simple).
- Haskell est un langage fonctionnel à évaluation paresseuse qui lui ne possede "aucun" aspect impératif. En theorie il ne possede donc aucune des caractéristiques presente sur une machine VonNeuman (pas d'allocation, pas de structure de controle de l'execution...). En cela on dit souvent que c'est un langage fonctionnel "pur". Ces aspects le rende assez difficile au premier abord, voir rebuterons même les plus motivés. C'est essenciellement un langage de recherche, même si il commence à être utilisable dans le cas d'application plus courante.
[^] # Re: Pérénité
Posté par David Mentré (site web personnel) . Évalué à 1.
Haskell fait du fonctionnel pure. C'est très séduisant car on peut raisonner sur les programmes. En pratique, Haskell est plus lent qu'OCaml, mais pas au point que ce soit inutilisable. Au niveau langage, chacun des deux a ses spécificités, après c'est à chaque programmeur de dire ce qu'il préfère.
Tu veux dire : qu'est qui motive les développeurs d'OCaml à continuer ? Ben c'est leur bébé. Et ces derniers temps, ça va plutôt bien pour OCaml. Evidemment, sur 30 ans, on ne sait pas si le langage sera toujours là. Mais dans 30 ans, fera-t-on toujours du Java ou du C ? (pour le C oui, vu le passif... :-)
[^] # Re: Pérénité
Posté par Ontologia (site web personnel) . Évalué à 2.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Pérénité
Posté par Stéphane Traumat (site web personnel) . Évalué à 2.
Pkoi choisir ocaml plutot que Java ? est ce que j'ai mon hibernate, mon junit, mon struts... ?
Comment j'attaque les bases du marché ? ldap ?
Je ne crois pas que tout soit marketing
http://about.me/straumat
[^] # Re: Pérénité
Posté par Nicolas Chapin . Évalué à 1.
Java ou Hibernate?
Java ou JUnit?
Java ou Struts?
Tout ces projets on été développé parce qu'en premier Java a bénéficié de la force de frappe marketing de Sun. Idem pour .Net
Maintenant imagine que l'INRIA ait disposé de la même force et au lieu d'un langage apprécié seulement des universitaires et des hardcore hackers tu aurais une plateforme qui poutre les nounours (ce qui est déjà le cas, cf. caml humps) largement diffusée.
Je n'ai pas dit que Java et C# (.net n'est pas un langage mais un framework) sont de mauvais langages (Quoique ... :) mais là on tombe dans le troll), mais grâce à la puissance de frappe de leur créateur, ils ont pu attirer une communauté qui a ensuite développé tout un framework autour.
[^] # Re: Pérénité
Posté par Stéphane Traumat (site web personnel) . Évalué à 3.
Mais voila, un langage ne se juge pas qu'à ca.
http://about.me/straumat
[^] # CPAN?
Posté par Tobu . Évalué à 2.
Ce site regroupe par type, thème, license quelques centaines de bibliothèques, bindings, applications, extensions du langage avec les mises à jour.
A noter qu'il est dans la majorité des cas très facile de faire appel à des bibliothèques C: j'ai jeté un ½il aux bindings vorbis, chaque fonction C est enrobée en 5 à 10 lignes triviales pour avoir une fonction caml.
[^] # Re: CPAN?
Posté par tgl . Évalué à 3.
> des bibliothèques C: j'ai jeté un ½il aux bindings vorbis, chaque
> fonction C est enrobée en 5 à 10 lignes triviales pour avoir une
> fonction caml.
OCaml fait aussi partie des langages de sortie de SWIG, et donc ces quelques lignes sont potentiellement générables de façon quasi automatique (même si les quelques bindings OCaml que j'ai croisé jusqu'ici ont plutôt l'air d'être écrits à la main).
# transparents
Posté par hugo_lec . Évalué à 3.
[^] # Re: transparents
Posté par David Mentré (site web personnel) . Évalué à 4.
http://www.linux-france.org/~dmentre/gulliver/expose-ocaml-2005-04-(...)
[^] # Re: transparents
Posté par Lucas Bonnet . Évalué à 1.
Merci, je me contenterai du PDF pour aujourd'hui :)
[^] # Re: transparents
Posté par Olivier Faurax (site web personnel) . Évalué à 1.
http://www.linux-france.org/~dmentre/gulliver/presentations/expose-ocaml-2005-04-07/
# Lent ?
Posté par Nicolas Boulay (site web personnel) . Évalué à 1.
"La première sécurité est la liberté"
[^] # Re: Lent ?
Posté par brouillon . Évalué à 2.
Le revers de la médaille c'est que tu programme à très bas niveau et qu'a ce titre
tu a à te preoccuper de détail dont dans une très grande majorité des cas tu aimerai
ne pas avoir à gerer. Ainsi il ne faut pas s'etonner du nombre de buffer overflow
issue de certain programme en C (ou autre) par rapport à d'autre ecrit en Java.
Donc dire que OCaml est derrière le C en terme de vitesse n'est pas clair. Qu'est ce qui est plus rapide en C qu'en OCaml ? De mon avis, on est par exemple beaucoup plus rapide à ecrire un programme en OCaml qu'en C.
Et puis il suffit de gouter au systeme de typage à la ML pour comprendre le plaisir
que l'on peut avoir à coder en OCaml.
Si Ocaml est encore derriere le C en terme de performence dans le cas d'application
tres pointues, cest parceque par ailleur il offre un confort d'utilisation sans commune mesure vis a vis de celui ci, et que ce confort passe a travers l'utilisation d'un machine virtuelle qui naturellement prend des resources.
[^] # Re: Lent ?
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
Pour la rapitdité de dev, je pense plus à perl qu'à ocaml :)
Vu le niveau d'abstraction, le compilo d'ocaml pourrait faire des choses impossible ou difficile en C comme le controle du layout mémoire ou l'utilisation du SIMD.
"La première sécurité est la liberté"
[^] # Re: Lent ?
Posté par David Mentré (site web personnel) . Évalué à 1.
J'ai découvert OCaml en 2e année de thèse. A l'époque, je faisais un logiciel de traitement symbolique et je l'avais commencé en Perl. Au-delà de 1.000 lignes, Perl est une vraie daube(tm) : un cauchemar pour faire de la programmation claire (le moto : "y'a toujours un comportement par défaut" de Perl devient très vite ingérable. Le programme tourne mais ne fait jamais ce que l'on veut).
J'ai commencé OCaml en lisant le bouquin de Leroy et Weis sur la plage, pendant mes vacances. En revenant, j'ai codé direct la nouvelle version : depuis, je suis un fan d'OCaml. Je trouve que mon code est clair, bien structuré et efficace. Et tu limites pas mal de bug par construction.
Evidemment, pour un petit script de vérif de sortie de brochage d'un FPGA par rapport à un logiciel de CAO, je sort mon Perl. Mais dès que je veux faire un programme, c'est à dire quelque chose de structuré qui doit durer, je ne vois pas mieux qu'OCaml (suivant les cas, cf. mon exposé).
Si je me souviens bien, OCaml fait quelques siouxeries sur IA64. Quand au contrôle du layout mémoire, c'est LE point sur lequel je voudrais qu'OCaml progresse. Mais j'ai pas encore les idées claires sur ce qu'il faudrait faire.
[^] # Re: Lent ?
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
La mémoire dispose d'un grand nombre de "multiple" (taille de write buffer, ligne de cache L1, L2, page mémoire de 4 ko et 4 Mo). On peut aussi tenir compte de l'associativité des caches et donc de l'aliasing des adresses mémoire dans les bits lsb d'adresses.
Tu peux déjà aligner les adresses mémoires avec l'utilisation qui est en faite (genre trier les élements d'un struct en fonction de l'utilisation de ses champs). Jouer avec le preload et le prefetch pourrait aussi améliorer les choses. Et augmenter la localité d'acces.
"La première sécurité est la liberté"
[^] # Re: Lent ?
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
"La première sécurité est la liberté"
[^] # Re: Lent ?
Posté par Sebastien (site web personnel) . Évalué à -2.
AHAHAHAHAHAHAH
C'est bon de rire parfois.
Si c'est pour faire de l'objet, sans avoir à pousser le masochisme jusqu'à OCaml, il y a toujours Python et Ruby.
seb.
[^] # Re: Lent ?
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
"La première sécurité est la liberté"
[^] # Re: Lent ?
Posté par Tobu . Évalué à 3.
let print_obj a = Printf.printf "%s\n" a#to_string;;
D'autre part on peut hériter de classe sans faire un sous-type de ces classes. Par exemple, on peut définir une classe «['a] clonable» avec une méthode clone de type unit -> 'a sans casser le système de types (autre exemple courant: une classe 'comparable').
En java par example, la méthode est de type 'a -> object, et on est obligé d'utiliser un cast avec vérification dynamique du type et risque d'exception.
Les deux gros avantages de ce typage entièrement statique, c'est qu'il n'y a pas de coût en perf (comme pour du C avec des cast statiques) et que l'on évite toute une catégorie de bugs (plus sûr que pas de vérification comme en C et qu'une vérification dynamique comme dans Java, python et les langages dynamiques en général).
[^] # Re: Lent ?
Posté par Sebastien (site web personnel) . Évalué à 0.
Après, dans d'autres langages, on peut aussi passer outre. Typiquement, en Java il "suffit de" faire implémenter aux objets manipulés une interface particulière comprenant les méthodes communes. (l'avantage de cette situation est de permettre d'éviter d'éventuelles erreurs au runtime vu qu'en évitant les cast, on aura vérifié à la compilation les types).
seb.
[^] # Re: Lent ?
Posté par fmaz fmaz . Évalué à 1.
Faut comparer ce qui est comparable.
[^] # Re: Lent ?
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
Java n'est pas compilé en code machine. tu ne peux pas prendre avoir la vitesse du C. Ce n'est pas le cas de Ocaml qui pourrait être plus rapide que le C. Et je ne vois vraiment pas pourquoi je me suis fait moinsé !
"La première sécurité est la liberté"
[^] # Re: Lent ?
Posté par fmaz fmaz . Évalué à 1.
Ceci dit, je n'ai jamais essayé de faire tourner un prog compilé
sur un i386 sur autre chose mais j'imagine que ça doit marcher
sans problèmes.
Maintenant, il existe des compilateurs spécifiques pour obtenir
un code natif pour quelques architectures.
[^] # Re: Lent ?
Posté par Stéphane Traumat (site web personnel) . Évalué à 2.
http://about.me/straumat
[^] # Re: Lent ?
Posté par David Mentré (site web personnel) . Évalué à 1.
Parce que les développeurs d'OCaml ne cherchent pas à faire les super-optimisations de scheduling d'instruction qui permettraient de gratter les quelques cycles manquants en calcul numérique pur.
Parce que OCaml a quand même un ramasse miettes, et qu'il a un surcoût (léger certes, mais surcoût quand même).
Parce qu'un processeur est conçu pour exécuter du C et pas du OCaml. Mais ça ça changera quand on fera nos processeurs libres. ;-)
[^] # Re: Lent ?
Posté par Nicolas Boulay (site web personnel) . Évalué à 3.
Les risc du début des années 80 étaient fait pour le C. Cela remonte un peu aujourd'hui hein...
La croyance veut que l'on gagne qq cycles en optimisation. C'est faux. J'ai "étudié" le code de la multiplication matriciel en entier en C. Entre la version simple de 4 lignes, et la version imbitable de 100, il y a un rapport 4 de vitesses (+400%).
"La première sécurité est la liberté"
[^] # Re: Lent ?
Posté par Tobu . Évalué à 3.
Pour les optimisations algorithmiques, le plus important est d'avoit un langage pratique et concis, pas un langage proche de la machine.
[^] # Re: Lent ?
Posté par Nicolas Boulay (site web personnel) . Évalué à 3.
Je suis d'accord que la multiplication matriciel est un cas particulier mais quand même !
Pour les optimisations algorithmiques, le plus important est d'avoit un langage pratique et concis, pas un langage proche de la machine.
C'est évident ça. C'est ce que je dis au début. Mais pourquoi le langage ne peut pas rester clair et être performant ?
La compilation du C a fait des progres mais des fonctionnalités du C rendent impossible tout une classe d'optimisation, notamment concernant le layout mémoire. Donc le Ocaml étant de plus haut niveau, il est plus facile d'optimiser, donc ocaml devrait produire du code plus rapide que le c.
"La première sécurité est la liberté"
[^] # Re: Lent ?
Posté par Tobu . Évalué à 2.
Avec le système de modules, les types ont une portée limitée, ce qui devrait laisser pas mal de libertés dans ce domaine: pas de contraintes de compatibilité binaire, et on peut faire une analyse du flot d'exécution.
Dans l'idée de modifier aggressivement la gestion de la mémoire à partir d'une analyse statique, il y a ce papier: http://citeseer.ist.psu.edu/reynolds02separation.html(...) (et aussi http://pag.csail.mit.edu/reading-group/tofte94implementation.pdf).(...)
Il mentionne la possibilité de passer la gestion mémoire en statique au lieu d'utiliser un ramasse miettes, ce qui à première vue est incompatible avec les langages fonctionnels. On gagne (un peu) en temps d'exécution du ramasse-miettes, et surtout on utilise moins de place, et on peut mieux tirer parti du cache processeur.
Dans le même genre on parle d'étendre le système de types pour y intégrer une information d'état récupérée par analyse du flot - par exemple marquer qu'une fonction prend des types en accès-concurrent et renvoie le même type en lecture-seule.
Plus concrètement, on peut améliorer certaines structures de données existantes dans des cas précis. Récemment on a une implémentation du module List (hyper utilisé) qui utilise des VListes: http://article.gmane.org/gmane.comp.lang.ocaml.lib.devel/1866(...)
La performance mémoire est meilleure puisque l'on utilise des blocs adjacents de taille importante (la version originale utilisait huit blocs adjacents seulement). La performance en caclul est meilleure aussi puisqu'on fait disparaitre la distinction entre liste et tableau!
[^] # Re: Lent ?
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
L'exemple typique c'est une grosse structure. Les doc AMD/intel préconnise de classé par ordre de taille décroissante les élements d'une structure. Pourquoi ? Parce que le compilo rajoute du padding pour s'aligner sur 32 bits si des char sont mélanger avec des int. La structure augmente donc de tailles. Mais à cause des compilations séparées, un compilo C ne peut pas réarranger l'ordre des éléments.
J'avais fait le teste avec la librairy ffmpeg. Elle utilise une énorme structure à la base. Juste en modifiant l'ordre dans la structure j'avais gagné 2% de perf.
Dans le même ordre d'idée, une fonction d'initialisation pourrait faire les affectations dans l'ordre mémoire de la structure et non l'ordre du code. etc...
La maitrise du layout des données en mémoire permet aussi de pouvoir utiliser des instructions SIMD.
Sinon, ta liste me fait furieusement penser à judy http://docs.hp.com/en/B6841-90001/ch01.html(...)
En gros, c'est des arbres 256-aires plus des astuces pour stoquer des infos de types dans les 3 bits d'adresses non utilisé.
"La première sécurité est la liberté"
[^] # Re: Lent ?
Posté par Tobu . Évalué à 2.
Les VListes sont moins sophistiquées, et adaptées aux listes et aux arrays. En particulier on peut partager un suffixe entre plusieurs listes, nécessaire pour les langages fontionels.
Il y a un bon résumé des techniques d'optimisations liées au typage dans ce papier de Xavier Leroy: http://citeseer.ist.psu.edu/leroy98overview.html(...)
Et plein d'articles ici: http://ropas.kaist.ac.kr/survey/tc/(...)
[^] # Re: Lent ?
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
"La première sécurité est la liberté"
# Calcule numérique
Posté par salvaire . Évalué à 2.
[^] # Re: Calcul numérique
Posté par kjus . Évalué à 1.
http://caml.inria.fr/pub/docs/manual-caml-light/node18.html(...) , par exemple
[^] # Re: Calcul numérique
Posté par salvaire . Évalué à 2.
[^] # Re: Calcul numérique
Posté par David Mentré (site web personnel) . Évalué à 2.
http://www.ffconsultancy.com/products/ocaml_for_scientists/(...)
Sinon, son auteur a fait un email récent comparant OCaml à C++ sur x86 32 et 64 bits. OCaml n'est pas toujours le premier mais pas non plus le dernier. Et ne pas oublier qu'il n'y a pas de mémoire à gérer ! Rien que pour ça...
http://caml.inria.fr/pub/ml-archives/caml-list/2005/03/9aa5c15129d1(...)
# OCaml# ?
Posté par TazForEver . Évalué à 1.
Un peu à la manière de Python/IronPython/Jython, etc.
Ça serait vraiment intéressant je pense.
D'ailleurs, quid de la portabilité ? je parle pas du coeur qui j'imagine est portable, je parle du reste, voir la partie GUI ? existe-t-il des bindings avec des bibliotèques type GTK+ ou tout le fatras de GNOME ?
J'ai bien aimé le coup de 'fais une recherche sur google' ... 'MLdonkey est écrit en OCaml' pour ne citer que lui, et bien presque ! Pour qu'un langage décole, j'ai quand même l'impression qu'il faut une killer-app pour attirer les développeurs. Et je ne parle de la qualité de MLdonkey, qui bouffe beaucoup de temps CPU. Et de mémoire (ça fuit terrible). D'ailleurs, debian propose à l'installation de redémarrer toutes les 24H mldonkey pour éviter une trop grande dégradation des performances...
[^] # Re: OCaml# ?
Posté par Vivi (site web personnel) . Évalué à 1.
il y a F#, une implémentation d'une partie du langage caml pour .NET :
http://research.microsoft.com/projects/ilx/fsharp.aspx(...)
il y a aussi ça : http://www.pps.jussieu.fr/~montela/ocamil/(...)
De manière générale c'est pas super car les autres machines virtuelles ne sont pas trés adaptées aux langages fonctionnels.
existe-t-il des bindings avec des bibliotèques type GTK+ ou tout le fatras de GNOME ?
LablGTK http://wwwfun.kurims.kyoto-u.ac.jp/soft/olabl/lablgtk.html(...) est une interface GTK+ avec des bouts d'autres choses (gnomecanvas, gnome-panel... ). C'est pas mal complet et utilisable.
il faut une killer-app pour attirer les développeurs
mouais, ça dépend aussi à quels développeurs tu t'adresses ... C'est sûr qu'il n'y a pas des masses de clients IRC en caml. Mais les killer-apps sont déjà là : OCaml est trés apprécié et utilisé dans la recherche sur les langages (voir Coq par exemple).
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.