J'ai bien dis le nom maximum que le processeur peut exécuter, c'est à dire en supposant que, par un moyen quelconque (et c'est la fonctione qu'essaye de remplire les différents caches), toutes les instructions et données sont acheminées au processeurs dès que nécessaire et sans temps de latence.
Je sais bien que celà est presque illusoire, cependant voici une expérience vécue: J'ai récament remplacé mon athlon 600 par un athlon XP 2200 (1800 MHz réels). j'exécute le client seti@home sur ma machine, avec l'athlon 600 une unité de calcul prenait ~14h de temps processeur pour être complétée, avec le XP2200 une unité de calcul prend ~4h. 14h/4h=3.5 et 2200/600=3.666 (1800/600=3). Ce n'est pas très étonnant, car le programme (~350ko dont beaucoup de code qui ne sert que lors du démarrage ou de l'envoitdes résultat et de la récupération de la suivante) et les données (~340ko) sont à peine plus grand que les différetns caches (128ko de L1 et 256ko de L2), d'où très peu de latence pour les accès mémoire, vu qu'à peu près tout peut tenir en cache.
[^] # Re: L'intérêt de la fréquence
Posté par wismerhill . En réponse à la dépêche AMD et INTEL optent pour des technologies opposées.. Évalué à 4.
Je sais bien que celà est presque illusoire, cependant voici une expérience vécue: J'ai récament remplacé mon athlon 600 par un athlon XP 2200 (1800 MHz réels). j'exécute le client seti@home sur ma machine, avec l'athlon 600 une unité de calcul prenait ~14h de temps processeur pour être complétée, avec le XP2200 une unité de calcul prend ~4h. 14h/4h=3.5 et 2200/600=3.666 (1800/600=3). Ce n'est pas très étonnant, car le programme (~350ko dont beaucoup de code qui ne sert que lors du démarrage ou de l'envoitdes résultat et de la récupération de la suivante) et les données (~340ko) sont à peine plus grand que les différetns caches (128ko de L1 et 256ko de L2), d'où très peu de latence pour les accès mémoire, vu qu'à peu près tout peut tenir en cache.