lasher a écrit 2738 commentaires

Je ne dis pas que c'est nécessairement réalisable (enfin, réalisable selon des contraintes du genre coût, consommation supplémentaire, etc.), mais ce que je dis en tout cas, c'est que tous les papiers que j'ai pu lire concernant les mémoires transactionnelles, et qui se faisaient en soft avaient la plupart du temps un, voire deux problèmes :

- ils plombent les perfs dans leurs implémentations actuelles; et parfois,
- ils rajoutent (lire : surchargent) de nouveaux mots-clefs dans les langages (j'ai souvenir d'une implém de mémoire transactionnelle dans une JVM qui rajoutait encore des qualificatifs en plus des synchronize et autres joyeusetés).

Fortress ça vit encore ? Et mis à part pour le calcul scientifique, ça sert à quelque chose ? :)

« Un langage avec des thread (dépassé, voir mémoire transactionnel, Scoop, etc...) »

Faudrait arrêter un peu de dire des bêtises des fois. :)

Les mémoires transactionnelles, dans le principe c'est très bien, mais en pratique ça offre une perte de performances, et ce sera toujours le cas tant que ce sera fait en soft uniquement. Il faudrait d'abord convaincre les constructeurs de matériel ...

Sinon, pour le moment en tout cas, dès qu'il s'agit de faire de la perf, malheureusement, utiliser des threads (et donc un modèle non-déterministe) est un peu obligatoire.

J'attends beaucoup de trucs genre GCD et tout ce qui est closures cependant. Le boulot fait dans C# à ce niveau pour pouvoir générer du parallélisme est assez intéressant.

Ben oui, mais c'est un peu le seul endroit où le compilateur peut faire quelque chose finalement : insérer des symboles pour le linker dans les fichiers objet. Et si sur de GROS codes ça explose, sur des codes de taille raisonnable ça va encore (et surtout, la compilation avec ipo peut être partielle : une partie des fichiers objet qui est compilée de façon classique, et une autre avec ipo).

Est-ce vraiment pour des raisons de perf que GCC (au sens Compiler Collection) ne permet pas ça ?

« La compilation par fichier .c a été faite à cause de la faiblesse des machines de l'époque. Depuis la définition du C, les cpus ont gagné en vitesse, et la raison du saucissonnage du code n'a plus lieu d'être. »

Je ne suis pas tout à fait d'accord. Lorsqu'on active les optimisations inter-procédurales, c'est-à-dire l'optimisation de code entre des fichiers objets séparés, si le code est vraiment gros, ça peut vraiment faire exploser le temps de compilation. Au point que parfois c'est carrément le compilateur qui abandonne (j'ai déjà vu le cas se présenter avec les compilateurs d'Intel pour Fortran et C, avec des codes assez énormes, et où on avait activé l'IPO).

Peut-être pas : a priori sous Minix 3, quand un pilote plante, un démon finit par le détecter et « reboote » le pilote qui ne répond plus.

À ma connaissance, Apple a surtout aidé au dév de gcc pour y rajouter le support d'AltiVec.

Oui enfin comme Fortran 77 quoi.


.
.
.


Grmbl. /me repart lire du code écrit il y a moins de 3 ans en Fortran. :-/

Oui alors là par contre je ne suis pas du tout d'accord.

Un compilateur sur une machine Out-of-Order a justement *moins* de boulot à fournir, vu que le moteur OoO matériel se charge de rendre moins moche un code « mal généré ».

Pour donner un ordre d'idée, sur une archi certes quasi-morte, à savoir l'Itanium 2, la qualité du code généré par gcc comparée à celle d'icc [1] est carrément lamentable. Le compilateur d'Intel dans ce cas est en moyenne 3 fois plus performant que gcc. Bien sûr, il y a plusieurs raisons :
1/ Plus de dévs pour gcc/x86 (mais là je renvoie à gcc/PowerPC qui se débrouille plutôt bien, et je suis sûr que l'OoO y est pour beaucoup)
2/ L'Itanium 2 n'est pas une machine très répandue (et pour cause), ce qui est finalement une variation sur 1/. :)

N'empêche : l'Itanium 2 a une architecture VLIW et superscalaire, et dont les seules opérations out-of-order sont liées à la mémoire. Presque tout est laissé au compilateur, et si celui-ci se débrouille mal pour la génération de code, alors le programme résultant sera vraiment mauvais.

Sur x86, l'OoO limite vraiment la casse.

[1] Le compilateur du constructeur (Intel), donc évidemment il y a un avantage net pour ce dernier, qui possède le modèle machine du CPU

Tout à fait, et ça permet ensuite d'être root. C'est une feature très sympathique. :P

Bouais. Pas vraiment. Au moment de l'édition de liens, ton code assembleur est donc lié aux bibliothèques que tu utilises (libc, etc.), et du code supplémentaire est généré par l'éditeur de liens. Sans parler du fait que parfois certaines mnémoniques, pourtant différentes au niveau ASM sont traduite dans le même opcode au niveau binaire.

Je suis tout à fait d'accord avec toi, c'est d'ailleurs pour ça que j'écris tous mes programmes en assembleur. Cependant, il y a encore trop d'abstraction, donc je crois que je vais finir par tout écrire directement avec les opcodes.

Oui, et ? J'ai passé 1 an et demi sur un noyau de calcul. À tout péter, je dois avoir au final 50 lignes « utiles ». Sauf qu'en fait, la moindre modif de code implique une différence importante en termes de perf. Comment tu évalues ça ? :)

Évidemment je fais exprès de prendre un cas extrême. L'autre bout de la chaîne serait du code généré à 90% par un IDE (génération des setters/getters, refactorisation de code semi-automatique, etc.). Sans parler que quand un modèle essaie de parler de « mois-hommes » je pense directement au « Mythical Man-Month » de Brooks.

personne ne regrettera ce truc

J'attends de voir, très honnêtement. Parce que tout de même, OpenMP n'existe pas que pour C++ et C, mais aussi (et surtout ? :) ) pour Fortran. gfortran va-t-il profiter de Grand Central ? Je ne crois pas ... :)

Je ne vois pas comment deux ISA aussi différentes que ia64 et x86_64 pourraient converger.

Ia64 est VLIW+superscalaire, in-order (sauf pour certaines opérations mémoire), là où x86 est superscalaire out-of-order. Le seul truc qui se rapproche "un peu" (mais alors juste un peu) de l'Itanium pourrait à la limite être le Larrabee, mais uniquement parce qu'il s'agit d'un proc superscalaire in-order lui aussi.

Après, si par converger tu veux dire qu'un jour l'ISA x86 aura des instructions prédicatées et qu'on retournera à du many core in-order, c'est bien possible, mais on sera toujours loin de l'ia64 ...

Putain.

« se moque-t-on », bordel.

Un code écrit comme un cochon, même libre, c'est difficile à reprendre. Et pas mal de boites font appel à des prestas pour développer une application en interne (elle peut être libre mais ça ne change rien au fait que la boite l'utilise en interne, par ex). De ce côté-ci, propriétaire ou pas, même si tu as la possibilité d'engager ensuite un autre presta pour maintenir le code, tu es passé d'une servitude à une autre : on passe de « je dépends d'un soft proprio » à « je dépends d'un prestataire précis ». Le deuxième cas est sans doute « moins pire », car si vraiment ça ne va pas, on peut toujours changer, mais ça n'empêche pas que ça coûte cher, voire très cher de faire maintenir un soft. Surtout si ladite boite est la seule à l'utiliser.

Enfin, pour une utilisation desktop, même si je suis d'accord qu'on n'aura pas d'accélération 3D correcte sans le RSX, le Cell peut faire de très belles choses pour ce qui est de l'accélération 2D

A la base la PS3 ne devait pas avoir de GPU, et tout devait être fait avec les SPE. On a sans doute fait remarquer à Sony que c'était déjà assez compliqué à programmer comme ça, sans en plus avoir à gérer tout ce qui est graphique avec les SPE. Donc faire de la 3D avec le Cell c'est tout à fait possible. D'ailleurs, M. Abrash a fait de même pour OpenGL sur archi x86 avec juste SSE (bien entendu dans ce dernier cas c'est beaucoup moins rapide qu'avec une carte graphique, mais c'est utile dans certains cas).

Nous avons 2 PS3 au labo pour nos tests sur Cell. La raison est très simple : si nous voulons acheter des Cell "complets" chez IBM, c'est TRES cher, alors que pour jouer avec l'archi PowerPC PPE/SPE, une console suffit.

Pourquoi "grep" ? Alors que '/' en mode commande sert justement à ça
(ou bien l'utilisation d'*' et de 'n')...

Et puis je vois pas trop ce que tu reproches aux ctags (si ce n'est que le raccourci pour s'en servir n'est pas super adapté aux claviers azerty).

Bof, pas pire que le Vegemite australien ... (Bon ok, j'aime pas non plus :))

Ça veut dire quoi, « trop mal » ?

>> Si tu n'appliques pas la loi, pourquoi tu te plains de travailler plus et reproche en même temps à un chercheur de le faire ?

>Je ne reproche pas aux chercheurs de le faire. Je reproche de mélanger ce que certains décident de faire et leur contrat de travail.

La nature même du travail de chercheur fait que, quel que soit le volume horaire déclaré sur ton contrat, si tu veux satisfaire au tristement célèbre « publish or perish » (qui est une connerie monumentale à mon avis...), tu n'as pas d'autre choix. Comme les idées ne viennent pas forcément en continu, les journées de recherche sont très irrégulières. Une fois une idée trouvée, sa mise en application peut prendre pas mal de temps (et dans beaucoup de cas, ça se rapproche de l'ingénierie).

Soit dit en passant, comme nous sommes en août, il y a officiellement fermeture administrative de la fac où je bosse (avec exception pour ceux qui ont demandé à pouvoir venir de 9h à 17h ...), mais le reste de l'année, oui, je suis couvert jour & nuit. Si si. Tant mieux, parce que les nuits blanches passée à finir la rédaction d'un article sont rares, mais arrivent régulièrement.

Oui, mais Knuth a arrêté d'offrir cette récompense, parce que les gens n'encaissaient jamais le chèque, et préféraient l'encadrer. :)

[mode capello accent='en']
Capello wins
[/mode]