Développeur : Erlang/OTP R11B supporte les architectures multiprocesseur
Posté par Mickaël Rémond (page perso, ). Modéré le 22 mai 2006.
Une nouvelle version de la machine virtuelle Erlang et du canevas de développement a été publiée. Cette version R11B est une avancée majeure, car elle supporte désormais les architectures multiprocesseur. Une même application Erlang peut ainsi bénéficier directement d'amélioration de ses performances sans retoucher son code.
![[en]](../images/en.png)
Erlang (675 hits)-
Nouveautés de la version R11B (267 hits)
-
IBM DeveloperWorks: Concurrent programming with Erlang (295 hits)
-
Planet Erlang (233 hits)
![[fr]](../images/fr.png)
Livre: Erlang programmation (531 hits)-
Définition Wikipédia (1010 hits)
> Lire la dépêche (114 commentaires, moyenne: 3,4).
Vous avez demandé le commentaire #714515.
Run by 
Cette page a été générée par Templeet en 0.0923s (dont 0.0089 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.
Eheh
Ah oui, pardon, excusez-moi de dire des bêtises, le C et le C++ sont des langages préhistoriques, bons pour les dinosaures qui n'ont pas su évoluer, toussa...
C'est d'ailleurs pour ça que l'OS sur lequel vous écrivez ce message est écris en C et pas en erlang/caml/machin-tout-pourrave, de même que le navigateur, le moteur de rendu html, le serveur sur lequel est hébergé linuxfr, les OS des différents routeurs/servers par lesquels passent les messages HTTP, la lib qui encode ce-même http en https, et j'en passe.
A propos de jeux vidéos, c'est aussi pour ça que 99% des jeux vidéos sont écris en C et/ou en C++ (et quand je vois des bouquins sérieux comme les Game Programming Gems, ce n'est généralement pas du 'vrai' C++ mais plutôt du C avec des classes parce qu'il ne faut pas déconner), et surement leurs serveurs avec. Je sais bien qu'il y a des gens qui pensent que 80% de la lourdeur d'un jv vient des accès gc, mais bon...
Je pense que certains théoriciens qu ne pensent qu'à refaire le monde de la programmation à leur sauce parce qu'avant tout le monde il était crétin et que eux on la solution feraient mieux de revenir sur terre.
Je suis de bonne fois, si quelqu'un me sort un OS en erlang/caml avec ses drivers, ses programmes (où un VRAI jeu vidéo), qui soit aussi rapide qu'un OS en C/asm, je ne dis pas que je commencerai à réfléchir un peu, mais en attendant, laissez moi le privilège du doute.
[^]Re: Eheh
Pour ce qui est des jeux et en imaginant que la boite qui produit le moteur de unreal (epic games) puisse etre considerée comme digne d'interet, alors je dirais que le futur des jeux video ne passera pas par le C/C++ mais effectivement pas des langages plus proche de Caml/Haskell/etc ...
Pour ce qui est des kernels, et en considerant que les temps actuels sont au retour des micro-kernel (bon quelque année encore mais les derniers propos de Tannenbaum et les recent travaux de microsoft sur singularity semble aller dans ce sens) alors je dirais que oui oui il se pourrait que hors le micro-kernel proprement dit (qui sera surement en C puisque pour une fois que le C est le langage le plus adapté pour quelque chose, à savoir attaquer le hardware au plus bas niveau) la majorité du noyau (j'englobe tout cette fois ci, systeme de fichier, etc ... ) soit surement dans des langage de plus haut niveau (C#/...)
[^]Re: Eheh
Le Unreal Engine 3 est en C++, non ?
Quand aux kernels, Hurd est en C...
Et jusqu'à preuve du contraire, citer un future échec^W^W^Wproduit Microsoft comme référence sur linuxfr est du plus profond mauvais goût...
Et Tannenbaum est certes très doué, mais reste un théoricien...
[^]Re: Eheh
> Le Unreal Engine 3 est en C++, non ?
Et alors, en quoi ce que j'ai dit te géne ? je me cite
"je dirais que le FUTUR des jeux video ne passera pas par le C/C++"
^^^^
C'est sur je ne dis pas quand, et je ne m'avancerai pas la dessus ;-)
Maintenant je reconnais que j'avais oublié la ref :
http://www.st.cs.uni-sb.de/edu/seminare/2005/advanced-fp/doc(...)
A lire ! tres interessantes remarque sur les contraintes des jeux video et comment epic games y refechit.
> Et jusqu'à preuve du contraire, citer un future
> échec^W^W^Wproduit Microsoft comme référence
> sur linuxfr est du plus profond mauvais goût...
Ce genre de remarque me fais souvent plus pitié que sourir...
Confondre la politique general de microsoft, certain produit (et encore dans l'ensemble il est completement idiot de dire que leurs produits sont pourris, tout au plus certain de leur aspect ne te plaise pas comme le prix mais de la a denigrer systematiquement sans avoir aucun argument) avec ce sur quoi il sont en train de travailler je trouve ca domage.
Peux tu vraiment affirmer que C#/.Net soit un echec.
A mon gout c'est l'un des effort les plus intéressants issue de chez microsoft. Je trouve C# et tout particulierement le futur de celui-ci avec LINQ tout a fait enthousiasmant.
Il est capital que l'industrie informatique aille dans ce sens plutot que dans le tiens et tant pis (ou tant mieux) si ca fait de microsoft.
Maintenant regarde un peu singularity (et SING# comme langage formel de plus bas niveau) et tu pourra être etonné.
[^]Re: Eheh
>> Et jusqu'à preuve du contraire, citer un future
>> échec^W^W^Wproduit Microsoft comme référence
>> sur linuxfr est du plus profond mauvais goût...
Note que singularity est un projet de recherche "pur", ils n'ont même pas encore essayé de vraiment voire le coté compatibilité avec les logiciels existant..
Comment un projet de recherche pourrait être un échec commercial?
>Ce genre de remarque me fais souvent plus pitié que sourir...
Assez d'accord avec ta réponse brouillon, mais pour ce qui est de leurs produits la on n'a pas le même point de vue: leur produit number 1 MSOffice, bien que leur rapportant des sommes indécentes est *pourri*: quand je vois le nombre de documents corrompu, l'interface pénible, etc.
Et la ils n'ont même pas l'excuse des driver.
Pour C#, certes c'est un effort interressant de chez MS, surtout la future v3 d'accord, mais a la base c'est quand même un clone de Java donc pas de quoi non plus s'extasier..
Ce qui est "capital", c'est qu'il y ait enfin des produits fiables en informatique, mais c'est autant (plus AMHA) un probleme de mode de travail que d'outils..
[^]Re: Eheh
Bon sur les produit microsoft et la suite office en particulier, je comprend tout a fait ce que tu veux dire, mais pour ma part je ne me permettrait pas de dire que ce sont des produit *pourri*.
Imaginons un exemple utopique qui ferait que la suite office est gratuite. Pourquoi cette exemple, parceque le prix ou il la commercialise est a mon sens la seule chose veritablement pourri dans cette histoire. Et bien si office etait gratuit, pourrais tu encore te permettre de dire qu'elle est pourri ? Si oui la suite OpenOffice l'est encore plus. Paradoxalement toutes les suites de ce genre seraient aussi pourries les unes que les autres mais n'ayant pas mieux tout le monde s'en servirait !
Donc pour ma part je trouve qu'en dehors du prix, la suite office est quand meme un produit de qualité. (de toute facon je doit reconnaitre que je fait du latex + beamer + gnumeric donc je ne suis peut etre pas tres connaiseeur des faiblesse reel des produit microsoft).
Sur C#, oui il se sont largement inspiré de Java. En même temps Java ne s'etait pas beaucouop genné pour repomper dans d'autre langage. Pour être honnete Sun avec toute sa force commerciale n'a pas fait plus avec Java que reusir à introduire dans le monde de l'industrie des idées et des outils deja connus et utilisés, mais a trop petite echelle.
Depuis l'arrivé de C#, Sun a d'ailleur enfin fait evolué Java, en tout cas un peu plus qu'a l'allure de pacha qu'avant C#. Le coup du boxing unboxing manuel des types primitifs dans des objets etait tout simplement scandaleux. Maintenant on a une belle concurence Java/C# qui amenne à de nombreuses avancés, ce dont je me rejouit pleinement. Mais je continue aussi de penser que C# evolue pieux et plus vite que Java.
[^]Re: Eheh
> Et bien si office etait gratuit, pourrais tu encore te permettre de dire qu'elle est pourri ?
Dans un jugement, le rapport qualité/prix intervient..
> Si oui la suite OpenOffice l'est encore plus.
Possible, je n'utilise pas OOo.
>Paradoxalement toutes les suites de ce genre seraient aussi pourries les unes que les autres mais n'ayant pas mieux tout le monde s'en servirait !
Pourquoi toutes? Le monde ne se résume pas à MSOffice et OOo:
personellement le traitement de texte que j'ai préféré est FrameMaker et je connais peu de personne qui préfére Word à FrameMaker (sauf les experts Words qui apprennent FrameMaker en deuxième), n'empèche que presque personne utilise FrameMaker: trop cher et maintenant le monopole .doc est bien établi..
[^]Re: Eheh
D'une part, j'ai tendance à croire quelqu'un comme Tim Sweeney - cofondateur d'Epic Games, et concepteur de l'Unreal Engine - quand il raconte des choses comme "Will gladly sacrifice 10% of our performance for 10% higher productivity", "We never use assembly language", "C++ is ill-equipped for concurrency", "Purely Functional is the right default", ou encore "Garbage collection should be the only option". Cf son jeu de slides citées par brouillon.
Et où va jeter un oeil Tim Sweeney pour résoudre ses problèmes du moment ? Chez les théoriciens, et même les théoriciens des langages, ces fameux qui "feraient mieux de redescendre sur terre". Où va-t'il chercher des idées ? Vers un langage come Haskell, probablement à ranger dans la catégorie des "erlang/caml/machin-tout-pourrave"
Quand au "99% des jeux vidéos sont écris en C et/ou en C++", même à l'heure actuelle, c'est déjà complètement faux. Les shading languages sont entré dans la danse, ainsi que les langage de script. Il n'y a qu'à voir le succès de LUA dans ce marché, ou se rappeler de Carmack au début de Quake 3 qui avait sérieusement envisagé Java pour finalement se décider pour une variante de C interprétée.
Il n'y a rien de pire que l'aveuglement technique.
> Et jusqu'à preuve du contraire, citer un future échec^W^W^Wproduit Microsoft comme
> référence sur linuxfr est du plus profond mauvais goût...
Oops, correction, il n'y a rien de pire que l'aveuglement idéologique.
On peut dire beaucoup de choses sur Microsoft, mais on pourrait au moins leur reconnaitre qu'avec C#/.Net ils sont en train d'innover et tenter des choses intéressantes. Déjà, contrairement à l'idée répandue, ce n'est pas simplement du copycat de la JVM et de Java, cf. par exemple les papiers de John Gough qui montrent que Microsoft a essayé de comprendre ce qui marchait ou ne marchait pas dans le modèle JVM et d'améliorer les choses (renversement du modèle compilé/interprété, possibilité de faire de la tail recursion), sans parler de choses comme le multi-langage, les annotations, le problème du versioning de code, etc.
Bien sûr, la CLR n'est certes pas la VM la plus avancée/expérimentale au monde, mais ils sont les premiers à s'être pris de front tout ces problèmes là en même temps et mettre le tout en production. Sans parler de trucs récents comme LINQ, la réintégration des lambda ou d'un peu de typage implicite, etc.
> Et Tannenbaum est certes très doué, mais reste un théoricien...
Un théoricien qui veut prouver ce qu'il dit en codant un noyau unix, ça me va.
Sans méchanceté aucune: il faudrait voir à enlever les oeillères et regarder un peu le vaste monde.
[^]Re: Eheh
"Sans parler de trucs récents comme LINQ,"
Tu penses vraiment que surcharger la syntaxe d'un langage déjà plus que riche avec de la syntaxe d'autres langages est une bonne chose ?
[^]Re: Eheh
Très sincèrement ? oui. D'une part parce que ça ne me parait pas aberrant d'avoir des constructions de style requête dans un langage 'classique', même pour un fonctionnement complètement mémoire. Tant qu'à se taper des boucles for imbriquées avec 2 tests paumés au fond, j'aimerais autant l'exprimer à un niveau un poil plus abstrait, quand à la syntaxe je suis agnostique: autant j'aime la syntaxe minimaliste des lisp-like et smalltalk et de la manière d'écrire qu'on y trouve, autant ça ne me choque pas de voir des langages comme C# pousser l'exploration dans d'autres voies.
Et on peut au moins reconnaître à C# (et donc la bande à Hejlsberg) d'avoir amené des façons intéressantes de simplifier certaines écritures (ne serait-ce que par les attributs). D'autre part, tant qu'à voir des choses comme les requêtes arriver au niveau de la syntaxe du langage, autant que ça soit fait d'une manière intéressante et leur manière de faire en faisant intervenir les lambda et les expressions tree, et de mapper ça sur différents modèles (in-memory / xml-like / sql-like).
Savoir si c'est "une bonne chose", on ne peut le voir qu'à l'usage et sur la durée, mais tenter des choses comme ça, oui, je pense que c'est une bonne chose.
[+] [^]Re: Eheh
Nicolas je comprend ta colère : les langages de oufs, c'est juste pour frimer et étaler sa science :).
Les jeux : y en a des petits sympas en java sur téléphones portables ;). Non des bons jeux 3D, c'est C++ (avec des vrais morceaux de C ;) ).
Pour le reste C suffit et ça suffit :). (me parle pas de C++ sauf pour les guis).
blog
[^]Re: Eheh
Les gros jeux vidéos modernes ont besoins de plusieurs langages (par exemple il est possible d'avoir un moteur 3D en C et quelques bribes d'asm, moteur physique en C++, langage de scripting pour gerer les perso, etc...)
Faut arreter de croire que le C c'est le mal ultime et le FooBar c'est "trop de la balle ultime, et de toute manière si jamais ca rame on s'en fout nos PIV à 42 GHz qui necessitent une tranche nucléaire par proc sont bien assez rapide" ou inversement. Chaque langage a un interet dans un contexte particulier et c'est en les combinant qu'on peut faire des choses réellement interressantes.
Ce passer d'asm dans des inner loop ultra critique en croyant que dans 1 ans on pourra compiler du python et ca produire du MMX mixé avec du SSE n'est pas la meilleur prévision qu'on puisse faire du futur :))) A l'inverse si un timer s'execute 1 fois par seconde, on s'en fout royalement qu'il mette 10 ou 100 µs.
Autre exemple y a des fois ou c'est completement crétin d'utiliser un garbage collector, des fois ou ca s'implifie tellement le code que c'est absolument absurde de pas s'en servir (toutes choses égales par ailleurs).
[^]Re: Eheh
juste pour la reference a l'asm dans les jeux,
epic game (moteur d'Unreal) n'en utilise pas du tout !
Je pensais avant que cela s'averai indispensable aussi, mais
connaissant maintenant les faits, je veux bien comprendre aussi
pourquoi il est délirant de vouloir se servir d'asm dans le cas
de projet aussi ambitieux et accesoirement multiplateforme.
[^]Re: Eheh
>> epic game (moteur d'Unreal) n'en utilise pas du tout !
D'où tiens-tu cela?
ps: les intrinsics, c'est pas du jeux ;) http://msdn.microsoft.com/library/default.asp?url=/library/e(...)
[^]Re: Eheh
> A propos de jeux vidéos, c'est aussi pour ça que 99% des jeux vidéos > sont écris en C et/ou en C++
Avec des raisonnements comme ca tu vas loin: 90% des postes de bureau sont sous windows, 90% des logiciels bureautiques sont ceux de Microsoft. J'espère que tu conviendras que ca n'en fait pas les meilleurs produits :).
Aujourd'hui C/C++ est le langage le plus utilisé (en opensource) parce que c'est aussi le plus connu (et qu'en codant proprement tu arrives surement à quelque chose d'assez performant). Mais avec l'augmentation des fonctionnalités (je pense par exemple à un environnement de bureau), il est intéressant de faire une application dans un langage plus haut niveau (python/ruby par exemple) pour se concentrer vraiment sur les fonctionnalités et arrêter de se prendre la tête avec des segfaults.
Au niveau des applications réseau, on voit aussi pas mal d'applications écrites dans un langage plus 'évolué': bitorrent en python, mldonkey en ocaml, ejabberd en erlang, twisted en python (flumotion, buildbot).
Bref, ya de la place pour tout le monde, la seule chose qui compte c'est que celà fonctionne.
--
Thomas
[+] [^]Re: Eheh
Je suis de bonne fois, si quelqu'un me sort un OS en erlang/caml avec ses drivers, ses programmes (où un VRAI jeu vidéo), qui soit aussi rapide qu'un OS en C/asm, je ne dis pas que je commencerai à réfléchir un peu, mais en attendant, laissez moi le privilège du doute.
En jeu vidéo Caml j'ai trouvé mlrobbo : http://mlgame.sourceforge.net/Shots/robbo.png
Par contre je ne sais pas si c'est aussi rapide qu'en C. Il n'y a d'ailleurs pas d'équivalent en C à ma connaissance, ce qui me fait penser ceci : un tel jeu est-il au moins faisable en C ? Vous me répondrez sûrement oui, mais cela sera très certainement moins portable que son homologue Caml.
Moi aussi je suis de Bonn et de Foix.
[^]Re: Eheh
Je ressens une certaine aversion pour les "langages universitaires" (comprendre tout sauf le C ou les langages OO à classe "traditionnels"). Une expérience difficile à la fac ?
>C'est d'ailleurs pour ça que l'OS sur lequel vous écrivez ce message
>est écris en C et pas en erlang/caml/machin-tout-pourrave
Manque de bol, tu compares des langages qui n'ont pas grand chose à voir... Erlang (au contraire de Caml) est un langage spécialisé. Il n'a jamais été sa vocation de faire du bas niveau (nécessaire à un OS).
>de même que le navigateur, le moteur de rendu html
Ben merde, mon navigateur est un peu en vrai C++ et beaucoup en XML + Javascript.
>les OS des différents routeurs/servers par lesquels passent les
>messages HTTP, la lib qui encode ce-même http en https, et j'en
>passe.
Tu ne crois pas si bien dire. Erlang a été mis en oeuvre avec succès dans le routeur AXD301 d'Ericsson. Le résultat a été documenté, je pense que le pdf suivant est très explicite http://www.erlang.se/publications/Ulf_Wiger.pdf
Sinon il y a un serveur web en Erlang qui monte mieux en charge qu'Apache : Yaws (Yet another web server).
>A propos de jeux vidéos, c'est aussi pour ça que 99% des jeux
>vidéos sont écris en C et/ou en C++ (et quand je vois des
>bouquins sérieux comme les Game Programming Gems, ce n'est
>généralement pas du 'vrai' C++ mais plutôt du C avec des classes
>parce qu'il ne faut pas déconner), et surement leurs serveurs
>avec. Je sais bien qu'il y a des gens qui pensent que 80% de la
>lourdeur d'un jv vient des accès gc, mais bon...
Bah moi j'aurais dit que dans la plupart des jeux vidéos, le "core" nécessitant les grosses performances est codé en C/C++, et le reste en un langage de plus haut niveau ("UnrealScript" dans l'UnrealEngine, Python dans Civ4 et EVE Online...).
>Je pense que certains théoriciens qu ne pensent qu'à refaire le
>monde de la programmation à leur sauce parce qu'avant tout le
>monde il était crétin et que eux on la solution feraient mieux de
>revenir sur terre.
Et moi je pense que certaines personnes oublient rapidement que si l'informatique est là ou elle en est actuellement, et comment elle avance, c'est grâce à ces mêmes théoriciens, qui par définition réinventent souvent moins la roue que certains libristes.
Par ailleurs, tu compares beaucoup deux langages qui n'ont vraiment pas grand chose en commun : (O)Caml et Erlang. Clarifions les choses : Erlang est un langage fonctionnel spécialisé disposant de peu de traits impératifs (pas de boucles, etc), alors qu'OCaml se flatte d'être multi-paradigme et généraliste.
Contrairement à ce que tu sembles sous-entendre, Erlang n'est pas un délire théorique sorti de l'imagination embrumée d'un théoricien. C'est un projet conçu par Ericsson, utilisé dans l'industrie, avec une large gamme d'outils fournis. Il est vraiment conçu pour le dev. concurrent, et n'a jamais affirmé faire du bas niveau ou rivaliser avec le C concernant les performances pures. Beaucoup d'experts Erlang pensent qu'au contraire son futur passe par une entrée dans les moeurs académique, pour sortir un peu de l'industrie : en cela, il est l'exact inverse d'OCaml.
>Je suis de bonne fois, si quelqu'un me sort un OS en erlang/caml
>avec ses drivers, ses programmes (où un VRAI jeu vidéo), qui soit
>aussi rapide qu'un OS en C/asm, je ne dis pas que je commencerai
>à réfléchir un peu, mais en attendant, laissez moi le privilège du
>doute.
Du doute de quoi ? Qu'Erlang et Caml ne sont pas adaptés à l'écriture de code bas niveau extrèmement optimisé ? Bah alors je pense qu'on est d'accord. Mais ça n'a jamais été le sujet.
Sinon, je suppose que tu vas adorer House :
http://www.cse.ogi.edu/~hallgren/House/
Un OS codé en Haskell, langage fonctionnel pur (on peut difficilement trouver meilleur "délire de théoricien" ;-)).
Wr ar fbhunvgr cnf ha qrfgva sharfgr à yn cncnhgé. Nzra.
[^]Re: Eheh
Et c'est même pire que ça. Les interpréteurs/compilateurs/machines virtuelles java, perl, python, ruby, c# (en tout cas mono, celui de Microsoft je ne sais pas), ocaml sont tous eux-mêmes en grande partie écrits en C/C++.
[^]Re: Eheh
Je vois pas en quoi c'est pire, il faut bien les écrire en quelque chose. Remarque qu'elles ne sont pas écrites en assembleur, comme quoi al couche supérieure s'appuie sur la couche technologique immédiatement antérieure et non pas directement sur la couche assembleur ou matérielle directement.
Faire une autre couche, c'est pas dire 'les couches d'avant sont toutes pourries' mais plutot, elles sont insuffisantes et pas vraiment utilisable pour pour faire pleins de trucs supers, il faut qu'on fasse mieux.
[^]Re: Eheh
Euh, c'est faux, en ce qui concerne la plupart des langages évoqués dans les commentaires ci-desus. Sont bootstrappés depuis longtemps : OCaml, Erlang, Haskell... Pour les langages pseudo-interprétés du genre Python, Ruby, Perl (<= 5.x), ok. Quand à Mono, je trouve 11845 fichiers .cs dans les dernières sources, contre 259 .c ...
Wr ar fbhunvgr cnf ha qrfgva sharfgr à yn cncnhgé. Nzra.
[^]Re: Eheh
Quand à Mono, je trouve 11845 fichiers .cs dans les dernières sources, contre 259 .c ...
Mono l'environnement d'exécution est écrit en C
(g)mcs le compilateur C# du projet Mono est écrit en C#.
MonoFrance
[^]Re: Eheh
Attention, les compilateurs sont bootstrapés et les bibliothèques standard aussi mais les runtimes sont en général écrits en C (c'est le cas de OCaml en tout cas).
[^]Re: Eheh
Et pour Java, on peut citer la JikesRVM/Japaleno d'IBM http://jikesrvm.sourceforge.net/ qui est écrite en Java et qui nécessite juste un petit load d'image mémoire et une classe magique qui permet de descendre sous la VM quand c'est nécessaire.