Micro-Architecture

[fefe]

Bon, je me lance on verra bien ce que ca donne. L'idee du topic est de discuter de details de micro-architecture, a priori en partant d'articles de recherche ou d'articles existant. L'objectif n'est pas d'expliquer les bases, meme si de temps en temps ca ne peut pas faire de mal, mais de discuter sur des (plus ou moins) nouvelles idees.

Disclaimer: Ca risque d'etre un topic prise de tete

Je garde un peu de place pour indexer les diverses discussions qui auront eventuellement lieu dans le topic.

Quelques pointeurs avant de commencer:
- http://www.amazon.fr/s/ref=nb_ss_b?_...essy+patterson La bible (contient les abses du domaine).
- http://www.cs.wisc.edu/arch/www/ un bon point de depart, les conferences les plus interessantes etant generalement MICRO et ISCA (HPCA, ICS, Supercomputing sont aussi tres interressantes)

Ah et j'oubliais, il y a 1 conference en Francais dans le domaine (SympA, tenue conjointement avec RenPar http://gridgroup.tic.hefr.ch/renpar/), mais il n'y a pas vraiment d'alternative que de lire de l'anglais.

Quelques topics "chauds"
- Transactional Memory http://www.cs.wisc.edu/trans-memory/ http://en.wikipedia.org/wiki/Transactional_memory
- Speculative Multithreading/multiscalar http://research.ac.upc.edu/HPCsemina...Processing.ppt http://www.cs.wisc.edu/mscalar/overview.html
- Shared caches policies http://www.ieeexplore.ieee.org/xpls/...nt=44&index=42 http://www.ece.wisc.edu/~nesbit/papers/VPC_isca07.pdf http://users.ece.utexas.edu/~qk/papers/dip.pdf

Pick your topic

[Neo_13]

Tu viens de faire les frais de la fusion automatique...

JE suis intéressé.

[fefe]

Oui salete de fusion, mais bon, j'ai propose 3 sujets mais la liste est longue et je suis ouvert. C'est juste pour qu'il y ait un point de depart.

[Childerik]

Je suis contre l'intégration de l'HT dans le Nehalem : je vais lancer une pétition qui s'intitulera "Ensemble contre le SMT" .

Reprenons : l'HT, s'il signe réellement son retour sur Nehalem, qu'est-ce qu'il va apporter dans une architecture à court pipeline ? J'imagine mal le gain.

[Alexko]

Je suis contre l'intégration de l'HT dans le Nehalem : je vais lancer une pétition qui s'intitulera "Ensemble contre le SMT" .

Reprenons : l'HT, s'il signe réellement son retour sur Nehalem, qu'est-ce qu'il va apporter dans une architecture à court pipeline ? J'imagine mal le gain.

Le prends pas mal, mais je pense que les architectes qui bossent sur Nehalem en ont un peu rien à foutre de ton avis :D

En outre, le SMT profite plutôt à un pipeline large que long... et de toute façon on n'a aucune info sur la nature de celui de Nehalem.

[Tramb]

Ouah ça c'est de l'architecture hardcore. Honnêtement j'ai absolument pas les compétences pour faire ce genre de choix. Juste je vais devoir les assumer, quels qu'il soient, pendant 10 ans.
Esperons que ce soit le plus compliqué possible histoire que je puisse encore avoir du taf :D

Sinon:
La mémoire transactionnelle : ça serait l'occase d'avoir *enfin* du lockfree programming pas complètement buggué. En effet la majorité de ceux qui s'y essayent sur tout problème suffisament complexe foirent leur coup. J'imagine que la perf dépendra du taux de rollback mais au moins ça sera compréhensible par un humain. Problème : mapper ça correctement sur un HLL.

Le speculative multithreading: mouais... filez nous deja de quoi hinter la prédiction de branchement avant d'essayer d'exécuter encore plus de code inutile en avance
Jusqu'à combien de branchements peut-on se permettre de spéculer?
Ceci dit le constructeur qui arrive à améliorer grandement l'exécution de code single-threadé avec ça aura quand même:
a) la classe
b) une bonne part du marché

Pour les politiques de partage des caches, gros sujet, je préfère fermer ma gueule!
De toute façon les codeurs s'adapteront, toute architecture est viable du moment que des gens sont prêts à se faire chier derrière.

En tout cas tout ça m'évoque que les langages fonctionnels purs ont pas mal d'avenir devant eux, parceque quelque soient les modèles sous-jacents, ça sera eux les plus faciles à mapper sur les concepts, quand la granularité des tâches baissera et le parralèllisme augmentera.

[fefe]

HT: je prepare une reponse detaillee qui devrait eclairer un peu la lanterne de Childerik et Frank (j'ai une formation aujourd'hui donc je devrais trouver du temps). Et meme si notre avis les interressait ils ont fini leur archi depuis longtemps donc on peut quand meme discutter .

Le jour ou un programmeur pourra hinter la direction des branchements de maniere plus efficace que les predicteurs actuels n'est pas encore arrive. En revanche sur les quelques pourcents de mauvaises predictions restantes il y en a effectivement certains ou un programmeur pourrait aider. Apres le probleme est qu'il n'essaye pas de hint ceux ou le cpu s'en sort tres bien.

A 1 branchement toutes les 4-5 instructions et une machine de 4 de large, tu peux facilement speculer un branchement par cycle. Donc tu depasses vite la 10aine. Si les programmeurs/compilos etaient capable de donner des hints efficaces Itanium serait plus rapide que x86 sur du code entier. Le probleme majeur vient du fait qu'une partie non negligeable des branchements voit leur direction determinee dynamiquement et ca le programmeur ne peut absolument rien y faire (en proportion bien plus que ceux ou le predicteur se trompe).

Sinon pour les langages fonctionnels la premiere chose a faire pour leur donner un tel avenir est de les enseigner (hors de France). Etant donne que tout peut etre programme en imperatif ou en fonctionnel c'est surtout une question d'education. Apres il faudrait que les archis soient un peu plus prevue dans cette optique mais ca prend moins de temps que d'eduquer une generation de programmeurs.

[Tramb]

Le jour ou un programmeur pourra hinter la direction des branchements de maniere plus efficace que les predicteurs actuels n'est pas encore arrive. En revanche sur les quelques pourcents de mauvaises predictions restantes il y en a effectivement certains ou un programmeur pourrait aider. Apres le probleme est qu'il n'essaye pas de hint ceux ou le cpu s'en sort tres bien.

Bah par exemple sur le PowerPC tu as les branch hints. Ca permet par exemple de faire du bound checking dans un conteneur en hintant que ça ne doit jamais foirer.
Sur GCC/x86 t'as builtin_expect mais là c'est moins direct comme approche, il est censé connaître les heuristiques de prédiction de l'architecture (genre saut avant/saut arrière ) pour réordonnancer le code.

A 1 branchement toutes les 4-5 instructions et une machine de 4 de large, tu peux facilement speculer un branchement par cycle. Donc tu depasses vite la 10aine. Si les programmeurs/compilos etaient capable de donner des hints efficaces Itanium serait plus rapide que x86 sur du code entier. Le probleme majeur vient du fait qu'une partie non negligeable des branchements voit leur direction determinee dynamiquement et ca le programmeur ne peut absolument rien y faire (en proportion bien plus que ceux ou le predicteur se trompe).

Disons que c'est vrai que les endroits où la prédiction de branchement est un bottleneck sont rares dans le code de qualité car juste là où nécessaire. Exemple un quicksort ou une descente de kd-tree.
Mais dans la vie de tous les jours tu peux souvent voir(exemple débile) des
if(a&1) b++ compilés avec un branchement plutôt qu'en tant que b += (a&1)
Donc la les programmeurs son clairement responsables d'écrire du code impredictable et de bouffer une entrée dans le cache de prédiction
Ceci dit le vrai boulot d'un CPU maintenant c'est d'éxécuter efficacement du piètre code ( quand tu vois les règles de stlf du Core2 Duo tu te dis que c'est Noël )

[Neo_13]

Je suis contre l'intégration de l'HT dans le Nehalem : je vais lancer une pétition qui s'intitulera "Ensemble contre le SMT" .

Reprenons : l'HT, s'il signe réellement son retour sur Nehalem, qu'est-ce qu'il va apporter dans une architecture à court pipeline ? J'imagine mal le gain.

et si au lieu d'imbriquer 2 codes dans la pipe dans la longueur, tu le fasses dans la largeur pour optimiser le nombre d'unités utilisées, plutot que d'utiliser + les mêmes unités... Et bien là, pif paf, c'est utile sur nehalem.

[Franck@x86]

Reprenons : l'HT, s'il signe réellement son retour sur Nehalem, qu'est-ce qu'il va apporter dans une architecture à court pipeline ? J'imagine mal le gain.

Je l'ignore, mais si ça a été retenu, c'est que c'est profitable, au moins dans certains cas.

Les deux gros défauts du SMT à mon idée :
- partage des L1 entre deux threads, donc source d'augmentation des conflits (ce qui dans le cas du P4 pouvait conduire à une baisse globale de performances).
- nécessité que l'OS soit capable de distinguer les unités logiques des unités physiques.

[Oxygen3]

C'est pas grave, ca sera désactivable, on peut espérer en tous cas ...
Et j'avoue mal imaginer l'intéret d'un SMT quand il y'a déjà quatre coeurs dans le proco :/

[Foudge]

C'est pas grave, ca sera désactivable, on peut espérer en tous cas ...
Et j'avoue mal imaginer l'intéret d'un SMT quand il y'a déjà quatre coeurs dans le proco :/

Ce sera peut-être réservé aux Xeon, comme au début du Netburst.

[Tramb]

Les deux gros défauts du SMT à mon idée :
- partage des L1 entre deux threads, donc source d'augmentation des conflits (ce qui dans le cas du P4 pouvait conduire à une baisse globale de performances).

Un pattern potentiellement intéressant c'est d'avoir une thread qui ne s'occupe que de prefetcher pour la thread de travail, et là le partage du cache n'est pas un problème.

[Yasko]

Oui, mais du coup, tu n'es pas vraiment multithreadé au niveau calcul/traitement (je ne sais pas trop la charge de boulot que represente le prefetch...)

[Tramb]

Oui, mais du coup, tu n'es pas vraiment multithreadé au niveau calcul/traitement (je ne sais pas trop la charge de boulot que represente le prefetch...)

Tout à fait, ça dépend des patterns d'usage j'imagine, je n'ai jamais essayé ça je crois juste savoir que ICC peut générer ce genre de code par exemple.

[fefe]

Mais dans la vie de tous les jours tu peux souvent voir(exemple débile) des
if(a&1) b++ compilés avec un branchement plutôt qu'en tant que b += (a&1)
Donc la les programmeurs son clairement responsables d'écrire du code impredictable et de bouffer une entrée dans le cache de prédiction
Ceci dit le vrai boulot d'un CPU maintenant c'est d'éxécuter efficacement du piètre code ( quand tu vois les règles de stlf du Core2 Duo tu te dis que c'est Noël )

oui if a&1 b++ est plus rapide que b+= a&1 dans la grande majorite des cas sur un processeur moderne (1 cycle au lieu de 2, sauf si tu me dis a l'avance que a&1 a une entropie tres forte). Il vaut mieux donc un programmeur qui n'essaye pas trop fort . La plupart du temps aujourd'hui il vaut mieux faire un branchement qu'un conditional move, et meme sur un P4.

Les hint de power PC c'est quelque chose qu'ils regrettent depuis presque le premier jour ou presque et que les derniers PowerPC ignorent completement parce que dans la majorite des cas suivre les hints plutot que le predicteur perd de la perf (il existe toujours des contre exemple, c'est une question de proportion).

Quand au compilateur suppose connaitre qq chose sur l'archi du predicteur du branchement c'est pur BS. Aucun constructeur ne communique les details de fonctionnement de leur predicteur. La seule regle valide pour un predicteur moderne est, si toi en tant que programmeur tu arrives a voir une tendance particuliere, le predicteur la verra aussi (a moins que tu sois un specialiste en prediction de branchement, mais il y en a guere qu'une 20 aine et en general ils n'ecrivent pas de code).

[Yasko]

oui if a&1 b++ est plus rapide que b+= a&1 dans la grande majorite des cas sur un processeur moderne (1 cycle au lieu de 2, sauf si tu me dis a l'avance que a&1 a une entropie tres forte). Il vaut mieux donc un programmeur qui n'essaye pas trop fort .

Ah la la, quel monde d'assistés.

a moins que tu sois un specialiste en prediction de branchement, mais il y en a guere qu'une 20 aine et en general ils n'ecrivent pas de code

Moi, j'en connais plein des spécialistes en prédiction qui n'écrivent pas de code.
Mais ce n'est pas des branchements qu'ils prédisent.

Voila, c'était ma grande contribution du jour à la µarch moderne.

[fefe]

Je suis contre l'intégration de l'HT dans le Nehalem : je vais lancer une pétition qui s'intitulera "Ensemble contre le SMT" .

Reprenons : l'HT, s'il signe réellement son retour sur Nehalem, qu'est-ce qu'il va apporter dans une architecture à court pipeline ? J'imagine mal le gain.

Bon alors HT...
Prenons un pipeline a 14 etages de 4 de large te un pipeline de 29 etages de 3 de large, en gros Merom et Prescott (cours vs long). Pour comparer leurs utilisations relatives il suffit de comparer les perfs absolues de ces processeurs. Le plus difficile est de choisir a quelles frequences respective les comparer. Je vais choisir un ratio de 2/3 parce que c'est le plus facile et que ce n'est pas tres loin de la realite (c'est quelque part entre 2/3 et 4/7).

Je vais recuperer les indices de performance a particle de l'article sur les core2 de HFR: http://www.hardware.fr/articles/623-...o-dossier.html

Sur 3DSMAX, un P4 a 3.4Ghz est ~1.35x plus lent qu'un core 2 a 2.13, en pratique si on selectionne a gamme equivalente on arrive quasiment a 1.5x.
Sur MAya c'est 1.2x a 1.3x, sur Mathematica c'est dans les 1.5x, sur winrar c'est 1.1x, Divx 1.35x, etc... On se souvient grosso modo que core2 est 1.4x plus rapide que p4 a gamme equivalente.

D'un point de vue utilisation de la bande passante de decodage, on a 1.4*3*Up4=4*Uc2
d'ou Uc2=4.2/4Up4 soit 5% de plus d'utilisation de la bande passante du frontend.

Si on regarde la bande passante d'execution, P4 a 5 ports d'execution en entier et 1 en flottant alors que C2D en a 5 en entiers et 2 en flottant.
En terme de bande passante en entier, le P4 donne donc l'impression d'avoir 40% d'occupation en moins que C2D, mais en flottant la tendance s'inverse avec 30% en plus.

Prenons l'exemple de l'entier, 40% d'occupation en moins que C2D semble etre une bonne opportunite pour HT dans le cas de P4 et mauvais pour le C2D. En pratique c'est oublier replay... En entier les acces au cache L1 sont speculatifs et tout echec voit les instructions dependantes rejouees. Le cache L1 du P4 est petit, peu associatif et utilise un algorithme de prediction de voie qui reduit encore le taux de succes. Lorsque c'est juste la prediction de voie qui est fausse la boucle de replay est assez courte (quelques cycles), lorsque c'est un echec L1 elle est plus longue (superieur a une dizaine de cycles). Les valeurs exactes ont ete publiees par ixbt dans leur article P4 si je me souviens bien, j ai la flemme de regarder pour l instant.

Un cache L1 tel que celui du P4 va avoir un taux d'echec superieur a 10% en cas typique. Donc 10% des loads vont entrainer des instructions a etre rejouees pendant une bonne 10aine de cycles et 10% des loads se sont trompes sur la prediciotn de voie donc vont etre replay pendant qq cycles. Considerons 1 load sur 5 instructions (c'est entre 1 et 2 suivant les codes) soit 20% des loads. On arrive a 2% des loads entrainant des replays longs et 2% entrainant des replay courts. Si on prend un IPC de 1 (assez classique) et qu on prend 5 cycles pour le replay court et 15 cycles pour le replay long, on arrive immediatement a une augmentation du taux d'occupation des unites entieres de 40% juste a cause de replays. Il y a beaucoup d'autres causes de replay que je ne detaillerai pas ici, mais 40% est en faite tres optimiste.

Tout ca poue en arriver a la conclusion que aussi bien pour le frontend que pour les unites d'executions entieres, en pratique leur taux d'occupation est similaire entre P4 et C2D, ce qui laisse des opportunites similaires pour y scheduler un autre thread (HT).

Pour ce qui est du flottant ou du SIMD entier, le C2D se retrouve avec un taux d'utilisation nettement inferieur au P4, donc on voit qu'il y a encore plus de potentiel dans C2D que dans P4.

Si on regarde du cote des ressources partagees comme les caches: les C2D les ont systematiquement en plus grande quantite (y compris a process equivalent parce qu'il y a moins de transistors de logique en general a cause du nombre reduit d'etages de pipeline). Le cache de donnee de premier niveau est 2x plus gros par exemple. Donc si il n'y avait pas de problemes de partage il n'y en aura pas plus sur C2D.

Edit: je ne me suis pas encore relu, ca risque d'etre un peu imbitable

[Eld]

le HT, c'est bien
par contre faut que l'OS le fasse de façon intelligente, donc en mettant des threads qui bossent sur la même chose pour qu'ils ne se pourrissent pas les caches
et effectivement, dans le cas des helper threads, le cache commun est un avantage

la mémoire transactionelle, c'est beau sur le principe, mais il y a encore quelques soucis de performances.
on reste loin des performances d'un programme basé sur des locks à grain fin, qui n'est pas à la porté de tout le monde je vous l'accorde
il faudrait voir dans quelle mesure un support hardware peut aider les choses
autre problème : les exécutions qui ne respectent pas le lock et qui seront annulées peuvent tomber sur des données dont l'état n'est pas "normal", puisque modifiées en cours de route, et faire par exemple des divisions par 0

[Tramb]

oui if a&1 b++ est plus rapide que b+= a&1 dans la grande majorite des cas sur un processeur moderne (1 cycle au lieu de 2, sauf si tu me dis a l'avance que a&1 a une entropie tres forte). Il vaut mieux donc un programmeur qui n'essaye pas trop fort . La plupart du temps aujourd'hui il vaut mieux faire un branchement qu'un conditional move, et meme sur un P4.

C'est bien de ça qu'on parle hein, de code à forte entropie, évidemment si VTune ne râle pas sur le branch mispredict il vaut mieux laisser du code straightforward

Les hint de power PC c'est quelque chose qu'ils regrettent depuis presque le premier jour ou presque et que les derniers PowerPC ignorent completement parce que dans la majorite des cas suivre les hints plutot que le predicteur perd de la perf (il existe toujours des contre exemple, c'est une question de proportion).

Quand au compilateur suppose connaitre qq chose sur l'archi du predicteur du branchement c'est pur BS. Aucun constructeur ne communique les details de fonctionnement de leur predicteur. La seule regle valide pour un predicteur moderne est, si toi en tant que programmeur tu arrives a voir une tendance particuliere, le predicteur la verra aussi (a moins que tu sois un specialiste en prediction de branchement, mais il y en a guere qu'une 20 aine et en general ils n'ecrivent pas de code).

Alors que fait le __builtin_expect de GCC et pourquoi il y'a du PGO dans les suites de développement?
De plus le code peu utilisé peut être mis loin par le compilo pour préserver la localité des paths les plus exécutés.
Le prédicteur a besoin d'historique, le programmeur pas forcément.
Exemple : tu peux par exemple savoir que tous tes asserts ne doivent jamais être prédits comme failants.
Bref je vois pas comment fournir de la sémantique supplémentaire au CPU peut être pénalisant : au pire il l'ignore. C'est un peu comme dire que les JITters se débrouilleront mieux que ton code statique parcequ'ils sont dynamiques : on sait ce que ça donne en pratique

[Childerik]

Edit: je ne me suis pas encore relu, ca risque d'etre un peu imbitable

Bah, du moment que je te fais confiance dans tes calculs .

Bref, globalement, les deux unités flottantes du Core contre une seule pour le P4 laisse des trous encore plus nombreux que sur P4 et qui se tournent souvent les pouces, si j'ai bien compris ? C'est une bonne description qui justifie l'HT dans ce cas précis.

Mais comme le fait remarquer Oxygen3, pourquoi ne pas utiliser le potentiel déjà existant du SMP dans un quad ? (hum, l'anti-HT en quelques sortes, on rigole pas ).

[fefe]

La question de savoir si les applications tireront parti du nombre incommensurable de threads qu'auront les versions haut de gamme de Nehalem est une question differente.

Sur les serveurs la reponse est evidente: c'est utile et ca sera exploite des le premier jour.

Sur l'entree de gamme: meme un monocore proposera 2 threads (il y en aura probablement un a un moment ou un autre) et donc permettra le comfort d'utilisation des dual-thread meme dans un processeur ultra low cost. Cela permet aussi du 4 thread a assez bas cout, a supposer que les applis clients a 4 threads se developpent un peu plus.

Au dela de 4 threads pour les applis clients j'ai un doute certain, mais ceux qui me connaissent bien savent que je ne suis pas tres entousiaste a la simple idee de multithread, donc je ne me ferai pas l'avocat de plateformes proposant 8 a 16 threads sur un meme socket en dehors des applis server, ou du moins pas tout de suite...)

[Yasko]

Si j'ai bien compris, le replay du P4 comble un peu plus le pipe, et P4 et C2D arrivent au final à peu près à un même taux d'occupation ?

Question du coup : pourquoi Intel n'a pas mis de HT sur le C2D ?
L'impact du replay n'avait pas été prévu sur P4, et lorsque on tient compte, le taux de disponibilité pour un second thread n'est plus si intéressant que ça ?

[Childerik]

La question de savoir si les applications tireront parti du nombre incommensurable de threads qu'auront les versions haut de gamme de Nehalem est une question differente.

Sur les serveurs la reponse est evidente: c'est utile et ca sera exploite des le premier jour.

D'accord.

Sur l'entree de gamme: meme un monocore proposera 2 threads (il y en aura probablement un a un moment ou un autre) et donc permettra le comfort d'utilisation des dual-thread meme dans un processeur ultra low cost. Cela permet aussi du 4 thread a assez bas cout, a supposer que les applis clients a 4 threads se developpent un peu plus.

Oui, sauf qu'Intel mettra du SMP dans ses Celerons, et que les Celerons monocore disparaitront progressivement. Ca peut être intéressant pour Silverthorne dans un premier temps, avant que celui-ci puisse être dual-core avec un process à 32 nm.

[fefe]

Si j'ai bien compris, le replay du P4 comble un peu plus le pipe, et P4 et C2D arrivent au final à peu près à un même taux d'occupation ?

A peu pres le meme partout sauf en flottant ou le C2D est en fait moins charge que le P4.

Question du coup : pourquoi Intel n'a pas mis de HT sur le C2D ?

C2D etait le successeur de CD, un processeur pour laptops. Augmenter le taux d'utilisation d'un CPU a une certaine tendance a exploser le TDP. Ajouter du hardware pour que le 2 eme thread ne penalise pas le premier augmente encore plus le power, et ce pour les rares cas ou une appli mobile tirerait partie de ce thread hardware additionel. C2D a ete fait par une equipe qui n'a aps l'experience de HT, l'inverse de NHM. C2D est suffisament performant par rapport a la generation suffisante pour ne pas avoir besoin d'HT comme argument commercial. Choisi la raison que tu veux, il y a probablement un peu de tout, et plus encore meme...

L'impact du replay n'avait pas été prévu sur P4, et lorsque on tient compte, le taux de disponibilité pour un second thread n'est plus si intéressant que ça ?

L'impact du replay est quelque chose de tres difficile a evaluer a l'avance du a sa dynamicite (ca existe ce mot?). L'efficacite du second thread sur P4 n'est que partiellement lie a replay, il y a beaucoup d'autres raisons (regarder l'evolution de HT entre northwood et prescott peut aider a en comprendre certaines).

[Gabriel]

La seule regle valide pour un predicteur moderne est, si toi en tant que programmeur tu arrives a voir une tendance particuliere, le predicteur la verra aussi

Mais alors, pourquoi dans les codes sources, en réordonnant nos tests en fonction des probabilités on obtient un gain de perfs?

[fennec]

Mais alors, pourquoi dans les codes sources, en réordonnant nos tests en fonction des probabilités on obtient un gain de perfs?

Les predicteurs fonctionnent en faisant des statistiques, si tu réordonnance ton code pour "coller" aux statistiques tu triches, en fait tu as fait à la main ce que le predicteur aurait du calculer.

Le problème c'est que c'est difficle pour le compilateur de faire ce boulot pour toi :/


Pour info, j'ai reçu une petite Sun avec un UltraSPARC T2 (8 core & 64 threads). Dans quelques mois je ferais du bench d'homme dessu (prog avec 3000 Threads et 4Go de mémoire). Mais si quelqu'un a un petit bench en Java j'ai moyen de faire quelques tests.

[fefe]

Mais alors, pourquoi dans les codes sources, en réordonnant nos tests en fonction des probabilités on obtient un gain de perfs?

Si tu reduis l'entropie du probleme tu peux effectuer arriver a des gains, si tu parts avec un probleme ou tu as beaucoup de branchements data dependants. A priori ce n'est pas vraiment la probabilite qu un branchement soit pris ou non pris que tu optimises mais la regularite des patterns d'acces. Si tu regardes les performance counters pour analyser le taux de succes du predicteur sur le branchement que tu etudies, tu te rendras compte que son taux de succes est superieur au max (taux pris, taux non pris) ce qui serait le meilleur resultat qu'un hint software peut obtenir. Si tu trouves des branchements ou ce n'est pas le cas je suis tres interresse par des pointeurs.

En revanche en faisant ca tu es quasi certain que sur le prochain cpu ou sur le cpu du concurent tu devras refaire la meme analyse pour conserver ton niveau de perf, alors que si tu ne l'avais pas fait tu ne risquerais pas de perte de perf. En pratique si tu parles de Lame ou de codecs en general, cela a un sens de le faire. Divx le fait aussi, de meme pour windows media...

Mais en general ce genre d'analyse est rentable pour des applis qui ont une ou deux boucles avec un branchement critique, pas un code spaghietti.

En conclusion je ne voulais pas dire que l'analyse d'un branchement et de l'efficacite du predicteur ne peut pas t'apporter des performances (et je doute que le programmeur ait fait cette analyse statistique sans profiling donc ca ne rentre pas vraiment dans le cas du observable a l'oeil du programmeur), mais que d'essayer de coder une prediction de branchement statique sous forme de hint est inefficace.

[Gabriel]

Un peu de lecture sur la prédiction de branchement:
A. Farcy, "Exécution anticipée des flots de condition : une alternative aux prédictions de branchement"
http://rangiroa.essi.fr/rapports/200...hese-farcy.pdf

[Tramb]

fefe, que penses-tu de mon exemple pour du code spaghetti où tous les asserts sont hintés comme non pris?
A raison de 1/2 asserts par fonction, y'a de quoi améliorer la vitesse des debug builds quand même.

En fait tu négliges le chauffage du BHT et les évictions, ce qui me parait tout à fait valide pour du data crunching, mais pour un programme plus versatile... en fait j'en sais rien
En l'absence d'entrée dans l'historique le CPU a bien une heuristique statique pour se décider (les branches ne sont pas prises, j'imagine).