Le papier que j'ai vu passer montrait une compilation avec gcc et les outils ARM proprio. A chaque fois, x86 était bien plus petit (~ 20%).
Pour l'autre au dessus qui me cause de complexité de décodage quand je parle de sauvegarde de bande passante mémoire. Il devrait garder à l'esprit que la différence entre la vitesse du proc et la vitesse mémoire atteind 10x et ne fait que monter. Beaucoup d'algorithme sont limité par ça. Donc Il vaut mieux que le cpu fasse des trucs complexe plutot que d'attendre la mémoire.
Ensuite, l'IPC moyen d'un code est rarement supérieur à 3, donc rajouter plein d'unité de calcul sert dans très peu de cas. Donc, la vrai limite d'un processeurs devient la lattence mémoire.
Pour ceux qui mette en avant la FSB à 900Mhz du PPC970... qu'il relise pour voir que cela ne cause que de la liason cpu <-> chipset et que la lisaison chipset <-> mémoire, c'est de la bète DDRSDRAM à 333. L'opteron utilise une liaison cpu<-> mémoire direct bien plus efficace...
[^] # Re: Mouarf...
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche X86 contre PPC : Un article fait le point. Évalué à 2.
Pour l'autre au dessus qui me cause de complexité de décodage quand je parle de sauvegarde de bande passante mémoire. Il devrait garder à l'esprit que la différence entre la vitesse du proc et la vitesse mémoire atteind 10x et ne fait que monter. Beaucoup d'algorithme sont limité par ça. Donc Il vaut mieux que le cpu fasse des trucs complexe plutot que d'attendre la mémoire.
Ensuite, l'IPC moyen d'un code est rarement supérieur à 3, donc rajouter plein d'unité de calcul sert dans très peu de cas. Donc, la vrai limite d'un processeurs devient la lattence mémoire.
Pour ceux qui mette en avant la FSB à 900Mhz du PPC970... qu'il relise pour voir que cela ne cause que de la liason cpu <-> chipset et que la lisaison chipset <-> mémoire, c'est de la bète DDRSDRAM à 333. L'opteron utilise une liaison cpu<-> mémoire direct bien plus efficace...
"La première sécurité est la liberté"