Forum |  HardWare.fr | News | Articles | PC | S'identifier | S'inscrire | Shop Recherche
2826 connectés 

 


 Mot :   Pseudo :  
 
 Page :   1  2
Page Suivante
Auteur Sujet :

[HFR] Focus : Influence du nombre de coeurs et du SMT sur Ryzen

n°10127632
fragoule
Posté le 15-04-2017 à 22:26:58  profilanswer
5Votes positifs
 

Reprise du message précédent :
mille mercis pour ce genre d'articles. une aide très précieuse au choix lors de l'achat

mood
Publicité
Posté le 15-04-2017 à 22:26:58  profilanswer
 

n°10127658
GrouikR7
Posté le 15-04-2017 à 22:57:25  profilanswer
1Votes positifs
 

Le 1600X apparaît comme être le meilleur compromis prix/applications/jeux.

n°10127683
bep
Posté le 15-04-2017 à 23:49:11  profilanswer
1Votes positifs
 

merci pour l'article! Bon travail.

n°10127742
mogana
Posté le 16-04-2017 à 06:37:55  profilanswer
1Votes positifs
 

C_Wiz a écrit :


Non non, il y a des API pour détecter le nombre de coeurs. Il y a aussi des API Windows qui indiquent la présence de coeurs logiques, mais ca F1 2016 ne semble pas les utiliser.  
 
Ils semblent utiliser une détection de plus bas niveau, probablementles registres CPUID du processeur pour vérifier la présence ou non d'HT. Vu que leur moteur est multi plateforme, taper des API de bas niveau n'est pas une mauvaise idée, c'est juste qu'ils ne vérifient pas encore pour le SMT sur des puces AMD. Ca sera vite corrigé on imagine mais c'est souvent comme ca quand quelque chose de nouveau arrive, il peut y avoir des bugs. L'HT au tout début était aussi très très peu bénéfique dans le jeux chez Intel avant que les développeurs s'adaptent. Ici c'est juste détecter correctement, ce qui prendra peu de temps.  


 
merci pour la réponse
 
Cependant je me suis mal exprimé avec la première question, je voulais dire comment ça se fait qu'ils détectent la topologie d'un processeur car selon moi ils ne devraient pas dans une archi smp, numa je comprends mais pas smp.
Quand il m'arrivait de coder avec du multithreading, je ne m'amusais pas à chercher sur quel cœur faire tourner un thread, je laissais l'os faire pour ça, à la limite, je déterminais le nombre de cœurs pour dimensionner mon pool de thread mais c'est tout.
A moins que f1 2016 utilise une api bas niveau qui détermine le nombre de cœurs disponibles et en trouve 8 alors qu'il y en a 16 ?
après je suis pas développeur de jeu donc peut-être que pour eux il est utile de dispatcher leur thread sur les coeurs physiques puis logique, mais je ne connais pas d'api windows pour binder un thread sur un cœur particulier.

n°10127895
Talmu
Posté le 16-04-2017 à 12:56:28  profilanswer
2Votes positifs
 

karissmatic a écrit :

Les R 1600(X) représentent l'équilibre même. Tout ce que l'on a besoin pour un PC.
Un rapport puissance/polyvalence/prix excellent !

 

Je partage aussi ce point de vue, perso je n'avais plus utilisé de Pc Amd depuis la génération K7.
Mais la je crois que pour ma prochaine config de fin d'année et qui sera censée me tenir au moins 5 années, je pense faire un retour chez eux. Et pour plusieurs raisons, tout d'abord la plus importante, le prix !

 

J'ai jamais mis plus de 200 balles dans un Cpu et 350 dans une carte graphique, et depuis le manque de concurrence sur les 10 dernières années, on peut remarquer que le duo Intel/Nvidia en a bien profité pour monter les tarifs sans apporter une proportionnalité de gain équivalente.
Pour casser cela et revenir comme à la belle époque, seul Amd/Ati peuvent y parvenir. Je ne suis pas encore prêt pour passer chez Ati en terme de CG, mais pour le CPU je pense que ce Ryzen est une vraie opportunité. Quitte à mettre 50 balles de plus, la série 1600 est au top en terme de rapport perf/prix actuellement.

 

Quand je vois le gain dans les jeux entre un 2500k et un 2600k sur 6 années, je ne peut être que persuadé (avis perso) que l'avenir ne se jouera plus seulement sur une question de fréquence, mais bien de traitement multi-Threads et donc indirectement aux multi-cores.
Le 1600 face aux Intel à 250 balles offre 3 fois plus de Threads, sans oublier presque 3 fois plus de cache L3, et 2 cores supplémentaires qui à mon avis suffiront pour couvrir les futures développements de jeux dans un grand confort sur les 5 ou 6 prochaines années.

 

Les paris sont lancés.  :)


Message édité par Talmu le 16-04-2017 à 13:12:19
n°10127944
C_Wiz
Profil : Equipe HardWare.fr
Posté le 16-04-2017 à 14:04:42  profilanswer
2Votes positifs
 

mogana a écrit :


Cependant je me suis mal exprimé avec la première question, je voulais dire comment ça se fait qu'ils détectent la topologie d'un processeur car selon moi ils ne devraient pas dans une archi smp, numa je comprends mais pas smp.
Quand il m'arrivait de coder avec du multithreading, je ne m'amusais pas à chercher sur quel cœur faire tourner un thread, je laissais l'os faire pour ça, à la limite, je déterminais le nombre de cœurs pour dimensionner mon pool de thread mais c'est tout.


Il y a deux questions en fait, pourquoi détecter la topologie, et pourquoi pinner ses threads.

 

Pour la première, tout dépend de ce qu'on thread et comment. Quand on a un thread pool avec des traitements identiques //, effectivement en général on compte le nombre de coeurs pour déterminer la taille et ca suffit. Il peut cependant y avoir des cas plus compliqués. Un exemple dans notre protocole est DxO, il autorise le traitement de plusieurs photos en simultanée, et chaque traitement (qui n'est pas forcément identique, on peut appliquer des filtres différents a chaque photo) peut avoir des parties threadées elles même, voir déportées vers le GPU en OpenCL. Pour un logiciel grand public, là on peut avoir un intérêt a se dire j'autorise un maximum de N traitements qui spawneront peut etre (ou pas) d'autres threads pour une partie des filtres voir déporteront quelques kernels en OpenCL. Du coup DxO autorise autant de threads que de coeurs physiques au max. Ca ne l'empeche pas de profiter du SMT/HT d'ailleurs, certains filtres sont MT, mais ils ont fait ce compromis qui n'est pas mauvais a mon avis. Il y a aussi des cas ou certains algos peuvent créer des contentions de ressources et ou il est préférable d'ignorer les coeurs HT (pour exactement le même type de raison que tu ferais la même chose sur du NUMA, pas oublier aussi que quand on code pour du grand public on ne sait pas sur quoi on va tourner donc il est prudent d'en faire plus).

 
mogana a écrit :


A moins que f1 2016 utilise une api bas niveau qui détermine le nombre de cœurs disponibles et en trouve 8 alors qu'il y en a 16 ?
après je suis pas développeur de jeu donc peut-être que pour eux il est utile de dispatcher leur thread sur les coeurs physiques puis logique, mais je ne connais pas d'api windows pour binder un thread sur un cœur particulier.


Donc non c'est le contraire pour F1 : ça détecte 16 coeurs (et ca ne détecte pas la présence de SMT/HT). Le problème vient de la seconde question, pourquoi pinner ses threads.

 

Il y a deux facteurs, le premier c'est qu'on ne peut pas toujours se reposer sur l'OS, que ce soit pour détecter le nombre de coeurs ou pour poser les threads au bon endroit. Les API Windows détectent parfaitement le SMT de Ryzen et théoriquement le scheduler Windows se débrouille pas trop mal, mais pour un jeu qui va tourner sur diverses consoles, on ne peut pas se reposer sur Windows, ou sur un OS précis. Et donc il faudra parfois manager quand même à la main. Et il faudra donc détecter le nombre de coeur et la topologie des plateforme avec des API de bas niveau.

 

Donc un moteur multi plateforme (c'est le cas de celui de codemasters) va avoir encore plus tendance à pinner ses threads. Et là il devient primordial de savoir qui fait quoi : si mon jeu requiert 4 gros threads et n petits threads qui peuvent aller n'importe ou, ou est ce que je pin mes 4 gros threads ? 1/2/3/4 ? Sur un système HT classique ça tombe sur le coeur 1 physique, le coeur 1 logique, le coeur 2 physique et le coeur 2 logique, donc le pire cas (on ne veut pas deux gros threads sur un même couple coeur physique/logique). Donc essentiel de détecter la présence d'HT (pareil pour les modules des FX ou la topologie va jouer un rôle dans la décision).

 

Après pour Windows il y a (je pense que c'est toujours vrai ?) un gros problème avec les timers. Un moteur de jeu a besoin de compter précisément le temps entre 2 frames, avec une précision supérieure aux timers classiques (1ms environ, pas suffisant). Il y a très longtemps on pouvait utiliser un compteur de cycles (RDTSC/P : https://en.wikipedia.org/wiki/Time_Stamp_Counter), avec les turbo/mécanismes de veille ça n'est plus trop possible. Il y a eu depuis des implémentations dites invariantes (qui bypassent le turbo) mais certains CPU n'en ont pas, pour ceux qui en ont, elles ne sont pas toutes identiques sur tous les CPU, et la fidélité de lecture n'est pas forcément garantie sur deux threads sur tous les CPU non plus. Microsoft à quelques infos intéressantes là : https://msdn.microsoft.com/en-us/li [...] #AppendixB

 

Résultat, ce que conseillait Microsoft aux développeurs de jeux, c'est d'utiliser son propre meta timer baptisé QPC (qui utilise ou pas RDTSC/P), en pinnant ses threads(via SetThreadAffinity). Cf ici sur ce vieux post sur archive.org : http://web.archive.org/web/2008011 [...] 73458.aspx

 

Donc la réponse courte, si les jeux pinnent leurs threads, c'est comme toujours la faute de Microsoft :)

 

Peut etre que Microsoft conseille autre chose aujourd'hui spécifiquement aux développeurs de jeux (si un dev d'un studio passe dans le coin hein qu'il n'hésite pas !), en général il me semble que ça reste leur recommandation. Évidemment, comme c'est Microsoft, l'implémentation exacte de QPC change d'une version de Windows à l'autre, ce qui rend la question encore plus compliquée. Plus de détails sur cette page en entier sur les variantes de timers et les problèmes : https://msdn.microsoft.com/en-us/li [...] s.85).aspx

Message cité 1 fois
Message édité par C_Wiz le 16-04-2017 à 14:07:43
n°10128173
mogana
Posté le 16-04-2017 à 20:49:49  profilanswer
0Votes positifs
 

C_Wiz a écrit :


Il y a deux questions en fait, pourquoi détecter la topologie, et pourquoi pinner ses threads.  
 
Pour la première, tout dépend de ce qu'on thread et comment. Quand on a un thread pool avec des traitements identiques //, effectivement en général on compte le nombre de coeurs pour déterminer la taille et ca suffit. Il peut cependant y avoir des cas plus compliqués. Un exemple dans notre protocole est DxO, il autorise le traitement de plusieurs photos en simultanée, et chaque traitement (qui n'est pas forcément identique, on peut appliquer des filtres différents a chaque photo) peut avoir des parties threadées elles même, voir déportées vers le GPU en OpenCL. Pour un logiciel grand public, là on peut avoir un intérêt a se dire j'autorise un maximum de N traitements qui spawneront peut etre (ou pas) d'autres threads pour une partie des filtres voir déporteront quelques kernels en OpenCL. Du coup DxO autorise autant de threads que de coeurs physiques au max. Ca ne l'empeche pas de profiter du SMT/HT d'ailleurs, certains filtres sont MT, mais ils ont fait ce compromis qui n'est pas mauvais a mon avis. Il y a aussi des cas ou certains algos peuvent créer des contentions de ressources et ou il est préférable d'ignorer les coeurs HT (pour exactement le même type de raison que tu ferais la même chose sur du NUMA, pas oublier aussi que quand on code pour du grand public on ne sait pas sur quoi on va tourner donc il est prudent d'en faire plus).  
 


 
 
 

C_Wiz a écrit :


Donc non c'est le contraire pour F1 : ça détecte 16 coeurs (et ca ne détecte pas la présence de SMT/HT). Le problème vient de la seconde question, pourquoi pinner ses threads.
 
Il y a deux facteurs, le premier c'est qu'on ne peut pas toujours se reposer sur l'OS, que ce soit pour détecter le nombre de coeurs ou pour poser les threads au bon endroit. Les API Windows détectent parfaitement le SMT de Ryzen et théoriquement le scheduler Windows se débrouille pas trop mal, mais pour un jeu qui va tourner sur diverses consoles, on ne peut pas se reposer sur Windows, ou sur un OS précis. Et donc il faudra parfois manager quand même à la main. Et il faudra donc détecter le nombre de coeur et la topologie des plateforme avec des API de bas niveau.  
 
Donc un moteur multi plateforme (c'est le cas de celui de codemasters) va avoir encore plus tendance à pinner ses threads. Et là il devient primordial de savoir qui fait quoi : si mon jeu requiert 4 gros threads et n petits threads qui peuvent aller n'importe ou, ou est ce que je pin mes 4 gros threads ? 1/2/3/4 ? Sur un système HT classique ça tombe sur le coeur 1 physique, le coeur 1 logique, le coeur 2 physique et le coeur 2 logique, donc le pire cas (on ne veut pas deux gros threads sur un même couple coeur physique/logique). Donc essentiel de détecter la présence d'HT (pareil pour les modules des FX ou la topologie va jouer un rôle dans la décision).
 
Après pour Windows il y a (je pense que c'est toujours vrai ?) un gros problème avec les timers. Un moteur de jeu a besoin de compter précisément le temps entre 2 frames, avec une précision supérieure aux timers classiques (1ms environ, pas suffisant). Il y a très longtemps on pouvait utiliser un compteur de cycles (RDTSC/P : https://en.wikipedia.org/wiki/Time_Stamp_Counter), avec les turbo/mécanismes de veille ça n'est plus trop possible. Il y a eu depuis des implémentations dites invariantes (qui bypassent le turbo) mais certains CPU n'en ont pas, pour ceux qui en ont, elles ne sont pas toutes identiques sur tous les CPU, et la fidélité de lecture n'est pas forcément garantie sur deux threads sur tous les CPU non plus. Microsoft à quelques infos intéressantes là : https://msdn.microsoft.com/en-us/li [...] #AppendixB
 
Résultat, ce que conseillait Microsoft aux développeurs de jeux, c'est d'utiliser son propre meta timer baptisé QPC (qui utilise ou pas RDTSC/P), en pinnant ses threads(via SetThreadAffinity). Cf ici sur ce vieux post sur archive.org : http://web.archive.org/web/2008011 [...] 73458.aspx
 
Donc la réponse courte, si les jeux pinnent leurs threads, c'est comme toujours la faute de Microsoft :)
 
Peut etre que Microsoft conseille autre chose aujourd'hui spécifiquement aux développeurs de jeux (si un dev d'un studio passe dans le coin hein qu'il n'hésite pas !), en général il me semble que ça reste leur recommandation. Évidemment, comme c'est Microsoft, l'implémentation exacte de QPC change d'une version de Windows à l'autre, ce qui rend la question encore plus compliquée. Plus de détails sur cette page en entier sur les variantes de timers et les problèmes : https://msdn.microsoft.com/en-us/li [...] s.85).aspx  


 
Merci, c'est très clair  :jap:  
tu me laisses même pas la possibilité de rebondir  :o  
en tout j'ai appris des choses, merci encore  :)  

n°10128425
mrteub
Posté le 17-04-2017 à 11:57:05  profilanswer
0Votes positifs
 

Intéressant

n°10128621
svenos
Posté le 17-04-2017 à 16:06:07  profilanswer
0Votes positifs
 

De ce que j'ai compris dans ces benchs, en matière de jeux video, le 1500x smt off se situe devant tout les autres processeurs AMD, quelles sont ses performances par rapport à un 7700k? Si j'interprète bien, à l'heure actuelle et pour les jeux actuels, le 1500x est le processeur le plus performant pour le jeux video. Bien que ce ne soit pas une solution de long terme, pouvez vous confirmer ou infirmer ce point?

n°10128627
sagittaire
Posté le 17-04-2017 à 16:12:38  profilanswer
0Votes positifs
 

Marc a écrit :


Sinon observations intéressantes à ceci près que les fichiers à compresser auront pas mal d'influence, on a des taux d'utilisations CPU bien plus importants que les tiens par exemple. Dans le cas de tes fichiers le zip non compressés doit probablement permettre à l'algo de LZMA2 de contourner certaines difficultés qu'il a de base sur ton répertoire.  


 
En fait je crois que sur mon i5-3550 avec de la DDR3 1600 je tombe beaucoup plus tôt que vous sur le problème de la vitesse de RAM. Plus la qualité de compression augmente et plus la quantité de RAM nécessaire augmente à cause de la plus grande taille des dictionnaires. Du coups je suis limité en terme de performance CPU sur mon i5-3550 à partir de la qualité de compression mx5.
 
 

|-----------|----------|----------|-----------|
|  qualité  | temps(s) | size(MB) | charge(%) |
|-----------|----------|----------|-----------|
|      mx0  |     4.39 |      810 |        22 |
|      mx1  |    21.16 |      559 |       371 |
|      mx2  |    30.14 |      556 |       379 |
|      mx3  |    44.94 |      551 |       376 |
|      mx4  |    49.09 |      543 |       381 |
|      mx5  |    71.74 |      517 |       318 |
|      mx6  |    78.53 |      513 |       304 |
|      mx7  |   128.86 |      504 |       235 |
|      mx8  |   127.11 |      499 |       228 |
|      mx9  |   127.10 |      499 |       229 |
|-----------|----------|----------|-----------|


Message édité par sagittaire le 17-04-2017 à 16:13:51
mood
Publicité
Posté le 17-04-2017 à 16:12:38  profilanswer
 

n°10128628
dark oopa
PSN: Dark_Oopa
Posté le 17-04-2017 à 16:12:41  profilanswer
0Votes positifs
 

svenos a écrit :

De ce que j'ai compris dans ces benchs, en matière de jeux video, le 1500x smt off se situe devant tout les autres processeurs AMD, quelles sont ses performances par rapport à un 7700k? Si j'interprète bien, à l'heure actuelle et pour les jeux actuels, le 1500x est le processeur le plus performant pour le jeux video. Bien que ce ne soit pas une solution de long terme, pouvez vous confirmer ou infirmer ce point?


 
relis bien...

n°10128634
svenos
Posté le 17-04-2017 à 16:21:00  profilanswer
1Votes positifs
 

Ah oui effectivement, c'est l'inverse, autant pour moi. Mais quid des perfs du 1500x vs un 7700k par exemple? le 1500X smt enabled serait le plus rapide des processeurs pour le jeux vidéo à l'heure actuelle?

n°10128635
dark oopa
PSN: Dark_Oopa
Posté le 17-04-2017 à 16:23:26  profilanswer
0Votes positifs
 

svenos a écrit :

Ah oui effectivement, c'est l'inverse, autant pour moi. Mais quid des perfs du 1500x vs un 7700k par exemple? le 1500X smt enabled serait le plus rapide des processeurs pour le jeux vidéo à l'heure actuelle?


 
non, et il n'y a aucune raison que ça le soit...
 
http://www.hardware.fr/articles/95 [...] mance.html

n°10128640
svenos
Posté le 17-04-2017 à 16:31:10  profilanswer
0Votes positifs
 

J'ai oublié de préciser, le plus rapide dans les gammes d'AMD. Le dernier bench de cet article a donc comme indice, la valeur smt off propre à chaque processeur ce que je n'avais pas compris. Si le 1500x arrive à se placer devant le 7600k comme l'atteste le bench, il doit donc être au même niveau que le 1800x ou 1600x, j'aurai bien aimé avoir des chiffres pour ce cas de figure, car étant donné son prix, si l'utilisation est exclusivement dédié au jeux ça fait un processeur plus que correct pour son budget. On peut imaginer que les 6 et 8coeurs seront mieux exploités à l'avenir, mais cet avenir va quand même attendre quelques années à mon avis.

n°10128702
sagittaire
Posté le 17-04-2017 à 17:59:32  profilanswer
0Votes positifs
 

Marc a écrit :


 
Comme dis par C-Wiz pas mal de temps perdu pour vérifier quelque chose qui l'est déjà ;) J'ajoute que chez Intel le passage de 6C/12T à 8C/16T fait gagner 30% de performances sur notre protocole, proche des +33% maximums théoriques, là ou chez AMD c'est donc 20%.
 
Sinon observations intéressantes à ceci près que les fichiers à compresser auront pas mal d'influence, on a des taux d'utilisations CPU bien plus importants que les tiens par exemple. Dans le cas de tes fichiers le zip non compressés doit probablement permettre à l'algo de LZMA2 de contourner certaines difficultés qu'il a de base sur ton répertoire.  


 
et autre observation amusante sur mon i5 3550 4C/4T:
 

|-----------|----------|----------|-----------| 4 Threads
| mx0 mmt4  |     4.39 |      810 |        22 |
| mx1 mmt4  |    21.16 |      559 |       371 |
| mx2 mmt4  |    30.14 |      556 |       379 |
| mx3 mmt4  |    44.94 |      551 |       376 |
| mx4 mmt4  |    49.09 |      543 |       381 |
| mx5 mmt4  |    71.74 |      517 |       318 |
| mx6 mmt4  |    78.53 |      513 |       304 |
| mx7 mmt4  |   128.86 |      504 |       235 |
| mx8 mmt4  |   127.11 |      499 |       228 |
| mx9 mmt4  |   127.10 |      499 |       229 |
|-----------|----------|----------|-----------|
 
|-----------|----------|----------|-----------| 6 Threads
|  qualité  | temps(s) | size(MB) | charge(%) |
|-----------|----------|----------|-----------|
| mx0 mmt6  |     2.57 |      810 |        32 |
| mx1 mmt6  |    21.13 |      559 |       375 |
| mx2 mmt6  |    30.42 |      556 |       387 |
| mx3 mmt6  |    44.28 |      551 |       387 |
| mx4 mmt6  |    49.12 |      543 |       387 |
| mx5 mmt6  |    67.72 |      517 |       351 | +5.0%
| mx6 mmt6  |    73.96 |      513 |       340 | +6.0%
| mx7 mmt6  |   128.79 |      504 |       235 |
| mx8 mmt6  |   126.58 |      499 |       232 |
| mx9 mmt6  |   125.94 |      499 |       232 |
|-----------|----------|----------|-----------|
 
|-----------|----------|----------|-----------| 8 threads
|  qualité  | temps(s) | size(MB) | charge(%) |
|-----------|----------|----------|-----------|
| mx0 mmt8  |     3.24 |      810 |        31 |
| mx1 mmt8  |    21.16 |      559 |       378 |
| mx2 mmt8  |    30.22 |      556 |       387 |
| mx3 mmt8  |    43.76 |      551 |       392 |
| mx4 mmt8  |    49.34 |      543 |       386 |  
| mx5 mmt8  |    65.92 |      517 |       371 | +8.8%
| mx6 mmt8  |    71.77 |      513 |       355 | +9.4%
| mx7 mmt8  |   130.28 |      504 |       232 |
| mx8 mmt8  |   128.56 |      499 |       226 |
| mx9 mmt8  |   128.81 |      499 |       230 |
|-----------|----------|----------|-----------|


 
Augmenter le nombre de threads logiciel (de 4 par défaut à 8) me permet d'augmenter significativement la charge CPU jusqu'à la qualité mx6. Après je dois retomber sur la limitation du système mémoire dont vous parliez.
 
Cela semble montrer qu'avec un i5 4C/4T sous 7zip, le nombre de threads logiciels optimal n'est pas le nombre de coeur physique (valeur par défaut dans 7zip)
 
De plus quand on analyse en détail vos résultats on observe cela:
- l'écart le plus important entre un i7-6700K et un i5-7600K c'est sous 7zip (près de 43%)
- l'écart le plus faible entre un i7-6700K et un i7-7700K c'est sous 7zip (2.4% contre 8.5% en moyenne)
- l'écart le plus faible entre un i5-7600K et un i3-7350K c'est sous 7zip (13.8% contre 42% en moyenne)
- La plate forme est exactement la même pour tous les CPU sur socket 1151
 
 
Si je devais parier, je dirais qu'il y aurait probablement moyen d'augmenter significativement le score de tous les CPU i5 (sans HT donc) sur 7zip en doublant le nombre de coeurs logiciels par rapport aux nombre de coeurs physiques.


Message édité par sagittaire le 17-04-2017 à 18:09:32
n°10128713
Marc
Super Administrateur
Chasseur de joce & sly
Posté le 17-04-2017 à 18:13:25  profilanswer
2Votes positifs
 

On s'ennuie le lundi de pâques ?

 

Quand ton CPU "attends" après la mémoire, il ne me semble pas que ça fait baisser le taux d'utilisation CPU pour autant.

 

Sinon, oui, augmenter le nombre de thread fait augmenter les perfs sous 7-zip, avec ou sans HT d'ailleurs, peut-être plus sans HT je ne sais pas. x2 avec beaucoup de coeurs ça prends vraiment trop de mémoire, x1.5 est plus raisonnable.

Message cité 1 fois
Message édité par Marc le 17-04-2017 à 18:17:32
n°10128763
sagittaire
Posté le 17-04-2017 à 18:59:50  profilanswer
0Votes positifs
 

Marc a écrit :

On s'ennuie le lundi de pâques ?
 
Quand ton CPU "attends" après la mémoire, il ne me semble pas que ça fait baisser le taux d'utilisation CPU pour autant.
 
Sinon, oui, augmenter le nombre de thread fait augmenter les perfs sous 7-zip, avec ou sans HT d'ailleurs, peut-être plus sans HT je ne sais pas.


 
Et ouai, me fait un petit chier, j'ai bouffé tous les oeufs ce matin et il m'en reste plus ... ;-)
 
J'ai que 4 Go de DDR3 à 1600 Mhz sur mon système, la limitation vient peut-être de là. Avec la qualité mx6, 7zip utilise déjà 1750 MB de RAM. Mon SSD prend peut-être le relais au dessus de la qualité mx7, ce qui plombe les perfs?  
 
Sinon pour les perfs i5, elles sont vraiment très faibles sous 7zip: un i7-3770K colle 40% de mieux à un i5-7600K.
 
 

Citation :

x2 avec beaucoup de coeurs ça prends vraiment trop de mémoire, x1.5 est plus raisonnable.


 
Après si tu compares un i5-7600K avec 8 threads logiciel et un i7-6700K avec 8 threads logiciel, tu utilise le même volume mémoire.
Le nombre de thread ne serait qu'à doubler que pour les i5 pour faire une comparaison plus directe.

Message cité 1 fois
Message édité par sagittaire le 17-04-2017 à 21:15:30
n°10128888
C_Wiz
Profil : Equipe HardWare.fr
Posté le 17-04-2017 à 21:41:41  profilanswer
3Votes positifs
 

sagittaire a écrit :


Et ouai, me fait un petit chier


On avait remarqué  :o  
 

sagittaire a écrit :


4 Go de DDR3
i5-7600K  
i7-6700K


Donc en fait y'a juste aucun rapport avec l'article. Merci d'arrêter de polluer le sujet et de laisser la place aux autres qui auraient des questions en rapport.


Message édité par C_Wiz le 17-04-2017 à 21:52:46
n°10129189
Eric B
Posté le 18-04-2017 à 12:49:30  profilanswer
2Votes positifs
 

merci pour cet énième article qui éclaire un peu plus comment AMD va pousser l industrie à faire encore plus de logiciels multithréadés.
 
Notamment au niveaux des jeux, y a t il des études sur l occupation des modules et threads sur les consoles PS4 et XBox one équpées en AMD Jaguar 8C ?
Autrement dit, dans quelle mesure ces 8C de consoles peuvent avoir une influence pour les jeux sur PC?
Et si la prochaine PS5 ou Xbox2 seront basées sur un Ryzen (ou Zen2), ce sera encore plus intéressant!

n°10129932
vanloque
Someone broke my AT Field
Posté le 19-04-2017 à 10:59:49  profilanswer
0Votes positifs
 

Eric B a écrit :

merci pour cet énième article qui éclaire un peu plus comment AMD va pousser l industrie à faire encore plus de logiciels multithréadés.
 
Notamment au niveaux des jeux, y a t il des études sur l occupation des modules et threads sur les consoles PS4 et XBox one équpées en AMD Jaguar 8C ?
Autrement dit, dans quelle mesure ces 8C de consoles peuvent avoir une influence pour les jeux sur PC?
Et si la prochaine PS5 ou Xbox2 seront basées sur un Ryzen (ou Zen2), ce sera encore plus intéressant!


Sur ces consoles les devs ont tout intérêt à distribuer au mieux la charge sur tous les coeurs dispos (6 ou 7 sur la PS4 par exemple). Donc à terme ça finira toujours par être bénéfique pour le pc.
Et vu qu'on sait que les cpu AMD continuent d'être adoptés pour les prochaines consoles, ça va continuer dans le bon sens. La Box Scorpio parle de coeurs AMD Customs, on verra dans les mois suivants s'il s'agit d'architecture Ryzen ou pas.


---------------
--- https://steamcommunity.com/id/Vanlock ---
n°10129937
dark oopa
PSN: Dark_Oopa
Posté le 19-04-2017 à 11:03:35  profilanswer
0Votes positifs
 

vanloque a écrit :


Sur ces consoles les devs ont tout intérêt à distribuer au mieux la charge sur tous les coeurs dispos (6 ou 7 sur la PS4 par exemple). Donc à terme ça finira toujours par être bénéfique pour le pc.
Et vu qu'on sait que les cpu AMD continuent d'être adoptés pour les prochaines consoles, ça va continuer dans le bon sens. La Box Scorpio parle de coeurs AMD Customs, on verra dans les mois suivants s'il s'agit d'architecture Ryzen ou pas.


 
on sait déjà qu'il s'agit de jaguars  légèrement modifiés

n°10129945
vanloque
Someone broke my AT Field
Posté le 19-04-2017 à 11:10:03  profilanswer
0Votes positifs
 

dark oopa a écrit :


 
on sait déjà qu'il s'agit de jaguars  légèrement modifiés


Ah ? autant pour moi et dommage !  
Coté Sony y'aura pas d'autre machine avant quoi, un an ?


---------------
--- https://steamcommunity.com/id/Vanlock ---
n°10129989
C_Wiz
Profil : Equipe HardWare.fr
Posté le 19-04-2017 à 11:45:10  profilanswer
2Votes positifs
 

A mon avis 0 chance de voir Ryzen dans la génération actuelle ou ses updates. Parce que le code est encore plus bas niveau et que les archis étaient très particulières, c'est vraiment pas une bonne idée pour les jeux anciens de switcher comme ca.  
 
On a vu ce que SMT/HT mal géré peut faire comme dégâts, alors dans un monde ou les devs doivent tout gérer a la main c'est encore pire. Même avec largement plus de puissance potentielle on peut avoir des problèmes liés aux différences de comportements des CPU.  
 
Sinon sur l'occupation des threads sur console, pas possible, c'est fermé et on a pas les outils pour. Globalement les consoles sont très particulières. Les API sont différentes (DX12/Vulkan/Metal sont plus proches dans l'esprit des API consoles, même si encore un poil plus haut niveau dans le sens ou ca doit gérer des choses en plus), mais l'OS et l'environnement aussi. Un jeu sur console en plus d'avoir un hardware a peu près fixe (a 2/3 SKU près) tourne a peu près seul sur l'OS (oui il y a des trucs en arrière plan mais pas tant que ca, on est très loin de Windows ou il peut y avoir de la vrai concurrence). Donc c'est un monde différent dont le PC tente de se rapprocher pour être moins innefficace. Les API bas niveaux sont le premier pas mais on voit que Windows 10 n'aide pas, pour faire court.

n°10130530
Kardahs
Posté le 20-04-2017 à 01:00:18  profilanswer
0Votes positifs
 

Comme Windows 10 n'aide pas, et pas que pour le jeu, pour faire court faut passer à Linux ^^

n°10131506
Eric B
Posté le 21-04-2017 à 11:46:15  profilanswer
0Votes positifs
 

En parlant de ps5/xbox2, je pensais à la génération prochaine des consoles, sans doute vers 2020, pas celle actuelle (y compris les updates).
Il ne peut s'agir de Ryzen mais d'une variante low power issue des APU Zen (eux mêmes pas avant 2018), comme les Jaguar sont variante low power (25W max) sorti à l'époque de Kaveri.

n°10131698
quake_addi​ct
Posté le 21-04-2017 à 15:26:02  profilanswer
0Votes positifs
 

Bonjour à tous.

 

Déjà félicitation pour vos articles, je veux changer de configuration et j'ai lu beaucoup de sites anglophones sur le hardware pour cela. Vos articles sont ceux qui vont le plus loin dans les tests, avec par exemple, des articles remarquables sur l'influence du sous-système mémoire ou du SMT.

 

Mais j'ai cependant quelques observations à faire sur votre protocole expérimental et votre démarche scientifique:

 


Observation 1:
vous comparez donc l'impact du nombre de cœurs. Mais si je comprends bien vous avez testé les CPU à leurs fréquences de base et pas à une fréquence fixe.
N'aurait-il pas été plus pertinent de faire les tests à une fréquence fixe pour avoir des résultats plus directement comparables avec les gains théoriques potentiels?

 

Observation 2:
Si je comprends bien le fonctionnement du XFR, c'est un mode turbo supplémentaire qui pourra s'activer quand les conditions seront favorables (Puissance consommée faible?, température faible?). Mais on peut probablement estimer que le XFR trouvera un terrain plus favorable pour s'activer en mode "SMT Off" qu'en mode "SMT On", du fait d'une charge moins importante sur les cœurs.
Le XFR était-il actif lors de vos tests?
Le XFR n'a-t-il pas un impact sur les résultats en "SMT On" et "SMT Off"?

 

Observation 3:
Si j'en crois vos propres tests sur 7zip, augmenter le nombre de processus actifs (Threads logiciels?), permet d’augmenter la charge CPU et donc les performances. Je vous cite:

 
Citation :

"Sinon, oui, augmenter le nombre de thread fait augmenter les perfs sous 7-zip, avec ou sans HT d'ailleurs, peut-être plus sans HT je ne sais pas. x2 avec beaucoup de cœurs. ça prends vraiment trop de mémoire, x1.5 est plus raisonnable."

 

D'après ce que je comprends, 7zip choisi par défaut un nombre de "threads logiciels" égal au nombre de "threads logiques" détecté par le logiciel lui-même. Mais cela pose alors une question sur le test avec 7zip en "SMT On" et "SMT Off" car vous faites la comparaison suivante:

 

- 7zip en "SMT Off": "threads logiciels" = "threads physiques"
- 7zip en "SMT On": "threads logiciels" = "threads logiques"

 

Vous faites donc une comparaison avec un nombre de threads logiciels qui varie d'un test à l'autre, alors que pour avoir une comparaison rigoureuse entre "SMT Off" et "SMT On", vous devriez avoir un nombre de threads logiciel constant et égal au double (au minimum) de threads physiques afin d'être certain de saturer complètement les cœurs du CPU.

 

J'anticipe une réponse possible de votre part: "Nous avons choisi le réglage par défaut du logiciel". Certainement, mais vous n'avez pas choisi la qualité de compression par défaut de 7zip, et d'autre part, l'interface du logiciel permet de choisir un nombre de threads logiciels égal, justement, au double du nombre de threads physiques/logiques détectés. On pourra prétendre sans risque que si les auteurs du logiciel 7zip le permettent, c'est qu'ils ont eux aussi observé que le nombre de threads détectés n'était pas toujours suffisant pour saturer les cœurs du CPU.

 

Pour finir, si ce raisonnement est exact (ce qui reste à démontrer car vous n'avez pas détaillé votre protocole dans ce domaine précis du choix du nombre de thread), vous allez donc probablement observer que les écarts sur 7zip entre "SMT On" et "SMT Off" vont se réduire, ce qui appuiera d'autant plus vos observations sur les limitations du système mémoire pour les CPU Ryzen. De plus cela pourrait aussi expliquer par la même occasion pourquoi l'activation de l'HyperThreading permet d'obtenir un tel niveau de performance dans 7zip (+40.5% avec un i7-6900K sur 7zip dans votre comparatif initial sur l'impact du SMT/HT, soit presque le double de la moyenne de +22.5%).

 

Observation 4:
Une question simple vient donc ici. Ce qui est, par hypothèse, observable avec 7zip, peut-il l'être avec d'autres applications? Il faudrait d'abord pour le vérifier que le nombre de threads logiciels soit paramétrable:

 

- Winrar: winrar permet aussi de régler le nombre de "threads logiciels"
- Visual Studio 2015 et MinGW 64/GCC 6.2.0: ?
- x264 et x265: oui pour le x264, je ne sais pas pour le x265 (Sagittaire le sais peut-être?)
- Stockfish 8 et komodo 10: oui pour les deux
- Lightroom 6.7: peut-être qu'il faudrait ici un nombre d'export égal au nombre de cœurs. physiques des CPU
- DxO Optics Pro 11.2: vous utilisez le réglage max à chaque fois
- Mental Ray et V-Ray 3.4: oui pour les deux


Message édité par quake_addict le 21-04-2017 à 15:46:52
n°10131752
Marc
Super Administrateur
Chasseur de joce & sly
Posté le 21-04-2017 à 16:48:51  profilanswer
4Votes positifs
 

Je pense que le plus simple pour tes questions relatives à x265 est de demander à sagittaire directement puisqu'il semble être juste à côté de toi, si ce n'est plus...
 
Les questions de fréquence sont déjà abordées, l'écart est minime et ne justifie pas de repasser des heures sur le banc de test pour un article rapide.
 
Sinon pour répondre au nombre de thread il est effectivement probable que le protocole avantage légèrement l'HT sous 7z et WinRAR qui ne sont pas à 100% d'usage CPU avec les réglages thread = cœurs logiques. Mais utiliser thread = cœurs physiques serait à l'inverse désavantageux pour les CPU avec HT. Pet être qu'un réglage avec x1.5 vs cœurs logique serait plus équilibré pour 7z au moins mais se pose alors la question de la quantité de ram.
 
Enfin merci d'aller faire une fixette sur un autre média, avec quel que pseudo que ce soit, on a déjà passé assez de temps à te répondre et tu en abuses avec des méthodes douteuses qui plus est.

n°10131788
SynE
Posté le 21-04-2017 à 17:31:32  profilanswer
2Votes positifs
 

Il y en a qui feraient mieux de monter leur propre blog de hardware, ça rendrait les com plus lisibles.

n°10132183
sagittaire
Posté le 22-04-2017 à 13:06:19  profilanswer
0Votes positifs
 

Marc a écrit :

Je pense que le plus simple pour tes questions relatives à x265 est de demander à sagittaire directement puisqu'il semble être juste à côté de toi, si ce n'est plus...
Enfin merci d'aller faire une fixette sur un autre média, avec quel que pseudo que ce soit, on a déjà passé assez de temps à te répondre et tu en abuses avec des méthodes douteuses qui plus est.


 
Et non c'est un collègue à qui j'ai juste conseillé de lire votre site parce qu'il voulait changer sa config. C'est interdit?
 
 

Citation :

Les questions de fréquence sont déjà abordées, l'écart est minime et ne justifie pas de repasser des heures sur le banc de test pour un article rapide.


 
Oui et cela se retrouve du reste assez facilement si l'on connait la fréquence du turbo sur tous les cores. Par contre ne pas choisir de fréquence fixe conduit à avoir des résultats un peu curieux, puisque sur Komodo par exemple, vous dépassez le maximum théorique. Par contre, il est vrai que l'impact du XFR se pose ici car personne ne sait s'il se comporte de la même façon en SMT On ou Off.  
 
 

Citation :

Sinon pour répondre au nombre de thread il est effectivement probable que le protocole avantage légèrement l'HT sous 7z et WinRAR qui ne sont pas à 100% d'usage CPU avec les réglages thread = cœurs logiques. Mais utiliser thread = cœurs physiques serait à l'inverse désavantageux pour les CPU avec HT. Pet être qu'un réglage avec x1.5 vs cœurs logique serait plus équilibré pour 7z au moins mais se pose alors la question de la quantité de ram.


 
Ce que mon collègue vous dit ici, c'est que votre protocole expérimental devrait utiliser exactement la même ligne de commande en SMT On ou Off pour mesurer le gain réel de performance.
 
Pour 7zip avec un R5 1500X 4C/8T cela donne cette ligne de commande que cela soit avec SMT On ou Off
7z.exe a C:\Users\JFL\Desktop\zip\Benchmark1.7z C:\Users\JFL\Desktop\zip\test -bt -mx9 -mmt=8
 
Si vous laissez le programme choisir le nombre de thread, vous testez cela avec un R5 1500X:
7z.exe a C:\Users\JFL\Desktop\zip\Benchmark1.7z C:\Users\JFL\Desktop\zip\test -bt -mx9 -mmt=4 en SMT Off
7z.exe a C:\Users\JFL\Desktop\zip\Benchmark1.7z C:\Users\JFL\Desktop\zip\test -bt -mx9 -mmt=8 en SMT On
 
Si vous laissez choisir 7zip le nombre de thread automatiquement (qui est en fait ici le nombre de threads logiques détectés), vous aurez donc une mesure de gain sur le SMT qui sera fausse. D'autant plus qu'effectivement mmt=4 et mmt=8, n'utilise pas la même quantité mémoire.
 

Citation :

Observation 4:
Une question simple vient donc ici. Ce qui est, par hypothèse, observable avec 7zip, peut-il l'être avec d'autres applications? Il faudrait d'abord pour le vérifier que le nombre de threads logiciels soit paramétrable:


 
Ce qui est valable avec 7zip (et winrar?), l'est aussi avec toutes les autres applications: Si vous voulez mesurer exactement l'impact du SMT On et Off, vous devez utiliser exactement la même ligne de commande pour chaque application.
Et cela implique à chaque fois que c'est possible, de ne pas laisser l'application choisir le nombre de threads.
 
Alors après cela change-t-il en pratique quelque chose dans les résultats?  
 
Je vais me contenter de répondre pour les applications dont j'ai une bonne connaissance:  
 
pour le x264, l'application va elle même choisir un nombre de thread logiciel qui va généralement saturer le CPU. Donc les mesures en SMT off et On avec le x264 sont généralement fiables si on laisse l'application faire. Mais en toute rigueur, pour comparer les résultats en STM Off et On de manière précise, il faudrait utiliser la ligne de commande suivante sur un R5 1500X:
--crf 20 --preset slower --tune grain --ssim --psnr --threads 12
 
pour le x265, la situation se complique car le x265 utilise un protocole propre à la norme HEVC pour gérer le multithreading: le Wavefront Parallel Processing (WPP).
http://x265.readthedocs.io/en/default/threading.html
https://www.parabolaresearch.com/bl [...] ation.html
 
Du fait de nombreuses interdépendances, le codage (et le décodage aussi) en HEVC atteint très vite des limites en terme de threading et c'est géré directement par le x265 pour essayer de l'optimiser au maximum au niveau intra frames: le nombre de "rows WPP" va augmenter avec la résolution (les interdépendances intra frames posent moins de problème que pour celles en inter frames). C'est pour cette raison que pour saturer la charge d'un CPU 8C/16T, il faudra utiliser une résolution 4K.
 
Sinon le x265 utilise des commandes qui lui sont propres (--frame-threads) qui vont aussi automatiquement s'adapter en fonction du nombre de threads détectés. En tout état de cause votre mesure est fiable sur un 4C/8T, mais ce n'est plus du tout le cas sur les 6C/12T et les 8C/16T. Il faudrait utiliser une source 4K pour avoir une mesure fiable de l'impact SMT/HT on et off pour tous les CPU.


Message édité par sagittaire le 22-04-2017 à 13:14:48
n°10132296
Eric B
Posté le 22-04-2017 à 16:08:04  profilanswer
0Votes positifs
 

la discussion sous-jacente est finalement philosophique, suivant qu on se place côté machine ou côté utilisateur:
a) côté machine, pour détecter l influence stricte du SMT, il semble logique comme le suggère sagittaire et quake_addict de pouvoir eliminer tous les autres parametres et donc avoir un benchmark qui soit strictement à toutes chose égales par ailleurs, par ex en utilisant un ligne de commande.
b) côté utilisateur, l'approche est plus pratique: on utilise le logiciel tel qu'il est prévu dans un usage normal, et on change le paramètre qui nous intéresse (ici le SMT), ds le logiciel ou en externe, mais on laisse le logiciel se comporter 'par défaut', ce qui a aussi sa logique et est + proche de la réalité: on veut savoir comment se comportent le/les logiciels utilisés normalement chez chacun.
Le protocole de Hardware.fr semble plus proche de b).


Message édité par Eric B le 22-04-2017 à 16:16:56
n°10132425
Marc
Super Administrateur
Chasseur de joce & sly
Posté le 22-04-2017 à 19:08:06  profilanswer
2Votes positifs
 

Merci on sait utiliser 7zip.
 
Utiliser 2x le nombre de cœurs, uniquement sans HT, n'est pas possible dans toutes les applis et il n'est pas dit que ce réglage serait optimal pour tous les CPU avec HT, sans parler du fait que ce n'est pas le fonctionnement par défaut des applis.
 
On ne refera pas de test supplémentaire pour voir ça dans les cas où c'est possible. Il va falloir faire avec et passer à une autre occupation telle que les maquettes en allumettes, même si ça semble dur.
 
Ps : partager ses sessions navigateur avec un collègue c'est bizarre.

Message cité 1 fois
Message édité par Marc le 22-04-2017 à 19:13:13
n°10132532
SynE
Posté le 22-04-2017 à 23:10:07  profilanswer
2Votes positifs
 

Marc a écrit :


Ps : partager ses sessions navigateur avec un collègue c'est bizarre.


 
 :lol:  

Marc a écrit :


sans parler du fait que ce n'est pas le fonctionnement par défaut des applis.


 
Ben c'est surtout que la grande majorité des utilisateurs vont en faire de même, du coup le protocole est pertinent, fin de l'histoire.  :sarcastic:  
 
Tu est vachement patient de lui répondre encore et encore, même si c'est techniquement intéressant ça n'en reste pas moins de l'ergotage.  :o


Message édité par SynE le 22-04-2017 à 23:10:29
n°10132537
Uranium201​0
Gamer dans l'âme!
Posté le 22-04-2017 à 23:24:32  profilanswer
3Votes positifs
 

N'oublie surtout pas x264.
C'est pourtant la base, se palucher avec son pote en encodant toute la sainte journée, en mode "je suis un foufou, j'utilise les lignes de commandes".

 

Les commentaires sont souvent un bon prolongement aux excellents articles de HFR, on peut y lire des choses pertinentes, mais là ça deviens vraiment agaçant de perdre son temps à lire des conneries, donc merci de respecter les autres et lâcher prise
Comme Marc l'a si bien suggéré, il existe plein de passes temps divers et variés.

n°10133890
H4Cknisty
Posté le 25-04-2017 à 12:24:29  profilanswer
0Votes positifs
 

Sujet intéressant.
Ce que j'attends c'est un test entre la solution AMD et Intel LGA 2066.
 
Pour moi AMD a toujours été synonyme de lowcost.
Suffit de regarder l'offre des laptop toutes marques confondues.
Un latop AMD pour 399 voire 359 € TTC ...
 
Globalement l'applicatif est compilé sur Intel pour Intel.
Quand on voit le nombre de patch sortis ces derniers jours, c'est tout à fait représentatif.
Que ce soit les pro (architectes, Home studio, studio pro) et même les serveurs, il n'y a rien de sérieux qui tourne sur AMD.
Oui pour faire un Supercalculateur lowcost chinois. Mis à part ça ...
 
Je me souviens encore de l'époque des cartes mère AMD avec un chipset Nforce.
Le truc ignoble ...

n°10134279
SynE
Posté le 25-04-2017 à 18:45:55  profilanswer
0Votes positifs
 

H4Cknisty a écrit :

Sujet intéressant.
Ce que j'attends c'est un test entre la solution AMD et Intel LGA 2066.
 
Pour moi AMD a toujours été synonyme de lowcost.
Suffit de regarder l'offre des laptop toutes marques confondues.
Un latop AMD pour 399 voire 359 € TTC ...
 
Globalement l'applicatif est compilé sur Intel pour Intel.
Quand on voit le nombre de patch sortis ces derniers jours, c'est tout à fait représentatif.
Que ce soit les pro (architectes, Home studio, studio pro) et même les serveurs, il n'y a rien de sérieux qui tourne sur AMD.
Oui pour faire un Supercalculateur lowcost chinois. Mis à part ça ...
 
Je me souviens encore de l'époque des cartes mère AMD avec un chipset Nforce.
Le truc ignoble ...


 
20 fois plus fiable que les carte mère intel en nforce, bon c'est pas dur...  :)  :lol:  

n°10136777
winbravo
Posté le 29-04-2017 à 00:24:39  profilanswer
0Votes positifs
 

Ce qui m'intéresse avant tout c'est l'évolution croissante de ce genre de microprocesseurs, multiplié la fréquence d'accès à la (mémoire vive) ram, par le nombre de cœur, multiplié aussi par la fréquence en hertz de chaque cœur.
La puissance brut de calcul d'un microprocesseur avec 8 cœurs et une fréquence de 4 Giga hertz est de 8*4=32 Giga-hertz de fréquence brut de calcul cumulé.
L'accès à de multiple cœur de calcul en parallèle permet de créer autant de thread simultanément, et de les synchroniser ensemble quand "ils" ont fini leurs tache de calcul.

n°10143658
quake_addi​ct
Posté le 09-05-2017 à 14:28:52  profilanswer
0Votes positifs
 

Oups, les débats sont passionnés ici. Je ne voulais pas créer de polémique inutile. Pour tout dire je ne savais même pas que « Sagittaire » était le pseudo de mon collègue sur ce forum.
 
Je trouvais juste le sujet fort intéressant et il se trouve que c’est mon métier d'évaluer la pertinence d’un protocole expérimental : je fais ça depuis 19 ans en TIPE avec des étudiants en CPGE. Même si mon domaine de prédilection c’est quand même plutôt la physique.
 
Ceci étant, que cela soit pour les Sciences Humaines ou les Sciences Expérimentales, le protocole expérimental est toujours entièrement défini par la problématique. C’est la base même de toute recherche.
 
Or je n’arrive pas à savoir quelle est votre problématique. Où du moins j’hésite entre les deux options suivantes :
 
Problématique 1: vous avez voulu évaluer le gain maximum potentiel du parallélisme sur une base uniquement matériel.
Problématique 2 : vous avez voulu évaluer le gain maximum potentiel du parallélisme sur une base uniquement applicative.
 
La nuance est subtile mais elle détermine la structure de votre protocole expérimental : par exemple dans le cas de la problématique 1 avec l’application Adobe Lightroom, il faudrait lancer de nombreux processus pour saturer la charge « CPU » car cette application profite mal su « SMT ». Dans le cas de la problématique 2, il faudrait lancer un seul processus avec cette application. Or vous avez testé une situation intermédiaire : deux processus en même temps qui profitent un peu mieux du « SMT » sans pour autant en saturer la charge « CPU ».
 
De la même façon il aurait fallu, sauf contre-indication, au moins utiliser la même commande pour voir les gains dans les cas « SMT Off » ou « SMT On » pour en évaluer réellement l’impact. Pour beaucoup d’applications, le nombre de processus est défini par détection automatique du nombre de coeurs logiques : Lancer une application avec n processus actifs sur un CPU nC/nT et 2n processus actifs sur un même CPU reconfiguré en nC/2nT ne permet pas de faire une évaluation correcte de l’impact du SMT. Et il semble qu’au moins pour 7zip et winrar, le problème ne soit pas négligeable.
 
Bonne continuation.
 
 
"Ps : partager ses sessions navigateur avec un collègue c'est bizarre."
 
Comme sur un PC dans un labo qui sert à faire de la spectrophotométrie infrarouge, qui reste allumé et en libre accès au cours d'un TP pour que les étudiants puissent faire leur spectres, par exemple?


Message édité par quake_addict le 09-05-2017 à 15:20:51
n°10160538
Lunaska
Canard Equèstre
Posté le 04-06-2017 à 01:29:15  profilanswer
0Votes positifs
 

Le problème bien plus du fait que a l'heure actuel jeux ou logiciel appli ne sont plus optimiser par leur dév

mood
Publicité
Posté le   profilanswer
 

 Page :   1  2
Page Suivante

Aller à :
Ajouter une réponse
 

Sujets relatifs
[HFR] Actu : GTX 1070 simple slot pour Galax / KFA²Solidarité HFR :D besoin de vos modèles de bios et carte-mere
[HFR] Actu : BDD o/c : Ajout des Ryzen[HFR] Actu : Dell lance son OLED 4K à 3500$
Ryzen 5 1600 et Asus PRIME B350-PLUS pas de signal vidéoConfig 1500euros ryzen
[HFR] Dossier : AMD Ryzen 5 1600X, 1600, 1500X et 1400 en testinfluence de consommation RAM suivant la résolution
Plus de sujets relatifs à : [HFR] Focus : Influence du nombre de coeurs et du SMT sur Ryzen


Copyright © 1997-2022 Hardware.fr SARL (Signaler un contenu illicite / Données personnelles) / Groupe LDLC / Shop HFR