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. Le gain de performance apporté par cette nouvelle version est déjà important, comme le montrent plusieurs benchmarks:
- http://www.erlang-stuff.net/wordpress/?p=14
- http://www.franklinmint.fm/blog/archives/000792.html
Des optimisations sont déjà cependant prévues.
Cette nouvelle version marque une étape importante dans le développement d'Erlang et devrait contribuer à accélérer son adoption.
Erlang est réputé pour ses fonctionnalités, permettant de développer des applications robustes, capables de monter en charge et que l'on peut mettre à jour à chaud. Son orientation vers la concurrence en fait un langage idéal pour développer des serveurs.
Aller plus loin
- Erlang (7 clics)
- Nouveautés de la version R11B (2 clics)
- IBM DeveloperWorks: Concurrent programming with Erlang (5 clics)
- Planet Erlang (4 clics)
- Livre: Erlang programmation (15 clics)
- Définition Wikipédia (5 clics)
# ...
Posté par Anonyme . Évalué à -1.
C'est pas pour dire, mais ça fait des années que pleins de gens pensent avoir découvert le langage idéal, et on en revient toujours au C...
Surtout pour de la programmation serveur...
[^] # Re: ...
Posté par olgk . Évalué à 10.
[^] # Re: ...
Posté par Gniarf . Évalué à 5.
dernier paragraphe de : http://gracewanderer.livejournal.com/89519.html
There was a handfull of Comp Sci students there that I hung out with for a bit, and they told me about a lunch that they were all at earlier in the day with Alan Kay.
Apparently, one of the students said to Kay, "I don't see why you need anything more than C to write an operating system with."
This is like saying to Einstein, "I don't see why we need anything better than Newtonian physics to describe the universe."
A good 15 minutes of humiliation followed.
[^] # Re: ...
Posté par Pol' uX (site web personnel) . Évalué à 7.
De manière générale, chaque langage existe car il a le mérite de poroposer quelque chose que les autres ne proposent pas. J'adore le language C, mais ce n'est pas approprié pour faire certaines choses, même si on peut tout faire en C.
J'ai un pote qui developpe en smalltalk en ce moment, il se fait bien plaisir car c'est un bon language, mais en contre partie les performances sont pitoyables. Alors bon ... il faudra finir par admettre un jour que la nature est bourrée de compromis, et qu'il n'y a pas de language miracle qui permette de tout bien faire facilement et de façon performante, simple d'accès mais ultra-sécurisé, exploitant bien les ressources, et avec une description mixte impérative/fonctionnelle.
Adhérer à l'April, ça vous tente ?
[^] # Re: ...
Posté par Ontologia (site web personnel) . Évalué à 1.
Lisaac. Et c'est le but (bon évidemment pour le fonctionnel par exemple, on fera jamais mieux que Caml, Lisp, etc...).
Et s'il manque des choses a ton goût, c'est ici : http://wiki.loria.fr/wiki/Sp%C3%A9cifications_compilateur
Bon j'ai fait ma prosel de la semaine, c'est bon...
Ok, je --> []
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: ...
Posté par Pol' uX (site web personnel) . Évalué à 4.
So, wait and see.
Adhérer à l'April, ça vous tente ?
[^] # Re: ...
Posté par Ontologia (site web personnel) . Évalué à 4.
Mais on réfléchi depuis quelques temps, surtout à l'instigation de nicO à des fonctionnalités massivement parralèles un peu comme Erlang. Mais faut spécifier tout cela et ensuite réfléchir si c'est intégrable et comment l'intégrer...
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: ...
Posté par lasher . Évalué à 10.
Euh, au contraire, mis à part les systèmes embarqués, ou nécessitant une patate pas possible (et encore), le C a tendance à être marginalisé dans ce que j'ai vu autour de moi.
Surtout pour de la programmation serveur...
Là pareil, tout dépend. Tu peux avoir une infrastructure à partir de C (genre Apache, etc.), avec une base de code relativement petite, mais quand tu vois Apache+Tomcat, ou JBoss, les applications serveur en Java sont très utilisées (et on pourrait sans doute dire la même chose des applications C#, Perl, Ruby &co.).
Erlang a ça de génial qu'il embarque tout un tas de mécanismes qui sont fastidieux à utiliser (voire à programmer) dans un langage comme le C. Franchement, celui qui me dit que la gestion des threads en C, c'est super simple, que la gestion des accès concurrents, ça ne pose pas de problème, etc..., j'aurai du mal à le croire. Ou alors, les threads sont indépendants, et alors, pourquoi en utiliser en premier lieu ? :-)
[^] # Re: ...
Posté par pastro . Évalué à 0.
"Ou alors, les threads sont indépendants, et alors, pourquoi en utiliser en premier lieu ?" ben pour parallèliser le traitement ( archi multi-proc tous ca ... ) et pourquoi pas des fork a la place? ben histoire de changement de contexte plus court ...
[^] # Re: ...
Posté par brouillon . Évalué à 8.
> sur tu geres tous les access toi même mais je dirai chiant ou long
> mais pas compliqué .
La gestion des threads en C/C++ est compliqué par le fait que ces deux langages ne possede aucune primitives de concurence et de gestion des threads en interne.
Si effectivement au premier abord tu peux avoir l'impression que ce n'est pas si compliqué de faire du multithread en C/C++, le fait est que dans le cas d'applications réelles (autre que toy-app) le programmeur se trouve confronté à de nombreux bugs, non reproductibles, très difficille à trouver et encore plus à éliminer.
Le gestion des threads à travers une bibliotheque est d'ailleur très critiquée. voir :
"Threads Cannot be Implemented as a Library"
http://www.hpl.hp.com/techreports/2004/HPL-2004-209.html
qui en detaille les raisons
> "Ou alors, les threads sont indépendants, et alors, pourquoi en
> utiliser en premier lieu ?" ben pour parallèliser le traitement
> ( archi multi-proc tous ca ... )
Les threads peuvent en effet etre utilisé pour accelerer certain traitement. Mais ceci n'est qu'un cas particulier de leur utilisation.
De mon point de vu, les threads permettent surtout d'offrir aux programmeurs un acces au paradigme de la programmation concurente.
L'intérêt n'est pas d'aller plus vite, c'est surtout de coder plus simplement certain type de probleme très complexe qui se pretent mieux à mode de pensée.
> et pourquoi pas des fork a la place? ben histoire de changement
> de contexte plus court ...
Sache que sous Linux processus et thread sont pour ainsi dire la meme chose (Ce n'est pas le cas sur tout les OS, et Solaris possede une gestion des threads réellement intéressante).
Ce sont dans les fait des processus kernel-land avec comme seul difference que pour les threads ces processus partage le même espace mémoire. le scheduling se fait ensuite par le kernel comme n'importe quel process et "quasiment" à la même vitesse.
Voir ainsi l'appel system clone
$ man clone =>
NAME
clone - create a child process
DESCRIPTION
clone creates a new process, just like fork(2).
...
The main use of clone is to implement threads: multiple threads
of control in a program that run concurrently in a shared
memory space.
Il me semble que fork (...) fait appel à clone dans les fait
[^] # Re: ...
Posté par Jerome Herman . Évalué à 7.
Ca n'est (et heureusement) plus le cas. Linux est passé en mode NPTL depuis un petit moment, donc on a des vrais threads sous Linux et non juste des processus à moitié forkés.
Personellement ca fait pratiquement deux ans que ma Glibc est en NPTL only (elle ne supporte plus du tout les linux threads) et ca marche très bien (sauf pour MySQL, mais c'est un autre débat).
Maintenant les threads sont des entités dépendantes du processus (ie tous les threads d'un process sont ratachés à l'ID de ce process et le kernel ne voit qu'un seul process) et en plus on a une API standard pour créer toutes sortes de threads, les mutex et les sémaphores qui vont avec.
[^] # Re: ...
Posté par brouillon . Évalué à 6.
Je parlais bien cependant de la NPTL quand je disais que chaque thread etaient en fait encapsulé dans un process.
La NPTL semble surtout ensuite apporter certaine primitive de synchronisation entre les threads(process) crées.
j'ai tenu a verifier et dans WikiPedia
http://en.wikipedia.org/wiki/NPTL
(qui bien sur n'est pas parole d'evengile, mais bon) je lis :
NPTL uses a similar approach to LinuxThreads, in that the primary abstraction known by the kernel is still a process, and new threads are created with the clone() system call (called from the NPTL library). However, NPTL requires specialized kernel support to implement (for example) the contended case of synchronisation primitives which might require threads to sleep and be re-awoken. The primitive used for this is known as a futex.
NPTL is a so-called 1×1 threads library, in that threads created by the user (via the pthread_create() library function) are in 1-1 correspondence with schedulable entities in the kernel (processes, in the Linux case). This is the simplest possible threading implementation.
Maintenant je peux me meprendre sur certain point et je suis ouvert a toutes discussions.
[^] # Re: ...
Posté par Jerome Herman . Évalué à 5.
Apparament cependant tu en te trompais pas et c'est moi qui affabulait. Actuellement il semblerait que la NPTL soit toujours basé sur un modèle 1-on-1 (ie chaque thread utilisateur correspond un thread système, c'est à dire un processus) et non pas M-on-N comme ca avait été promis à une époque lointaine et reculée.
C'est un peu dommage pour les ordinateurs vraiment multiprocesseurs (comprendre 8 et plus) mais c'est vrai que pour le reste du monde ca ne change pas grand chose au niveau des perfs et ca allège considérablement la complexité du code.
Je pars me flageller avec des orties fraiches en penitence....
[^] # Re: ...
Posté par Krunch (site web personnel) . Évalué à 6.
Sinon en pratique il semblerait que les seuls OS un peu populaires qui ne font pas du 1:1 sont FreeBSD et NetBSD (sans doute aussi DragonFlyBSD ?).
http://web.mit.edu/nathanw/www/usenix/freenix-sa/freenix-sa.(...)
Au passage, j'ai écrit ça il y a quelques mois qui devrait faire une bonne introduction aux threads et processus en français pour ceux qui « débutent » : http://www.krunch.be/vrac/txt/sco-resume.pdf (oui, typographiquement c'est dégeulasse, désolé)
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: ...
Posté par Julien . Évalué à 0.
Je croyais que c'était aussi le cas de Windows ...
[^] # Re: ...
Posté par Krunch (site web personnel) . Évalué à 6.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: ...
Posté par pasBill pasGates . Évalué à 7.
[^] # Re: ...
Posté par tene . Évalué à 4.
Et les priorités des threads dépendent de leur process (y'a un lien fort entre process et thread) et de leur propre priorité. Cependant, ce sont en effet bien des threads qui sont scheduler, et pas des process.
Bref, c'est pas simple ;)
[^] # Re: ...
Posté par Krunch (site web personnel) . Évalué à 1.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: ...
Posté par tene . Évalué à 2.
Les fiber, sont (était) un outil pour diminuer le nombre de context switching en permettant à un thread de profiter de son quanta complètement. (sachant qu'un context switching arrive sur un sleep, sur l'attente d'un objet de synchro ou à la fin du quota, tu peux éviter ces deux premiers cas à l'aide d'un fiber).
Cependant faut relativiser leur utilité maintenant: le context switching est relativement de moins en moins cher (les cpu deviennent de plus en plus rapide, alors que les quantas CPU alloués par thread n'ont pas diminué de la même façon), et ce qu'on veut éviter quand on cherche des perfs, c'est de perdre sa cache (ce qui coute relativement de plus en plus cher, vu que la mémoire n'évolue pas aussi vite que la fréquence du cache...)
Enfin, je parle pas de parallélisation, mais de montée en charge, il est amha, naif de croire que rendre tout parallèle permet toujours de gagner en temps d'exécution, en fait, c'est même le contraire, une fois arrivé à un CPU par thread, la question est de ne pas bloquer les thread, pas d'en rajouter plus (et comme ce n'est pas toujours possible, ne fut-ce que parce que la plupart des applications requérant de la scalability sont IO bound, faciliter la gestion des threads, ça aide...).
[^] # Re: ...
Posté par sbugsin . Évalué à 3.
Pour l'instant, DragonFly est encore en 1:N mais le passage en 1:1 est prévu (avec l'utilisation de libthread_xu pour gérer les threads utilisateurs) . Par contre il n'y a pas vraiment de date arrêtée. Je ne sais pas exactement ce qui empêche le passage en 1:1 mais c'est probablement du côté du noyau.
[^] # threading 1:1 DragonFlyBSD
Posté par sbugsin . Évalué à 3.
Pour info, la roadmap écrite en octobre 2005 (en anglais) :
http://leaf.dragonflybsd.org/mailarchive/kernel/2005-10/msg0(...)
Pour l'instant les développements nécessaires à ce sujet semblent ralentis, voire arrêtés.
[^] # Re: ...
Posté par Jerome Herman . Évalué à 5.
Le pire de tout c'est le 1:N , dans ce cas là grosso-modo c'est quasiment comme si les threads n'existait pas. Tout se dérouel en userland et totu est rattaché au même processus (donc au même thread kernel, donc au même CPU)
Le 1:1 permet pas mal de parallelisation, mais il a ses limites. L'immense avantage de la gestion 1-on-1 est qu'elle ne nécessite pas du tout de planificateur en userland, il suffit généralement de rajouter quelques signaux au planificateur de processus pour s'en sortir.
Le M:N est très complexe à mettre en oeuvre, il nécessite deux scheduler (un en kernelland et un en userland) et il faut en plus que ces deux planificateur soient très bien coordonés. Cependant, il est celui qui offre le plus de flexibilité : dans un modèle avec un SA (Scheduler Activation) le kernel distribue des processeurs virtuels à tous les processus qui font appels aux threads et peut mettre à jour le nombre de processeurs virtuels attribués dynamiquement. Ca permet de constament adapter les threads à la charge effective des processus. Sous certaines conditions on peut même déplacer un thread d'un processeur à l'autre. Mais bon c'ets clair que vu l'overhead impliqué au niveau système, il vaut mieux avoir du processeur disponible, sinon ca sert pas à grand chose.
Pour plus de détails : http://people.redhat.com/drepper/Scheduler.pdf
[^] # Re: ...
Posté par brouillon . Évalué à 4.
> comme si les threads n'existait pas. Tout se dérouel en userland et totu est
> rattaché au même processus (donc au même thread kernel, donc au même CPU)
tout depend du point de vu et surtout de l'usage que l'on fait des threads.
Ainsi que je le disait precedement, les threads permettent d'offrir aux programmeurs un acces au paradigme de la programmation concurente qui peut s'averer plus adapté pour ecrire certains types de programmes.
Dans ce cas la, la gestion des threads en 1:N est bien souvent celle qui permet la gestion la plus fine pour le scheduler. Ainsi si tu considere la simulation d'un tres grand nombre d'entités et que tu a un imperatif de reactivité, ce mode est le plus adapté.
Je me pose d'ailleur une question : est il si simple de savoir si l'on gere plusieurs threads legers (géré par le langage ou user-land si on veut) en mode 1:N.
Apres tout lorsqu'on programme, le runtime du langage sur lequel on repose
peut tout a fait switcher plusieurs threads legers (si le langage integre bien sur les threads leger en interne, ce qui est loin d'être le cas de tout les langages) sur plusieurs threads kernell (process) si cela lui lui semble plus adapté à l'archi sur laquelle il repose, par exemple si le code s'execute sur du multi-core.
Il n'est en effet pas a la charge du programmeur d'un langage haut niveau de s'adresser directement à l'un ou l'autre des coeurs.
Donc au final pour arriver à la fin de cette digression alambiquée (c'est confu dans ma tete aussi) la gestion des threads par le kernel en 1:1 ne pose aucun probleme particulier, et n'empeche pas necessairement les langages qui permettent de faire de manière interne du 1:N d'un coté et de faire usage des threads kernel de l'autre, d'optenir du M:N.
Un langage generaliste moderne doit donc pouvoir offrir les moyens de programmer aisement de manière concurrente et ceci en permettant de gerer des threads user-land ET kernel-land.
Je pense au langage Haskell et plus particulierement à l'implementation GHC de celui-ci, pour laquelle une active discussion est mené pour gérer la concurrence.
[^] # Re: ...
Posté par Julien Wajsberg . Évalué à 6.
vala vala..
[^] # Re: ...
Posté par pasBill pasGates . Évalué à 3.
J'ai pas regarde ce qui a change de ce cote depuis un petit moment, mais j'esperes que ca a ete corrige, parce que c'etait vraiment ch....
[^] # Re: ...
Posté par rewind (Mastodon) . Évalué à 9.
http://www.eecs.berkeley.edu/Pubs/TechRpts/2006/EECS-2006-1.(...)
où le monsieur explique que la sémantique des threads introduit du non-déterminisme (et tout ce qui va avec dont la difficulté à débugger) dans un contexte déterministe. D'où une difficulté à résoudre des problèmes simple comme faire un design pattern observateur en Java qui soit correct dans un environnement multithreadé (code à l'appui). Il se place dans le contexte de l'embarqué mais je pense que ses remarques sur les threads sont tout à fait pertinentes.
[^] # Re: ...
Posté par golum . Évalué à 3.
[^] # Re: ...
Posté par Mickaël Rémond (site web personnel) . Évalué à 5.
Regarde le troisième lien proposé:
http://www-128.ibm.com/developerworks/java/library/j-cb04186(...)
--
Mickaël Rémond
http://www.process-one.net/
Mickaël
[^] # Re: ...
Posté par benoar . Évalué à 4.
http://lambda-the-ultimate.org/node/1481
[^] # Re: ...
Posté par Jerome Herman . Évalué à 10.
Ca dépend ? Qui veux-t-on comme gagnant ? Si on veut juste se rassurer sur l'inutilité à apprendre un autre langage que le C je suggère le calcul de décimales de Pi ou des suites de Fibonacci en mono processus - mono utilisateur. Le C devrait plier à peu près tout ce qui passe. Erlang va apparaitre comme lent et gourmand en mémoire.
Par contre si on s'amuse à faire un bête programe qui créé 200 serveurs intersynchronisés (comme par exemple pour un MMORPG) et que l'on connecte dessus quelques dizaines de milliers de clients on risque d'avoir 99% des programmeurs C qui vont avoir vraiment du mal. Alors que les programmeurs Erlang ayant un peu d'expérience devraient s'en sortir tous a peu près convenablement. Alors après reste la question de savoir qui entre le meilleur programmeur C et le meilleur programmeur Erlang du monde remporterait la palme. En toute honnêteté ce serait probablement le meilleur programmeur C du monde, mais le meilleur programmeur Erlang du monde aurait à coup sur un code maintenable par d'autres que le meilleur programmeur Erlang du monde.
Erlang à un très fort overhead (charge initiale), donc lui faire éxecuter des petits programmes en boucle le met forcément en position de faiblesse. Ceci dit il scale (monte en charge) très bien (très très même).
De toutes les façons, le langage Erlang est certes turing complet, mais il est destiné très prioritairement aux applications communicantes (archi point à point, client/serveur, n tiers etc.) de fait le comparer avec un langage aussi généraliste que le C n'a pas grand intéret. On pourrait éventuellement imaginer un bench d'une bibliothèque réseau ou IPC face à Erlang, mais comparer brut de décoffrage C et Erlang revent à la bonne vieille comparaison entre le couteau et la fourchette.
[^] # Re: ...
Posté par cbon linux . Évalué à -1.
quelle drôle d'idée de comparer des choux et des poires :).
Vitesse : C gagne car proche du langage machine.
Portabilité : C gagne grâce aux différents compilateurs.
Lisibilité : Erlang gagne car il a des fonctions déjà toutes prêtes.
Si on comparait C++ et Java ? Oups, on m'appelle :).
[^] # Re: ...
Posté par agmk . Évalué à 8.
Sans doute.
>Portabilité : C gagne grâce aux différents compilateurs.
Oui, le C est portable, si on utilise des bibliothèques portables et qu'on ne se repose pas sur les idiosyncraties du compilateur.
Mais l'infrastructure Erlang a été portée vers de très nombreuses architectures matérielles (et des plus exotiques), plus même que la JVM si je m'en souviens correctement. Le bytecode Erlang est donc plus que raisonnablement portable lui aussi.
>Lisibilité : Erlang gagne car il a des fonctions déjà toutes prêtes.
Ouhla, ça me paraît un peu réducteur. Erlang "gagne" parce qu'il dispose certes d'un framework important (mais pas bloated), mais aussi qu'il est fonctionnel et a une syntaxe claire et concise. Troll : tu considères Java plus lisible que C++ parce qu'il a "des fonctions déjà toutes prêtes" ?
Et surtout, comme expliqué plus haut, Erlang "gagne" (j'aime pas vraiment le terme) largement pour les serveurs, parce qu'il est très facile d'écrire des programmes concurrents, distribués, clusterisables, et qui peuvent être mis à chaud.
[^] # Re: ...
Posté par cbon linux . Évalué à -5.
Ok, Erlang c'est génial, mangez-en ;). (troll : pour les serveurs hein, sinon c'est le C ).
[^] # Re: ...
Posté par Philippe F (site web personnel) . Évalué à 7.
Mouai. Faudrait commencer a evoluer.
Par exemple, sur le "language shootout", OCaml est extremement proche du C pur en terme de vitesse:
http://shootout.alioth.debian.org/old/benchmark.php?test=all(...)
Et pourtant, je ne crois pas que OCaml soit "proche de la machine".
De meme, IronPython, une version de python ecrite pour le CLR de C# est plus rapide que la version de python en C.
Le C se prete bien a certaine manipulations mais pour des gros programme, je suis persuade qu'un langage qui expose correctement les intentions du programmeur dans sa grammaire pourra a terme etre mieux optimise par un bon compilateur. Le C et le C++ ont ce probleme que leur grammaire est complexe, avec des manipulations qui cachent ce que veut faire le developpeur. Au final, une information est perdue, celle de l'intention du programmeur et les optimisations sont donc limitees dans la mesure de l'expressivite du langage.
Si on regarde Java ou C#, on trouve plein d'outils de refactoring, d'analyseurs de code, de programmation oriente aspect, etc etc. La richesse de ces outils vient du fait que ces langages exposent une grammaire plus facile et que les outils annexes peuvent mieux comprendre et aider le programmeur.
[^] # Re: ...
Posté par cbon linux . Évalué à -8.
OCaml le joujou de recherche plus rapide ? Ca vient surtout du compilo et le langage n'est pas complexe ;).
Pourquoi Ironpython est plus lent en C qu'en C# ? Mal optimisé ?
Le C peut aussi bien faire de gros programmes, faut créer les bibliothèques et bien modulariser et bien savoir coder aussi ;).
La grammaire du C est complexe ? :o Pourquoi ?
Des manipulations qui cachent ce que veut faire le developpeur ? C'est quoi ?
La suite n'est pas claire non plus... Tu peux donner des exemples ?
Les outils n'ont rien à voir avec la simplicité du langage...
Et les outils ne font pas obligatoirement faire de meilleur code ;).
[^] # Re: ...
Posté par gc (site web personnel) . Évalué à 7.
ouatte ?? c'est vrai que l'inférence de types, les types paramétriques, le garbage collector hybride, l'héritage multiple, le pattern matching, tout ça c'est nettement plus simple qu'un bête compilateur C (qui je le rappelle ne fait rien de compliqué à part l'optimisation puisque c'est un traducteur quasi litéral vers le code assembleur).
[^] # Re: ...
Posté par Philippe F (site web personnel) . Évalué à 10.
Pourquoi Ironpython est plus lent en C qu'en C# ? Mal optimisé ?
>>
Une partie du gain vient du fait que le CLR peut detecter des organisations de code qu'il peut optimiser a la volee au moment de l'execution, ce que ne peut pas du tout faire le C.
Guido Van Rossum et tous les gens qui bossent sur python dpeuis 10 ans ne sont pas des machots donc je doute que le code C de python soit "mal optimise".
<<
Le C peut aussi bien faire de gros programmes, faut créer les bibliothèques et bien modulariser et bien savoir coder aussi
>>
Donc en fait, ta defense du C est une attaque des programmeurs. "Vous ne savez pas coder, sinon, ca marcherait mieux". C'est plutot minable comme argumentaire.
Sur des tres gros programmes en C, tu es souvent conduit a utiliser par exemple des pointeurs en (void *) car tu dois stocker plusieurs types de donnees dans un pointeur. L'absence de notion de dictionnaire, d'heritage, les notions de tableaux tres limitees, l'absence de notion d'interface font que beaucoup de paradigmes indispensables de programmation sont fait completement a l'insu du compilateur, qui du coup a un champ tres limite pour comprendre les intentions du programmeur et optimiser le code en fonction.
L'utilisation d'un (void *) est le plus flagrant mais tous les parametres jouent ensemble. Un dictionnaire a 3 elements est plus facile a optimiser avec une recherche lineaire, un dictionnaire avec 500 elements est plus facile a optimser avec une table de hashage. C'est une decision que le compilateur pourait prendre plutot que le programmeur.
L'absence de ramasse-miette fait aussi que les programmes en C demandent plus de travail au programmeur. Le ramassage des miettes (== desalllocation des ressources inutilisees) est aussi quelque chose que le compilateur peut faire mieux que le programmeur si on lui passe les bonnes information.
<<
La grammaire du C est complexe ? :o Pourquoi ?
>>
Au hasard et en survol :
- pas de distinction entre un tableau et un pointeur
- un melange entre la declaration de type et le nom de la variable :
<type de la variable> <nom de la variable> <info supplementaire facultative sur le type de la varible>
int a[30];
- le pre-processeur qui peut rendre la grammaire du texte decrivant le code completement irreguliere.
- l'absence de taille predefinies pour les types de bases.
<<
Des manipulations qui cachent ce que veut faire le developpeur ? C'est quoi ?
>>
Pour les plus simples :
- passage d'arguments par void *
- passage de tableaux par pointeur, on perd toute l'information sur la notion de tableau (de toute facon, le C n'est stocke aucune, mais c'est bien la une de ses limitations)
- bidouilles a coup de struct et de pointeurs de fonctions pour faire des interfaces
- pas de liste, pas de dictionnaire donc plein d'optimisations a la portee du compilateur qui sont perdues
<<
Et les outils ne font pas obligatoirement faire de meilleur code ;).
>>
T'as vraiment des arguments a 3 francs. T'as deja reflechi au sujet avant d'ecrire un truc pareil ?
Bien sur que la qualite des outils permettent d'ecrire du code de meilleur qualite et de le faire evoluer de meilleure facon.
Un outil de refactoring en java te permet de faire facilement evoluer ton code par exemple. La meme operation en C oblige a faire un gros grep dans les sources et a faire de modifs a la main, super penible donc rarement fait dans la pratique, donc code qui devient vite immaintenable.
Des que tu fais du C++, tu t'apercois que gdb n'as acces qu'a une partie limitee des objets, et que donc le debuggage est super penible, tu en reviens au printf, ce qui est long et penible.
Des outils comme la programmation oriente aspect permettent d'explorer des nouveaux concepts de programmation, plus en rapport avec les besoins de certains projets.
En java, il est possible de debugger a distance un programme java qui s'execute. Par exemple, je peux debugger une javacard depuis mon PC, poser des points d'arrets, inspecter les variables, etc. C'est difficile et lourd a faire avec du code embarque en C, tu es souvent oblige de developper un simulateur complet de ta plate-forme cible.
Des outils d'analyses de code peuvent te permettre de mieux comprendre un code existant. Ces outils sont limites dans leur comprehension du code C a cause des limitations de la grammaire du C (je commence a me repeter la).
<<
Les outils n'ont rien à voir avec la simplicité du langage...
>>
Je n'ai pas parle de simplicite mais d'expressivite. Si ton langage transcrit bien ce que tu veux faire, les outils peuvent t'aider beaucoup. Si ce n'est pas le cas, les outils ne peuvent rien pour toi.
Le cas d'erlang est frappant. Je ne connais pas le langage, mais je suis persuade que si tu informes le compilateur des morceaux de code qui doivent s'executer en parallele ou non, tu obtiens un truc bien plus propre que avec des mutex dans tous les sens, des sections critiques et des forks a tout va. Dans un cas, le compilateur peut t'aider et distributer pour toi l'execution du code sur plusieurs threads/processeurs/machines, dans l'autre, c'est toi pauvre programmeur, qui va essayer de le faire. Tu vas passer ton temps a re-inventer la roue.
[^] # IronPython
Posté par Antoine . Évalué à 2.
C'est une comparaison fallacieuse, car tu compares deux machines virtuelles différentes, et non pas deux implémentations différentes de la même machine virtuelle.
Les machines virtuelles écrites pour .Net (que ce soit celle de Microsoft ou de Mono) ont été beaucoup plus optimisées que celle de CPython. D'ailleurs, cette dernière ne fait pas de JIT (il y a Psyco qui est un projet séparé développé par une seule personne...).
[^] # Re: IronPython
Posté par TImaniac (site web personnel) . Évalué à 2.
Tu dis que .NET et Mono sont beaucoup plus optimisés que celles de CPython... C'est un petit peu le but de la comparaison :) De plus les 2 premiers n'ont pas du tout était conçu pour des langages dynamiques contrairement à CPython... IronPython sert d'ailleur de "cobaye" à MS pour améliorer sa VM en matière de langages dynamiques.
En fait sa comparaison est foireuse mais à pour une toute autre raison : il veut démontrer que le C n'est pas plus "rapide" que le C# en prenant pour exemple IronPython... Ce qu'il oublie c'est que .NET/Mono ne sont PAS écrits en C# mais en C :)
Bref, les seuls conclusions que l'on peut tirer ne sont pas sur le langage en soit mais sur les détails d'implémentation de la même VM : JIT ou non, VM dédiée langages dynamique ou pas, etc.
[^] # Re: ...
Posté par Jerome Herman . Évalué à 6.
Houlà, de moisn en moins vrai çà. Les processeurs commencent à être suffisament costaud poru que l'on puisse s'éloigner assez fortement du langage machine sans que celà pose de problèmes de perfs. Encore plus fort : sur une machine raisonnablement chargé (ie 50% de load CPU moyen) une machine virtuelle peu battre un programme natif. Par exemple toujours sur les codes clients/serveurs une fois la connexio établie il y a pleins de tests, de branchements et de boucles qui deviennent innutiles. Lors d'une éxecution dans une machine virtuelle on peut faire sauter tous ces ralentissements inutiles (Technique d'optimisation post bytecode par linéarisation) et le gain de performance est loin d'être négligeable. A titre d'éxemple le programme Dynamo qui est une machine virtuelle proche des processeurs alpha (i.e : un alpha virtuel) permet un gain jusqu'à 15% de performance sur des programmes nativement compilés pour alpha quand on l'execute sur un alpha.
Pour faire plus court, certains programmes alpha tournent 15% plus lentement quand ils sont executés directement sur un processeur alpha que quand ils sont executés sur une Dynamo sur un processeur alpha.
Portabilité : C gagne grâce aux différents compilateurs.
Pas tout à fait vrai non plus, tout d'abord parceque même si il y a pas mal de compilatuers, très peu sont C Ansi strict. Ensuite en C l'OS influence souvent beaucoup la programmation (Il suffit de comparer du code win32 avec du code GlibC pour comprendre). De toute les façons si le framework est bien fichu, il est quasiment impossible de battre en portabilité une machine virtuelle qui possède la triple compatibilité API/ABI/Source .
Lisibilité : Erlang gagne car il a des fonctions déjà toutes prêtes.
On peut cependant écrire des choses relativement illisibles en Erlang et utiliser des bibliothèques qui rendent le code très lisible en C. Après c'ets plus une question de méthode et de propreté du codeur.
[^] # Re: ...
Posté par cbon linux . Évalué à -1.
Portabilité :Si t'utilises gcc, ben il est C ANSI strict et il marche sur tous les Unix, et plein de processeurs non ?
L'OS peut influer ? Ca dépend si tu veux des fenêtres par ex. ;).
La machine virtuelle est une émulation, donc c'est moins rapide, et portabilité, ça dépend si elle existe ou non.
Lisibilité : ça dépend du codeur aussi mais avoir des bibli, ça aide.
[^] # Re: ...
Posté par Jerome Herman . Évalué à 4.
Tu attends dix ans. Les vieilles machines auront fait de gros progrès d'ici là.
Si t'utilises gcc, ben il est C ANSI strict et il marche sur tous les Unix, et plein de processeurs non ?
Non. a) Il n'est pas C ANSI strict, il peut se comporter comme C ANSI strict si on lui demande. Sinon il fait aussi du C ISO et si on ignore les warnings dans un cas comme dans l'autre on peut glisser assez loin de la norme.
b) Ce qui marche (plus ou moins bien) sur un paquet d'Unix c'est le trio GCC+Autotools et make+GLibc/Libc . Il existe entre les différents composants un degré de compatibilité assez élevé qui fait que les applications sont raisonnablement portables d'un systeme à l'autre, cependant on est loin de pouvoir prendre un programme Linux x86 pour le compiler sur uen station HP-UX.
La machine virtuelle est une émulation, donc c'est moins rapide
CF mon exemple de la Dynamo, parfois c'est plus rapide car plus flexible et donc optimisable pendant l'éxecution du code.
[^] # Re: ...
Posté par golum . Évalué à 3.
Si le C était si portable que ça pour ecrire des application ne searit-ce que de bas niveau, tu peux m'expliquer pourquoi la fondation apache a eu besoin de créer une librairies dédiée et réutilsée par Subversion. On est loin des fenêtres Hein ;) ; ) ;) ;) .....
http://apr.apache.org/
Par experience j'ai participé il y a quelques années au portage d'une appli depuis OS/2 vers Windows NT, et bien bizarrement ce qui nous a couté le plus cher etait le portage des apis de plus bas niveau par exemple quand tu découvres que NT ne supporte pas la mémoire partagée et que tu dois la simuler, que les mutex ont une conception complètement différentes, ....
[^] # Re: ...
Posté par Anonyme . Évalué à 1.
Il s'agit d'un cas particulier... Ces optimisations ne sont pas applicables par les compilateurs C ?
Enfin, plus généralement, plus il y a de couches présentes à l'exécution , plus le temps d'exécution tend à s'allonger, non ? Si on ne tient pas compte de facteurs comme l'optimisation meilleure d'une machine/d'un compilateur (puisque les techniques d'optimisation pourrait être réutilisée par d'autres compilateurs) mais uniquement de la structure du code exécutable et de la méthode d'exécution (machine virtuelle ou réelle)...
Evidemment, plus les processeurs augmentent en puissance, plus la différence s'amenuise. A strictement parler, cependant, il ne s'agit pas de la question.
[^] # Re: ...
Posté par Jerome Herman . Évalué à 4.
Il tend à s'allonger si on ne fait rien oui. Mais par contre plus on a de couches disponibles plus on va pouvoir faire d'optimisations post-compilation.
En C on ne peut pas faire d'optimisation à posteriori, une fois que le porgramme est lancé, sa partie executable (ie par la partie données) ne bouge pas sauf cas super particuliers et très casse gueule tel que l'assembleur automodifiant ou le self linking dynamique.
A l'inverse les programmes tournant sur une machine virtuelle peuvent s'optimiser tout seul en permanence. Par exemple lorsqu'il passent dans une fonction ils peuvent créer une table de hashage des paramêtres passés et de leur résultats et ainsi répondre instantanément si la fonction est appelé deux fois avec les mêmes paramêtres. De même ils peuvent faire sauter un paquet de tests et donc linéariser le code. Pareillement la machine virtuelle peut conserver une empreinte de la config système et ainsi court-circuiter un paquet d'appels systèmes en n'executant pas le bytecode et en plaçant la réponse directement au bon endroit etc.
En d'autres termes on passe d'un mode de calcul de branchement, éventuellement de prédiction de branchement à un mode de branchement direct.
A l'heure actuelle ces optimisations post-execution ne sont pas encore très rentables par rapport à la complexité qu'elles induisent dans la machine virtuelle, mais elles le deviennent. Sur des protocoles de communications complexes il est certain que les machines virtuelles finiront par battre à plate couture les programmes compilés traditionnels gràce a des meccanisme de prise d'empreinte mémoire et système qui leur permettront d'éviter la grosse majorité des tests.
[^] # Re: ...
Posté par Anonyme . Évalué à 3.
La différence tient donc du fait que la machine virtuelle, de nature logique, est de conception plus dynamique - donc plus facile et plus rapide - à gérer (nouvelle version d'une machine virtuelle -> nouveau paquet, nouvelle version d'une machine réelle -> nouveau modèle).
Sinon, ces optimisations post-génération de code exécutables sont quand même applicables aux machines physiques ?
[^] # Re: ...
Posté par Ontologia (site web personnel) . Évalué à 4.
Soit tu met des primitives dans le processeur et j'ose pas imaginer les conséquences...
Soit tu te débrouilles pour que le compilateur intègre les techniques que Kha citait plus haut. Et là ça devient assez chaud. Ca n'est possible à mon avis qu'avec :
- Un compilateur utilisant massivement une analyse de flot
- Un compilateur qui dispose de bonnes informations, à priori sur les statistiques d'utilisation du code (ie. distribution des valeurs les plus courantes en entrée des fonctions).
De là, soit tu t'amuses à compiler ton programme, à lui balancer une batterie de tests - en espérant qu'ils soient représentatifs - et à recompiler celui-ci en connaissance de cause, ou soit tu lui colle une sémantique du type contrat, définition d'intervals/ensemble afin d'avoir de bonnes infos sur le comportement de ton code.
Dans tous les cas c'est problématique, et faut bien analyser
- Quels appels extérieurs cela implique pour optimiser leur appel (table de hashage, etc...) et le cas échant, il faut que l'OS soit optimisé pour ça
- Les problèmes de mise à jour des données (table de hashage sur appels de fonction).
Dans le compilateur, il faudrait que l'analyse de flot analyse les sous graphes potentiellement très consommateurs en calculant leur complexité ainsi que les possibilités de "distributions" des paramètres dans l'intervalle possible (typiquement , on peut déduire, dans certains cas, par un moteur logique, que le param appliqué à la fonction f, dans le contexte se trouvera dans l'interval [20;100]).
Avec ça, le compilateur peut poser un système de table de hashage dessus, voire découper le code de la méthode en petit bout et la spécialiser aux seuls paramètres qui change.
Merci pour l'idée Kha, ça serait sympa à intégrer au compilo...
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: ...
Posté par Philippe F (site web personnel) . Évalué à 6.
C'est plus ou moins ce qu'a fait transmeta avec son code morphing. Au final, c'etait beaucoup plus lent qu'un processeur pur.
<<
- Un compilateur utilisant massivement une analyse de flot
- Un compilateur qui dispose de bonnes informations, à priori sur les statistiques d'utilisation du code (ie. distribution des valeurs les plus courantes en entrée des fonctions).
>>
Et on en revient a la necessite d'avoir une grammaire du langage de programmation qui soit suffisamment expressive. Sinon, ces optimisations sont tres difficiles a mettre en oeuvre.
C'est bien pour cela que le JIT a attendu des langages comme Java ou C# pour devenir populaire.
<<
Dans le compilateur, il faudrait que l'analyse de flot analyse les sous graphes potentiellement très consommateurs en calculant leur complexité ainsi que les possibilités de "distributions" des paramètres dans l'intervalle possible (typiquement , on peut déduire, dans certains cas, par un moteur logique, que le param appliqué à la fonction f, dans le contexte se trouvera dans l'interval [20;100]).
>>
C'est tres proche de ce que fait le compilateur OCaml. C'est d'ailleurs ce qui explique malgre un langage "loin de la machine", il arrive a de tres bonne perfs : il y a une analyse de code tres poussee derriere qui va bien chercher les optimisations.
Cependant, l'analyse statique restera toujours limitee. Le comportement d'un programme depend de son code et de ses parametres en entree. Une optimisation statique a la compilation ne peut optimiser que le code d'un point de vue general. Elle ne peut pas connaitre quelle fonction est appelee plus souvent dans la pratique. C'est la que les optimisations JIT interviennent. Elles regardent le code s'executer et peuvent trouver les fonctions qui sont reellement utilisees en permanence.
Le C etant compile en assembleur avant d'etre execute, toute l'information sur la notion de fonction et de variable est perdue. Meme si cette information perdurait, a terme, la grammaire du C est trop peu expressive a mon sens pour permettre des optimisations de longue haleine (pas de notion d'interface, pas de notion de dictionnaire, utilisation de pointeurs pour gerer des tableaux, utilisation de pointeurs sans types, etc).
Donc plus ca va, plus le C va etre a la rue parce qu'il ne peut guere evoluer. D'un autre cote, cette stabilite est aussi ce qui a fait son succes.
[^] # Re: ...
Posté par Ontologia (site web personnel) . Évalué à 2.
C'est bien pour cela que le JIT a attendu des langages comme Java ou C# pour devenir populaire.
On a surtout besoin de grammaires expressives.
Dans le langage auquel je pensais (toujours le même), Lisaac, la conditionnel, les briques de bases pour les boucles n'existent pas. Le compilateur ne connait que 7 primitives (-,*,/,and, or, =, >). Toute la lib est faîte avec ça.
Le if est une résolution dynamique sur les objets true et false héritant de booléan. Le compilateur l'optimise pour retomber sur un if comme en C. Ce qui fait que toutes les structures de ce type n'importe où dans le code sont optimisées. De même pour les récursives etc...
Plus ta grammaire est minimaliste, plus le compilateur se concentre sur la sémantique du code, pare que tu retombes toujours dessus quand tu fait l'analyse sémantique dans le compilateur (le micro langage interne).
Et c'est là que les optimisations sont possibles.
Le nombre de primitives dans Java et C# sont énormes, (http://isaacos.loria.fr/li_simplicity.html ), par contre le langage de la machine virtuelle est sufisament minimaliste et expressif pour que les optims soient faites dessus.
Cependant, l'analyse statique restera toujours limitee. Le comportement d'un programme depend de son code et de ses parametres en entree. Une optimisation statique a la compilation ne peut optimiser que le code d'un point de vue general. Elle ne peut pas connaitre quelle fonction est appelee plus souvent dans la pratique. C'est la que les optimisations JIT interviennent. Elles regardent le code s'executer et peuvent trouver les fonctions qui sont reellement utilisees en permanence.
Le C etant compile en assembleur avant d'etre execute, toute l'information sur la notion de fonction et de variable est perdue. Meme si cette information perdurait, a terme, la grammaire du C est trop peu expressive a mon sens pour permettre des optimisations de longue haleine (pas de notion d'interface, pas de notion de dictionnaire, utilisation de pointeurs pour gerer des tableaux, utilisation de pointeurs sans types, etc).
Donc plus ca va, plus le C va etre a la rue parce qu'il ne peut guere evoluer. D'un autre cote, cette stabilite est aussi ce qui a fait son succes.
Il y a C et C : il y a C écrit par un humain et C généré par un compilateur.
Le C écrit par un être humain exprime de la sémantique humaine : c'est à dire que le code est proche d'une représentation humaine du programme et moins un représentation adaptée à la machine.
Il est par exemple quasiment impensable qu'on s'amuse à faire un gros malloc au début et gérer les pointeurs pour faire en sorte que la mémoire cache soit utilisée au mieux. Ca devient vite ingérable. Par contre un compilateur peut le faire.
De même, souvent, tu vas utiliser des chaînes pour représenter une structure sémantique préfixée, alors que des nombres peuvent le faire, car c'est bijectif. C'est un peu ce qu'on fait dans les bases de données relationnelles.
Il est vrai qu'en l'état actuel des choses, on devrait réfléchir non à la machine virtuelle, mais à une espèce de programme possédant des informations sur son code et capable dans certains cas de générer son propre code. Mais il faut faire très attention : là où la machine virtuelle virtualise tout, il faudrait un système qui permette d'utiliser des optimisations faites par les VM seulement là et quand c'est utile.
C'est en tout cas une piste intéressante, mais le problème est qu'elle impose de connaître ton assembleur cible ou d'embarquer une part du compilateur (le back end de GCC par exemple)...
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: ...
Posté par Pierre Jarillon (site web personnel) . Évalué à 3.
C'est comme le code C généré par Lex et Yacc (Flex et bison). Je ne suis jamais parvenu très loin dans la lecture du code. Pourtant il fonctionne sacrément bien !
[^] # Transmeta
Posté par Antoine . Évalué à 3.
Non, ça n'a rien à voir avec la question posée.
Pour savoir si le "code morphing" de Transmeta était responsable d'une perte de performance, il aurait fallu comparer pour le même code C :
1) la version compilée pour x86 et exécutée via le code morphing
2) la version compilée en natif pour le processeur transmeta (donc exécutée directement)
Comme Transmeta ne dévoilait pas le jeu d'instructions de son processeur et ne fournissait pas de compilateur permettant de l'attaquer directement, personne n'a la réponse (à part peut-être Transmeta eux-mêmes).
[^] # Re: ...
Posté par Krunch (site web personnel) . Évalué à 4.
Par ailleurs, qu'est-ce que tu entends par "self linking dynamique" ? Google m'aide pas beaucoup.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: ...
Posté par Jerome Herman . Évalué à 2.
je faisais allusion aux techniques comem le fragment cache de la Dynamo. Mais c'est vrai que j'aurais du dire "Si le contexte d'exécution de focntion se représente alors ..." mais c'est vraiment très pédant, et pas forcément compréhensible en plus vu le double sens du mot contexte d'éxecution dans une discussion sur les threads (contexte au sens emplacement d'éxecution du thread et contexe au sens empreinte données+pile d'execution)
Par ailleurs, qu'est-ce que tu entends par "self linking dynamique" ? Google m'aide pas beaucoup.
C'est une des techniques les plus gore qui soit avec les bibliothèques dynamique. Il s'agit en fait de réussir à forcer une bibliothèque à se charger elle même puis à utiliser tout un tas d'effet de bord pour modifier le comportement de certaines fonctions de façon à ce que lorsque la même bibliothèque sera appelé par un autre programme, celui ci aura le comportement modifié et non le comportement initial.
Ce genre de techniques étaient utilisées de façon très light pour faire passer des message entre les processus via la biliothèque (oui ca a été possible, sous windows notamment) mais maintenant c'est fini. Ceci étant il resterait encore de très "jolies" choses à faire avec des virtual, des callback et en s'appuyant un peu sur les méccanismes du kernel.
Je n'ai pas d'exemple de ce que l'on peut faire sur un OS moderne...
[^] # Re: ...
Posté par reno . Évalué à 3.
Non, des PA-RISC si je me souviens bien.
Et pour ce qui est du gain de performances, je me suis toujours demandé s'il serait si bon si on comparait avec du code optimisé "par profil" (on execute une fois le code qui génère un profil d'execution puis on recompile le code de nouveau en exploitant le profil pour amméliorer les perf).
[^] # Re: ...
Posté par Jerome Herman . Évalué à 3.
En théorie si le profil d'execution est bien ciblé alors le code compilé repasse devant la dynamo. Cependant la Dynamo restera toujours plus performante sur les appels de fonctions déjà dans son "cache fragment". En francais : même si un a un profil d'execution très bien ciblé, le programme sera quand même obligé de faire et refaire certains tests dont le résultat peut changer, alors que la dynamo peut determiner que le résultat sera identique sans faire les calculs simpelment en comparant les contextes d'éxecution (ce qui est impossible à faire en dehors de l'exécution).
Un fouillant un poil j'ai retrouvé le doc d'origine : http://www.cs.utexas.edu/users/lin/cs380c/dynamo.pdf effectivement c'est bien sur du matériel HP que la dynamo a été implémentée en premier.
[^] # Re: ...
Posté par reno . Évalué à 1.
Oui, euh c'est quand meme la *premiere version* qui supporte le multi-CPU..
J'ai peut-être trop pris l'habitude de Sun et de leurs octoprocesseurs, mais quand on me dit 'tiens la montée en charge' et restreint au mono-CPU (si je comprends bien c'était le cas avant en mode 'natif'), je trouve ça un peu curieux.
Oui, je sais Erlang supporte plein de thread légés, mais bon si tes threads font quelque-chose, tu te retrouve facilement avec une machine a genoux..
[^] # Re: ...
Posté par agmk . Évalué à 5.
[^] # Re: ...
Posté par Jerome Herman . Évalué à 4.
Oui et non, C'est la première version ou chaque machine Erlang peut s'appuyer nativement sur plusieurs CPU sans efforts de la part du programmeur. Il a toujorus été extrèmement facile de faire tourner un programme Erlang sur plusieurs CPU voir sur plusieurs machines distinctes en mettant les différents process communicants sur différentes machines. Au final il était tout à fait possible de tirer parti de l'architecture complète (mais il est vrai que celà demandait une certainne finesse programmatique).
[^] # Re: ...
Posté par reno . Évalué à 4.
Je comprends bien qu'avant en utilisant des interfaces differentes on pouvait utiliser aussi plusieurs CPU.
[^] # Comment casser le mythe de rapidité de Fibonacci :-)
Posté par darkleon (site web personnel) . Évalué à 10.
Langage C, gcc -O3
Java
Interprétation naïve génératrice de Troll : Java est plus rapide que C
En fait, en faisant un programme en C plus sioux qui stocke les résultats intermédiaires dans une pile on arrive a des perfs équivalentes ou meilleures (j'ai la flemme de faire le prog, mais j'ai déjà essayé), de même le programme est écrit sous forme récursive, mais
Langage C linéaire, gcc -O3
Java Linéaire
Finallement, on retient :
- Il faut toujours choisir l'algorithme le moins naïf, si ce n'est pas couteux pour la conception du programme (shell sort contre bubble sort par ex pour 2 tri sans appels de piles)
- Il faut choisir le langage qui offre le meilleur compromis paresse du programmeur/rapidité d'éxecution.
Franchement, je ne connais pas Erlang, mais pour faire des agents distribués concurrents, je pense que j'aurais un résultat concret et plus fiable plus rapidement en apprenant Erlang et sa méthode de pensée, que de le coder en pur C.
Et puis ces discours étaient les mêmes dans les années 90 entre l'asm et le C sur 68k/80x86 :-))) et le C a gagné, cas son niveau d'abstraction ;-) permet d'être plus productif que de l'asm pur.
<µTroll>
Vive l'ASM et les démo framerate 60fps sur amiga et les démos ST sont pourries :-)))) (je dis ça par nostalgie, tout le monde est mort maintenant !)
</µTroll>
[^] # Re: Comment casser le mythe de rapidité de Fibonacci :-)
Posté par hocwp (site web personnel) . Évalué à 4.
(defun fib (n) (if (<= n 1) 1 (+ (fib (- n 1)) (fib (- n 2))))) (defun memo (fn) (let ((table (make-hash-table))) #'(lambda (x) (multiple-value-bind (val found-p) (gethash x table) (if found-p val (setf (gethash x table) (funcall fn x))))))) (defun memoize (fn-name) (setf (symbol-function fn-name) (memo (symbol-function fn-name))))CL-USER> (memoize 'fib) #<CLOSURE (LAMBDA (X)) {A748FC5}> CL-USER> (time (fib 1000)) Evaluation took: 0.002 seconds of real time 0.001999 seconds of user run time 0.0 seconds of system run time 0 page faults and 135,064 bytes consed. 7033036771142281582183525487718... CL-USER> (time (fib 1000)) ; 2eme appel -> instantané Evaluation took: 0.0 seconds of real time 0.0 seconds of user run time 0.0 seconds of system run time 0 page faults and 0 bytes consed. 7033036771142281582183525487718...Comme quoi le choix de l'algorithme est parfois (beaucoup) plus important que le langage. /me range sont PAIP, enfonce des portes ouvertes et --> [ ][^] # Re: Comment casser le mythe de rapidité de Fibonacci :-)
Posté par darkleon (site web personnel) . Évalué à 4.
Le problème, c'est que ce genre d'optimisation est envisageable dans une librairie système, ou un programme de calcul lourd, mais dans la vie de tous les jours au boulot, tu programmes de manière naïve (il faut maintenir le code après, et les optimisations rende le déroulement du programme moins lisible).
D'autant plus que la meilleure optimisation dans ce cas là est de transformer l'appel récursif en boucle -> gain de vitesse ET de mémoire.
Alors que ton exemple permet de gagner en vitesse, mais au détriment de la mémoire (et encore ça se discute, moins de pile à gérer)
Le principe de la table de hash pour stocker les résultats intermédiaires d'appels récursifs est quand même une trés bonne solution en général.
[^] # Re: Comment casser le mythe de rapidité de Fibonacci :-)
Posté par hocwp (site web personnel) . Évalué à 3.
Par contre, je pense que ça peut servir de savoir qu'on a ce genre d'outil à portée de main sans rien changer au code de base (enfin, en Lisp en tout cas et à condition qu'il soit purement fonctionnel).
Sinon, du point de vue mémoire, entre stocker 1000 entiers dans une hash table et refaire un très grand nombre de fois le même calcul, le choix est vite fait à mon avis.
[^] # Re: Comment casser le mythe de rapidité de Fibonacci :-)
Posté par darkleon (site web personnel) . Évalué à 3.
Je ne pense pas a priori dans ce cas précis que ta fonction memoize apporte un énorme gain, je pense même que normalement, en faisant 2 appels naïf, le deuxième devrait être "immédiat" sans le memoize.
Je serais interessé d'avoir les temps sans passer par la hash table pour confirmer cette hypothése.
Dommage que je ne digére vraiment pas la syntaxe lisp (et ce ne sont pas les parenthéses qui me dérange le plus) et l'ordre prefixe.
En fait ça me fait penser à une démo de math, sauf qu'il n'y a pas de symboles graphiques (Sigma, PI, QuelqueSoit, barre d'intégrale, etc...) pour faire des points d'ACCROCHE à l'oeil et l'ordre infixe.
< troll>
Et ceux qui me dise que la polonaise inversé, c'est le top, pourquoi l'écriture mathématique est infixe et n'est pas en polonaise inversée, hein, si conceptuellement c'était mieux pour réflechir.
C'est uniquement une facilité pour la conception des programmes de parsing, le cerveau humain ne pense pas polonaise inversée, bien qu'avec l'habitude, on se dit que c'est aussi simple (c'est juste que le cerveau fait la transformation infixe->postfixe de manière plus mécanique avec l'usage et que sur les vielles calculatrices SANS mémoire, c'est plus pratique pour évaluer une expression, au passage ça évite l'usage des parenthèse, mais LISP a raté le coche de ce côté là :-)))))
< /troll>
C'est ce que je disais, ça se discute :-)
Si au lieu d'un entier, c'est tout une structure à stocker, la taille de la pile qu'il faudra peut être augmenter avant l'execution du programme, etc...
A chaque cas sa solution, et je crois que c'est un peu l'esprit qui se dégage sur cette news.
[^] # Re: Comment casser le mythe de rapidité de Fibonacci :-)
Posté par hocwp (site web personnel) . Évalué à 2.
En fait, tu commences par calculer fib(999), puis pour calculer fib(999) tu calcules fib(998), etc, etc -> tu ne descends qu'un fois pour calculer chaque valeur de fib jusqu'à 1 et ensuite tout ce que tu calcules est déjà stocké dans la table de hachage => gain de temps là où normalement tu devrais calculer chaque valeur à chaque fois en remontant.
Sinon, niveau optimisation, je n'ai rien rajouté (juste compilé chaque fonction).
Par contre, sans la mémoization, fib(44) met environ 80 secondes sur ma machine avec la version recursive de base (je n'ai pas encore eu le temps de tester la version avec une boucle) et j'ai arrété fib(1000) ;-)
Pour la notation infix, j'en ai déjà parlé ici, mais tu as des macros qui te permettent de faire tes calculs dans cette notation, et c'est le compilateur qui se charge de les transformer en notation prefix avec de les évaluer.
http://www.cs.cmu.edu/afs/cs/project/ai-repository/ai/lang/l(...)
Oui, je crois que ça resume bien la situation.
[^] # Re: Comment casser le mythe de rapidité de Fibonacci :-)
Posté par gasche . Évalué à 0.
Et justement, je n'ai pas vraiment compris l'intérêt. N'est-ce pas beaucoup de bruit pour pas grand chose ?
(vous pourriez m'expliquer comment on met du code indenté ? Avec ou sans blockquotes ça foire à la prévisualsation)
[^] # Re: Comment casser le mythe de rapidité de Fibonacci :-)
Posté par Mildred (site web personnel) . Évalué à 3.
[^] # Re: Comment casser le mythe de rapidité de Fibonacci :-)
Posté par hocwp (site web personnel) . Évalué à 1.
(Pour le code indenté: texte avec du html sans retour chariot + balise <pre>code</pre>).
Sinon, effectivement, désolé pour le bruit : on s'éloigne du sujet.
[^] # Re: Comment casser le mythe de rapidité de Fibonacci :-)
Posté par Thomas Douillard . Évalué à 2.
par exemple, http://www.google.fr/search?hs=z6b&hl=fr&c2coff=1&am(...)
Le principe de base est de supprimer la recursivite en stockant les resultats intermediaire, le tout en s calulant ces resultat de sorte qu on ait besoin a chaque fois que de resultats deja en memoire. En version la plus optimiae on utilise que des tableaux.
Desole pour les accents, leger probleme de config ...
[^] # Re: Comment casser le mythe de rapidité de Fibonacci :-)
Posté par fmaz fmaz . Évalué à 4.
pourquoi tant de haine^Wtable de hashage.
fibo, la bonne façon de le coder, c'est de ne pas calculer
fib(n) mais de calculer fibAux n= ( fib (n-1), fib n )
parce qu'à l'étape d'après, on a directement
fibAux (n+1) = (fib n, fib (n-1)+fib n).
En chameau, ça donne un truc du genre:
let rec fibAux n =
if n=1 then (1,1)
else
let (a,b)=fibAux (n-1) in (b,a+b);;
let fib n=
if n=0 then 1
else
let (a,b)=fibAux n in b;;
[^] # Re: Comment casser le mythe de rapidité de Fibonacci :-)
Posté par Krunch (site web personnel) . Évalué à 2.
(j'ai failli faire le même commentaire cette nuit (mais avec du Scheme) avant de comprendre que c'était hors sujet :)
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: Comment casser le mythe de rapidité de Fibonacci :-)
Posté par Vivi (site web personnel) . Évalué à 4.
en chameau, en utilisant la bibliothèque de calculs avec les grands nombres, ça donne ceci:
open Num
let pmul (a, b) (c, d) =
let ac = a */ c in
(ac +/ a */ d +/ b */ c,
ac +/ b */ d)
let rec pow x a n =
if n = 0
then a
else
pow
(pmul x x)
(if n mod 2 = 0 then a else pmul a x)
(n / 2)
let fib n =
if n < 0 then invalid_arg "fib" ;
fst (pow (Int 1, Int 0) (Int 0, Int 1) n)
let _ =
print_endline (string_of_num (fib 100000))
Pour cacluler fib(100000) chez moi ça va 10× plus vite qu'avec l'algo linéaire.
[^] # Re: Comment casser le mythe de rapidité de Fibonacci :-)
Posté par fmaz fmaz . Évalué à 2.
Et ben moi, j'ai un algo encore plus mieux bien.
Comme la suite de Fibonacci est linéaire, on sait la résoudre
analytiquement.
a=(1+sqrt(5))/2.;
b=(1-sqrt(5))/2.;
l=(1+.sqrt(5))/(2*sqrt(5));
fib(n)=l*a^n+(1-l)*b^n;
Paf.
Alors, après, tu fais tes multiplications et ton exponentiation comme tu veux.
Comment ça, ça n'a plus rien a voir avec la problématique initiale ?
P.S. Je suis nul en calcul donc en plus le truc que j'ai écrit doit être faux.
[^] # Re: Comment casser le mythe de rapidité de Fibonacci :-)
Posté par Ontologia (site web personnel) . Évalué à 2.
Petite difficulté informatique : ne pas mettre les calculs par terre à cause des arrondis.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Comment casser le mythe de rapidité de Fibonacci :-)
Posté par hocwp (site web personnel) . Évalué à 2.
[^] # Re: Comment casser le mythe de rapidité de Fibonacci :-)
Posté par Krunch (site web personnel) . Évalué à 5.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: Comment casser le mythe de rapidité de Fibonacci :-)
Posté par lcld . Évalué à 2.
De toute façon, ici, la meilleure solution au solution problème reste encore d'exprimer la suite en fonction de n plutôt qu'en fonction des termes précédents -> algo en O(1) (quoique ça dépende de l'implémentation de l'exponentielle...).
La comparaison est mauvaise : la principale raison pour laquelle le C a gagné est que l'assembleur n'est pas portable et qu'un langage assembleur est censé avoir une durée de vie limitée.
Cela dit, il y a quand même un point qui me gêne. Comment justifier cette surenchère de couches alors qu'il y a de nombreuses tâches qui ne sont pas parallélisables (ou difficilement parallélisables) et que la puissance des coeurs CPU augmente de plus en plus lentement.
Par exemple : réactivité des IHM, compression de données, etc.
[^] # Re: Comment casser le mythe de rapidité de Fibonacci :-)
Posté par darkleon (site web personnel) . Évalué à 3.
C'est plutôt le problème des langages fonctionnels qui ne "connaissent pas la boucle", vu que la récursivité terminale, c'est comment transformer une boucle en appel récursif et vice-versa.
Ce n'est vraiment pas le but du compilateur C de chercher à optimiser la structure du programme.
Le but c'est quand même d'avoir un "macro assembleur" qui te garantisse que les séquences d'intructions écrites seront executées dans le même ordre (en dehors des optimisations qui généralement sont trés locale pré-chargement de registre pendant un long calcul pour que la donnée soit disponible au moment ou le décodeur en a besoin par exemple).
Pour moi, le C, c'est quand même le contrôle le plus direct sur ta machine après l'assembleur. Ce n'est pas fait pour être agréable, c'est fait pour faire ce que tu lui dit de faire (quoique des fois on se le demande :-)
C'est grosso modo ce qui se passe avec le C actuellement. Ton code n'est plus dépendant d'un processeur, mais d'un ensemble OS+librairies. Si sur du matos obscur ta librairie préférée n'est pas porté, tu peux toujours t'assoir sur la portabilité du C (sans aller jusque là, un programme écrit sur win3.1 en MFC, je ne crois pas qu'il soit trop portable).
Le plus drôle, c'est qu'on est un peu coincé avec l'architecture x86 parce que justement les constructeurs veulent garder cette sacro sainte comptabilité binaire, et en plus on a toujours le bios merdique remaquillé de 82 (à l'époque c'était peut être pas merdique, mais maintenant ça l'est!) avec tous les extensions un peu bidouille pour supporter le matériel moderne avec des spécifcation de 82.
(C'est un peu pareil avec les autres ISA).
Pratiquement partout sur cette page, tout le monde que le top, c'est l'association ASM+C+(langage de haut niveau)+langage de script en même temps, ce sont des couches "conceptuelles", puisque in fine, c'est toujours une séquence de code ASM (de plus en plus grosse) qui est executée.
Tu devrais jeter un coup d'oeil sur ISAAC (j'avoue, à part la démo, je ne suis pas allé beaucoup plus loin pour l'instant).
En résumé, le principe est que tu conçois ton application en haut niveau, et le compilo ISAAC se "démerde" pour transformer le bousin en code C super optimisé (faisant sauter toutes les couches d'abstraction justement) difficilement lisible pour un être humain.
L'interêt, c'est que tu obtiens 95% de la performance d'un programme C écrit par LE génie du C et de l'algo qui a amoureusement optimisé en PalucheProcessing(TM) chaque ligne de code et chaque algo et qui a passé des heures à le faire.
Avec Lisaac, tu ne t'occupe plus de la mémoire, tu as pleins d'algo haut-niveau pour penser plus conceptuel, du coup tu es plus productif, et ton code généré n'aura pas d'erreurs techniques (gestion mémoire principalement). Evidemment si on te demande de coder 2+3 et que tu code 2+2, aucun langage ne peut t'aider :-)
On peut faire le // avec mon exemple de Fibonacci, ou le même code "naïf" est plus rapide en JAVA qu'en C, car la JVM stocke des données intermédiaires sans te le dire.
On peut toujours rendre le code C plus rapide, la question, c'est à quel prix et au bout de combien de temps ?
[^] # Re: Comment casser le mythe de rapidité de Fibonacci :-)
Posté par Krunch (site web personnel) . Évalué à 2.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: Comment casser le mythe de rapidité de Fibonacci :-)
Posté par reno . Évalué à 2.
>- Il faut toujours choisir l'algorithme le moins naïf, si ce n'est pas couteux pour la conception du programme (shell sort contre bubble sort par ex pour 2 tri sans appels de piles)
*NON*, il faut choisir l'algorithme le plus simple, le plus maintenable en mettant une interface bien propre.
Mesurer les temps d'executions.
Si ce n'est pas suffisant: optimiser la ou c'est nécéssaire.
Le choix du language est plus difficile au niveau performance car si tu prends un langage lent genre Ruby, il y a aussi le risque du probleme des "milles coupures": pas un point chaud à optimiser (ça c'est pas trop compliqué) mais être lent partout et la, il n'y a plus qu'à réécrire.
Mais surtout il faut trouver un language accepté par ton chef donc D, Scala, Ruby, Limbo et autre Erlang, ce n'est pas gagné..
[^] # à propos de Erlang
Posté par cbon linux . Évalué à -3.
Le compilo Erlang est-il optimisé ?
Les temps de compils sont-ils longs ?
Erlang a-t'il besoin de beaucoup de cpu et de RAM ?
Quels sont enfin les gros avantages de Erlang ?
Merci ;)
# Eheh
Posté par Anonyme . Évalué à 1.
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
Posté par brouillon . Évalué à 3.
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
Posté par Anonyme . Évalué à 3.
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
Posté par brouillon . Évalué à 3.
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
Posté par reno . Évalué à 3.
>> é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
Posté par brouillon . Évalué à 4.
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
Posté par reno . Évalué à 2.
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
Posté par olgk . Évalué à 10.
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
Posté par golum . Évalué à 3.
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
Posté par olgk . Évalué à 4.
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
Posté par cbon linux . Évalué à -3.
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).
[^] # Re: Eheh
Posté par Guillaume Knispel . Évalué à 8.
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
Posté par brouillon . Évalué à 2.
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
Posté par tene . Évalué à 2.
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
Posté par Thomas Hervé . Évalué à 3.
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
Posté par beesse . Évalué à -1.
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
Posté par agmk . Évalué à 9.
>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" ;-)).
[^] # Re: Eheh
Posté par tontonflingueur . Évalué à 1.
[^] # Re: Eheh
Posté par Thomas Douillard . Évalué à 3.
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
Posté par agmk . Évalué à 3.
[^] # Re: Eheh
Posté par TImaniac (site web personnel) . Évalué à 6.
Mono l'environnement d'exécution est écrit en C
(g)mcs le compilateur C# du projet Mono est écrit en C#.
[^] # Re: Eheh
Posté par Vivi (site web personnel) . Évalué à 3.
[^] # Re: Eheh
Posté par olgk . Évalué à 1.
# Bindings...
Posté par sylware . Évalué à 2.
[^] # Re: Bindings...
Posté par agmk . Évalué à 4.
[^] # Re: Bindings...
Posté par sylware . Évalué à 0.
# Libre
Posté par Gof (site web personnel) . Évalué à 3.
http://www.erlang.org/faq/x213.html#AEN235
[^] # Re: Libre
Posté par TImaniac (site web personnel) . Évalué à 5.
[^] # Re: Libre
Posté par cbon linux . Évalué à 1.
http://www.vnunet.com/vnunet/news/2156205/sun-promises-open-source-java
"It's not a question of whether we'll open source Java, the question is how, " Schwartz told delegates in his opening keynote at the tradeshow.
[^] # Re: Libre
Posté par GuieA_7 (site web personnel) . Évalué à 3.
Wait and see donc...
[^] # Re: Libre
Posté par Arthur Accroc . Évalué à 2.
À moins que la question ne soit surtout quand.
Vont-ils le faire tant que Java a du succès, où vont-ils attendre qu'il soit sur la pente descendante, voire au fond du gouffre ?
Ayons une pensée pour Plan 9, qui est Open Source, maintenant...
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
# pratiquement Erlang ça donne quoi ?
Posté par cbon linux . Évalué à -6.
C'est beau la théorie mais moi chui un gars pratique ;) :
Le compilo Erlang est-il optimisé ?
Les temps de compils sont-ils longs ?
Erlang a-t'il besoin de beaucoup de cpu et de RAM ?
Quels sont enfin les gros avantages de Erlang ?
Merci ;)
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.