Citation:
Envoyé par
fefe
Si je voulais etre malhonnete je te demanderais de faire l'experience suivante:
- CPU d'il y a 10 ans avec compilo d'il y a 10 ans
- CPU d'il y a 10 ans avec compilo d'aujourd'hui
- CPU d'aujourd'hui avec compilo d'il y a 10 ans
- CPU d'aujourd'hui avec compilo d'aujourd'hui
C'est marrant, c'est exactement le genre de comparaison que j'allais proposer.
Citation:
en 10 ans le CPU aura probablement change ses perfs de >2x,
Tu le sais que c'est malhonnête : le proc va gagner parce que sa fréquence aura augmenté (ce qui est possible pour deux raisons, micro archi et process) et ses caches auront fait x10 en taille au minimum (je parle caches L2/L3).
Donc les seules comparaisons intéressantes seraient à CPU égal, compilos différents. Mais même là c'est biaisé : qui vérifie que son compilo marche encore bien sur un P5 ?
Je pense quand même que tu as raison sur le fond : ce sont plus les avancées des processeurs qui ont fait grimper les performances que les avancées des compilos.
Citation:
alors que je doute que le compilateur reussisse le meme tour de force en 10 ans, et ce meme si c'est du code susceptible d'etre vectorise (je parle d'applis completes bien sur, pas de kernels).
C'est une évidence ce que tu dis : tu as une limite, celle du processeur que tu cibles (mauvaise foi inside).
Citation:
Meme si on prend SPEC, sur lequel tout le monde aussi bien en compil qu'en hardware a beaucoup bosse (et avec un ensemble de donne fixe donc PGO est utilisable), je doute que les ameliorations des compilos soient comparables aux ameliorations des CPUs. Le seul cas que je connaisse sur SPEC ou il y ait eu des ameliorations importantes est un cas de loop inversion (qui sent assez fort la triche:) parce que peu appliquable en dehors de ce bench particulier).
Tu parles du "truc" de Sun ? J'avais cru qu'il s'agissait d'une astuce multi CPU, mais j'avoue que ce genre de x2 sur un score ne me donne pas envie de creuser.
Citation:
Comme je l'ai introduit c'est une comparaison malhonnete, ce genre de caracteristiques n'a jamais ete attendue d'un compilateur x86 (tout du moins sur les 10 ans passes), surtout que les CPUs ont investi une quantite tres importante de hardware qui justement est utilise a des fins d'optimisations qui overlap avec les capacites du compilateur.
C'est d'ailleurs un point qui m'ennuie : les designers font des benchmarks avec le meilleur compilo qu'ils trouvent et en déduisent des choses. Ils oublient juste qu'ils se trainent des artefacts de génération datant d'une génération précédente et/ou des benchmarks devenus idiots (dans le monde dans lequel je bosse, on sort à peine de Dhrystone :|).
Je suis complètement d'accord avec toi sur le fait que le MT massif va devoir remonter du programmeur vers le compilateur, cependant cela nous ramène à ce que je disais, il va falloir aller au-delà du langage C et aussi rééduquer les programmeurs qui pour 99% d'entre eux n'ont même pas la notion de ce qu'est un cache de données ou le coût du dispatch dynamique.
Citation:
Une autre opportunite a ete avec la vectorisation, mais malheureusement les jeux d'instructions SIMD disponibles sur les x86 n'ont jamais ete concus pour etre compilables efficacement (on peut moderer en disant que ce n'etait pas leur objet primaire). Le resultat est que malgre les connaissances importantes dans le domaine de la vectorisation automatique, les benefices ont ete assez ridicules sur tout ce qui n'a pas ete reecrit a la main.
Ces jeux d'instructions ont été hélas pensés pour l'écriture à la main de CODEC. Et les formats de données associés n'existent pas en C standard. D'un autre côté si on regarde ce que fait le compilo d'IBM voire même gcc, pour les SPU du CELL en utilisant des extensions de C, c'est quand même très intéressant.
Citation:
Dans le 2 eme cas il est effectivement difficile d'imaginer une solution ou on attendra un taux de bonnes speculation suffisant pour ameliorer l'efficacite (mais c'est un sujet de recherche tres actif, tant du cote soft que hard). En revanche dans le premier cas, il y a bon nombre d'applications qui ne fonctionnent pas proche du TDP (surtout pour les applis mono thread), il y a donc un budget power disponible assez important pour ces applications, et gagner de la performance meme en speculant avec une efficacite faible peut etre interressant.
J'avoue que je suis probablement perturbé par mon environnement de boulot : c'est plus l'efficacité énergétique qui me paraît importante. Mais je suis d'accord avec toi.
Je noterais cependant que la spéculation peut réduire les performances des applications non pensées pour cela ou qui ne s'y prêtent simplement pas. Le P4 SMT est probablement un tel exemple, même si comme il s'agissait d'un premier essai grand public, on peut laisser le bénéfice du doute à cette technique.
Citation:
En hardware (CPU centrique), je qualifierais de breakthrough l'implementation de multiples threads en hardware dans les memes cpus. Je fais reference aux techniques de SMT/SoEMT et pas aux multicores. Bien sur il y a eu des tentatives de machines multithread il y a longtemps, mais rien qui n'ait vraiment perce, alors que aujourd'hui on trouve des cpus integrant un type ou un autre de SMT dans des serveurs, dans des applis mobiles et dans des PCs. En revanche la recherche dans le domaine s'est intensifie uniquement il y a une bonne 15 aine d'annes, donc on peut discutter sur le fait que ca soit une idee de notre decennie.
(/mode provoc on) Ouai on a fait descendre le principe de switch de contexte sur IO au niveau du hardware (/mode provoc off)
J'ai encore du mal à croire que cette technique va vraiment apporter des gains importants, et donc je n'arrive pas à la qualifier de breakthrough. Je suis prêt en revanche à admettre que j'ai tort, ce n'est vraiment qu'un point de vue personnel !
Citation:
Il y a eu d'autres bonnes idees avec les caches de traces/ caches d'instruction predecodees/ disambiguation memoire, mais encore une fois il s'agit de la meme epoque.
Ces idées existent en soft depuis un moment.
Je conclurai en disant que je suis globalement d'accord avec toi, pas de doute là-dessus. On n'est probablement juste pas d'accord sur l'importance relative du SW vs celle du HW :)