Y a pas que fast-math, par exemple :
a=b/c;d=e/c; est simplifie sur Intel, pas sur Sun (pas de traps)... de plus, avec le compilateur de Sun, avec le proto "void f(float *f1, float f2[2])", ya aliasing de pointeur d'ou aucune optimisation faite par le compilateur, une sous utilisation des registres et un mauvais pipelinning du code (barde de ld/st)...
Malheureusment, aujourd'hui le code s'adapte aux options qui ont ete decidees sur Intel. Resultat, le CPI sur Sun est de 1.30 dans les benchs ou il n'y a pas de cache stalls... (un code legerement optimise a un CPI < a 0.5 si il n'y a pas de data cache stalls).
Je ne dis pas que les proc d'Intel sont bon ou mauvais, simplement qu'il n'est pas judicieux de comparer des proc avec des benchs d'appli dont on a pas beaucoups d'informations.
[^] # Re: Mouarf...
Posté par thedidouille . En réponse à la dépêche X86 contre PPC : Un article fait le point. Évalué à 1.
a=b/c;d=e/c; est simplifie sur Intel, pas sur Sun (pas de traps)... de plus, avec le compilateur de Sun, avec le proto "void f(float *f1, float f2[2])", ya aliasing de pointeur d'ou aucune optimisation faite par le compilateur, une sous utilisation des registres et un mauvais pipelinning du code (barde de ld/st)...
Malheureusment, aujourd'hui le code s'adapte aux options qui ont ete decidees sur Intel. Resultat, le CPI sur Sun est de 1.30 dans les benchs ou il n'y a pas de cache stalls... (un code legerement optimise a un CPI < a 0.5 si il n'y a pas de data cache stalls).
Je ne dis pas que les proc d'Intel sont bon ou mauvais, simplement qu'il n'est pas judicieux de comparer des proc avec des benchs d'appli dont on a pas beaucoups d'informations.