AMD ou Intel ainsi que la marque de la mémoire - page 73
Vous manquez des opportunités de trading :
- Applications de trading gratuites
- Plus de 8 000 signaux à copier
- Actualités économiques pour explorer les marchés financiers
Inscription
Se connecter
Vous acceptez la politique du site Web et les conditions d'utilisation
Si vous n'avez pas de compte, veuillez vous inscrire
Pourquoi ? Je suis également très intéressé par la vitesse de calcul des choses sérieuses.
Eh bien, on est trois. Toujours pas beaucoup.
J'ai très bien compris votre idée. Mais je pense que nous chargeons le testeur d'une mauvaise manière. Mon point de vue, par contre, vous ne semblez pas l'avoir compris. Mais cela n'a pas d'importance, dans l'ensemble. Pour une orientation, pour ainsi dire, "sur le terrain", ce dernier expert fera aussi bien l'affaire.
OK. Ce n'est pas un casus belli pour les maris décents, n'est-ce pas ? ))) Je suis également intéressé par la vitesse d'exécution du code spécifiquement, car mes indicateurs (soudainement, j'ai vu) sont assez gourmands en ressources même en exécution publique.
Je pense que Grassn serait également ravi d'avoir l'opportunité de compter plus vite.
Non. Tout le monde ne voit tout simplement pas de tâches gourmandes en ressources dans MT en dehors du travail de l'optimiseur. Et même s'ils le font, ils ne les utilisent pas dans leur travail quotidien. Du moins, la plupart d'entre eux le font. Mais peu importe. Je vais attendre MT5. La vitesse du code est visible à l'œil nu. Et il y a aussi CUDA. J'ai téléchargé des boîtes à outils sur le site de nVidia, je vais les étudier. Et il n'y a aucun problème pour transférer le code dans le DLL.
Quant à CUDA, j'ai vu des exemples de calculs accélérés par un facteur de 10 à 100. Pour certaines applications médicales. Et la programmation CUDA est déjà enseignée dans les universités. Mais c'est très fastidieux. Le C est un langage similaire, mais il est nécessaire de diviser correctement la tâche, de tenir compte des particularités du GPU et des calculs sur les nombres entiers. Il s'agit en fait d'une programmation de très bas niveau. Et toutes les tâches ne peuvent pas être facilement réduites à ce type pour obtenir un gain réel après six mois de travail. Bien que, par exemple, les opérations avec des matrices entières se traduisent presque parfaitement en CUDA.
Il y a le projet OpenCL, qui est un environnement de calcul distribué. Presque tout le monde y participe, y compris AMD et nVidia. Il y a là un niveau d'abstraction plus élevé. Le lien contient un exemple de code qui, comme vous pouvez le constater, est en C (la norme C99).
J'ai étudié les sources, je ferai mon rapport dans l'après-midi, c'est l'heure de se coucher.
Les résultats sont plus ou moins clairs.
Je vais essayer de décrire brièvement mes conclusions.
Lors de l'optimisation du conseiller expert, le testeur utilise plusieurs dizaines de Mo de mémoire. J'ai, par exemple, un fichier fxt pour une année avec des minutes par ouvertures pour environ 36 MB. Cet historique est stocké en mémoire et on y accède plus ou moins aléatoirement. Dans ce mode, la mémoire n'est pas assez performante pour fournir au processeur la quantité de données qu'il pourrait traiter dans le cas "idéal". Ici, le rôle important est joué par le cache.
C'est ici que commence la partie la plus intéressante.
1) De toute évidence, en cas d'absence de cache, la vitesse et la latence des accès à la mémoire jouent un rôle important. Ici, les processeurs peuvent être divisés en deux groupes :
a) Atom et Core 2 - le contrôleur de mémoire se trouve dans le chipset "north bridge" (North Bridge - NB).
b) tous les autres avec contrôleur de mémoire intégré (dans le processeur) - ICP.
Dans ce cas, les processeurs du groupe "a" peuvent perdre beaucoup au profit des processeurs du groupe "b". Cela dit, le PCI du Core i7 est beaucoup plus efficace que celui des processeurs AMD. C'est l'une des raisons de la victoire sans appel du Core i7.
2) Pour qu'un cache masque efficacement la latence, il doit être aussi grand que possible, associatif (x-way dans les captures d'écran de CPU-Z) et avoir une latence intrinsèque moindre.
Et ici, les processeurs s'alignent clairement en termes de vitesse en fonction du volume du cache (toutes choses égales par ailleurs).
- Le processeur le plus lent est le Celeron avec 512KB de cache (je ne prends pas en compte l'Atom - son architecture est conçue pour l'économie plutôt que pour la performance) ;
- Athlons - leurs caches de faible taille ont moins d'effet en raison de l'ICP ;
- Celeron 900 avec 1 MB de cache ;
- Processeurs Core 2 avec cache de 3 à 6 Mo ; les modèles avec un volume de cache plus important sont un peu à côté de la plaque ;
- Phenom II, ici 6 MB de cache (et avec une associativité maximale - jusqu'à 48 voies !) sont combinés avec ICP ;
- et le plus rapide - Core i7 - il combine ici toutes les choses les plus progressives - RPC à 3 canaux (et généralement très rapide) et le plus grand (et encore une fois très rapide) cache L3 avec 8 MB.
Quant à savoir pourquoi l'efficacité du Phenom diminue lorsqu'il est overclocké et celle du Core i7 augmente.
Dans ces deux processeurs, le cache ICP et le cache L3 sont cadencés séparément (tandis que le cache L1/L2 fonctionne toujours à la fréquence du CPU).
Mais la méthode d'overclocking de Belford consiste à augmenter le multiplicateur du CPU (il a un processeur BE - Black Edition series - avec un multiplicateur libre, normalement le multiplicateur du dessus est limité), sans overclocker le cache L3.
Alors que l'overclocking du Core i7 (à l'exception du XE) n'est possible qu'en augmentant la fréquence de base (BCLK). Cela permet également de surcadencer les circuits intégrés avec un cache L3 (dans le Core ix, cela s'appelle Uncore).
Donc la vitesse L3 du Phenom de Belford est toujours fixée à 2009.1 MHz. Et chez YuraZ, il passe de 2,13 GHz au pair, à 3,2 GHz lorsque le processeur est overclocké à 4 GHz. (CPU BCLK x 20, Uncore BCLK x 16). Et le Xeon, avec une fréquence CPU de 3,33 GHz, l'Uncore tourne à 2,66 GHz.
Même à 2,13 GHz, le cache L3 du Core i7 est nettement plus rapide que celui du Phenom à 2 GHz. Et naturellement beaucoup plus rapide à 3,2 GHz, ce qui assure l'excellente évolutivité du Core i7 dans ce test.
Il ne s'agit là que de spéculations, car je n'ai pas effectué de recherches détaillées. Mais il semble que la vitesse d'optimisation dépende fortement de la taille et des performances du cache, et un peu moins de la fréquence du processeur.
Je vais essayer de décrire brièvement mes conclusions.
Lors de l'optimisation du conseiller expert, le testeur utilise plusieurs dizaines de Mo de mémoire. J'ai, par exemple, un fichier fxt pour une année avec des minutes par ouvertures pour environ 36 MB. Cet historique est stocké en mémoire et on y accède plus ou moins aléatoirement. Dans ce mode, la mémoire n'est pas assez performante pour fournir au processeur la quantité de données qu'il pourrait traiter dans le cas "idéal". Ici, le rôle important est joué par le cache.
C'est ici que commence la partie la plus intéressante.
1) De toute évidence, en cas d'absence de cache, la vitesse et la latence des accès à la mémoire jouent un rôle important. Ici, les processeurs peuvent être divisés en deux groupes :
a) Atom et Core 2 - le contrôleur de mémoire se trouve dans le chipset "north bridge" (North Bridge - NB).
b) tous les autres avec contrôleur de mémoire intégré (dans le processeur) - ICP.
Dans ce cas, les processeurs du groupe "a" peuvent perdre beaucoup au profit des processeurs du groupe "b". Cela dit, le PCI du Core i7 est beaucoup plus efficace que celui des processeurs AMD. C'est l'une des raisons de la victoire sans appel du Core i7.
2) Pour qu'un cache masque efficacement la latence, il doit être aussi grand que possible, associatif (x-way dans les captures d'écran de CPU-Z) et avoir une latence intrinsèque moindre.
Et ici, les processeurs s'alignent clairement en termes de vitesse en fonction du volume du cache (toutes choses égales par ailleurs).
- Le processeur le plus lent est le Celeron avec 512KB de cache (je ne prends pas en compte l'Atom - son architecture est conçue pour l'économie plutôt que pour la performance) ;
- Athlons - leurs caches de faible taille ont moins d'effet en raison de l'ICP ;
- Celeron 900 avec 1 MB de cache ;
- Processeurs Core 2 avec cache de 3 à 6 Mo ; les modèles avec un volume de cache plus important sont un peu à côté de la plaque ;
- Phenom II, ici 6 MB de cache (et avec une associativité maximale - jusqu'à 48 voies !) sont combinés avec ICP ;
- et le plus rapide - Core i7 - combine ici tous les éléments les plus progressifs - RPC à 3 canaux (et généralement très rapide) et le plus grand (et à nouveau très rapide) cache L3 de 8 Mo.
Quant à savoir pourquoi l'efficacité du Phenom diminue lorsqu'il est overclocké, et celle du Core i7 augmente.
Dans ces deux processeurs, le cache ICP et le cache L3 sont cadencés séparément (tandis que le cache L1/L2 fonctionne toujours à la fréquence du CPU).
Mais la méthode d'overclocking de Belford consiste à augmenter le multiplicateur du CPU (il a un processeur BE - Black Edition series - avec un multiplicateur libre, normalement le multiplicateur du dessus est limité), sans overclocker le cache L3.
Alors que l'overclocking du Core i7 (à l'exception du XE) n'est possible qu'en augmentant la fréquence de base (BCLK). Cela permet également de surcadencer les circuits intégrés avec un cache L3 (dans le Core ix, cela s'appelle Uncore).
Donc la vitesse L3 du Phenom est toujours fixée à 2009.1 MHz. Et avec YuraZ, il passe de 2,13 GHz à la normale, à 3,2 GHz lorsque le processeur est overclocké à 4 GHz. (CPU BCLK x 20, Uncore BCLK x 16). Et le Xeon, avec une fréquence CPU de 3,33 GHz, l'Uncore tourne à 2,66 GHz.
Même à 2,13 GHz, le cache L3 du Core i7 est nettement plus rapide que celui du Phenom à 2 GHz. Et naturellement beaucoup plus rapide à 3,2 GHz, ce qui assure l'excellente évolutivité du Core i7 dans ce test.
Il ne s'agit là que de spéculations, car je n'ai pas effectué de recherches détaillées. Mais il semble que la vitesse d'optimisation dépende fortement de la taille et des performances du cache, et un peu moins de la fréquence du processeur.
Merci. Je pense que c'est très convaincant. Je suis d'accord.
Une petite clarification. Serait-il correct de supposer que la vitesse d'optimisation dépend davantage de la taille et des performances du cache que de la fréquence du processeur ?
.
Une petite clarification. Est-il correct de supposer que la vitesse d'optimisation dépend davantage de la taille et des performances du cache que de la fréquence du processeur ?
.
Il s'avère que c'est le cas. Mais cela reste une supposition pour le moment et je l'ai souligné dans mon post !