AMD annonce (officiellement) son Barcelona

>Lachessis
Quand je fais un O/C, je monte en même tps et du même pourcentage: le CPU, le FSB et la RAM. Lors qu'un calcul vidéo qui fait appel à une variété d'instruction et à la mémoire aussi, le gain n'est qu'à peine de moitié (6-8% de gain pour 12-15% d'O/C). Donc je m'interroge :neutre:

>Ypub
En interne il peut y avoir plusieurs fréquences (en général y a des coefs simple entre elles). Rien n'empêche donc d'avoir des unités internes qui fonctionnent en asynchrone, je ne sais pas si c'est le cas, mais la simple mention d'une fréquence ne me suffit pas pour considérer tout le CPU comme synchrone. En plus les CPU ont des pipelines, traitent plusieurs instructions en même temps et avec cette architecture c'est pas bien grave si une unité de traitement donne le résultat plus ou moins vite. :neutre:
Enfin l'essentiel c'est que ça marche et le meilleur moyen de comparer c'est encore le test en condition :)

> Si les cycles n'ont pas la même durée, il se peut qu'on ait pas le même nombre de cycle.

Mais la fréquence d'un proc est telle que à chaque cycle - à chaque fois que l'horloge fait tic - le processeur se trouve dans un état stable et défini, chaque registre ayant une valeur bien définie.


Prenons un exemple d'un opération complexe : la division.
Admetons que l'algo de division soit capable de d'extraire 2 bits par cycle d'horloge.
Pour faire une division de 2 nombre de 32bits il faudra 16 cycles dans mon exemple.

Cette opération élémentaire prend un certain temps (électriquement ). disons 1 ns.
Si c'est l'opération la plus lente du processeur, c'est elle qui va déterminer la fréquence max de fonctionnement de proc. dans notre cas 1 Ghz.
La division s'effectuera en 16ns.

Si tu fais fonctionner le proc + rapidement, il risque de fonctionner correctement pour les autres opérations mais risque de planter lamentablement parce que le registre final dans lequel est inscrit le résultat de la division n'a pas été mis à jour à temps, et l'instruction suivante utilise se registre sans savoir s'il a été mis à jour (là encore y'a plein de subtilités).

Là, plusieurs possibilités pour accélérer ton proc:

1 - Faire une nouvelle révision du proc, raccourcir les pistes, réarranger les unités de calcul et gagner quelques pouillèmes de secondes sur l'opération la plus lente (qui ne s'executera qu'en 0,8 ns ce qui permettra de monter le proc à 1,25 GHz ( à conditions bien sûr qu'il n'y ait pas d'autres problèmes de synchronisation, de dégagement thermique, etc.)
La division s'effectuera en 13 ns

2 - Utiliser une autre méthode pour diviser. Par exemple un algo qui ne calcul qu'un seul bit par cycle mais qui tourne deux fois plus vite (0,5 ns). Du coup, il faudra 32 cycles pour avoir le résultat.
Si tu arrives à faire grimper la fréquence de ton proc à 2Ghz. Ta division s'effectuera toujours à la même vitesse (16 ns) mais le reste des opération ira nettement plus vite.

Fury34 a écrit:
>Ypub
En interne il peut y avoir plusieurs fréquences (en général y a des coefs simple entre elles). Rien n'empêche donc d'avoir des unités internes qui fonctionnent en asynchrone, je ne sais pas si c'est le cas, mais la simple mention d'une fréquence ne me suffit pas pour considérer tout le CPU comme synchrone. En plus les CPU ont des pipelines, traitent plusieurs instructions en même temps et avec cette architecture c'est pas bien grave si une unité de traitement donne le résultat plus ou moins vite. :neutre:
Enfin l'essentiel c'est que ça marche et le meilleur moyen de comparer c'est encore le test en condition :)

Bien entendu mais tout est re-synchronisé, il y a une (des) bascule (s) en fin de traitement. Les processeurs asynchrones c'est de l'ordre du conceptuel. c'est bien joli mais trop risqué, de simples variantes de routages conduiraient à des erreurs. Un bête additionneur a besoin de la retenue du bit précédent.
Pour moi, en perf intrinsèques tant que tu montes la fréquence, tu augmentes linéairement les perfs jusqu'à une limite pour laquelle ton processeur plante. :neutre:

Fury34 a écrit:
>Lachessis
Quand je fais un O/C, je monte en même tps et du même pourcentage: le CPU, le FSB et la RAM. Lors qu'un calcul vidéo qui fait appel à une variété d'instruction et à la mémoire aussi, le gain n'est qu'à peine de moitié (6-8% de gain pour 12-15% d'O/C). Donc je m'interroge :neutre:

Et ça ne fait pas du tout appel au disque ? ;)

d9pouces a écrit:

Fury34 a écrit:
>Lachessis
Quand je fais un O/C, je monte en même tps et du même pourcentage: le CPU, le FSB et la RAM. Lors qu'un calcul vidéo qui fait appel à une variété d'instruction et à la mémoire aussi, le gain n'est qu'à peine de moitié (6-8% de gain pour 12-15% d'O/C). Donc je m'interroge :neutre:

Et ça ne fait pas du tout appel au disque ? ;)

Exact ça pourrait être ça. Ca m'étonne un peu car ça me parait énorme comme différence sur une simple lecture séquentielle + cache et sur un débit vidéo faible, mais pourquoi pas. Faudra que je reteste avec mon "nouveau" système et que je teste avec plus de cache.
Dans un test 3DMark06 le score CPU (je sais pas ce qu'il vaut) augmente pratiquement en proportion (12.5% O/C / 12% gain) donc ça doit venir de là. :jap:

Edit: Par contre, mon portable P4C 3.2 HT avec disque 2"5 compresse plus vite que mon P4B 2.8@3.15 sur un RAID 0 à 160GB/s sur le même type de vidéos (VOB MPEG2/AC3 => DivX/MP3) [:paysan] Ca doit ralentir mais pas tant que ça. Mes anciens disques devaient être vraiment dégueux :D
Edité le 02/07/2007 à 15:48

y'a pas une erreur dans la news?

"AMD se plante officiellement avec son Barcelona" :D