FS20 Nos performances sont un peu limitées

[Ptipilot]

Les P-cores correspondent aux cœurs classiques. Ce sont eux qui sont utilisés pour les charges lourdes comme nos simu par exemple.
Les E-cores sont là pour traiter les tâches d'arrière plan qui ne demandent pas de puissance.
La répartition est assuré par l'Intel Thread Director en tandem avec l'OS. Les threads ne sont donc pas envoyés au hasard sur les P-cores et E-cores.

En fait, c'est vrai... Mais, c'est faux également!...

Je m'explique... Pas taper l'ami @Loader
Il n'y a pas à proprement parlé de flag au niveau de la programmation d'un soft qui précise si c'est une tâche d'arrière plan ou une tâche d'avant plan.
Les Threads ou les Fibers sont donc engagés avec l'héritage à un instant "T" du niveau du processus parent.

Sur une configuration dite de type Bureautique, les process sont tour à tour en avant et en arrière plan en fonction de l'activité de l'utilisateur et donc les timing respectif de ses taches en avant et en arrière plan sont liés avec la règle des Quantums défini sur le poste.
Cela est donc relativement transparent pour l’utilisateur.
Dans ce cas de figure, l'architecture présentée par Intel fonctionne à merveille, car l'OS connait à un instant "T", la nature de se qu'il a mis en gestion au travers de son scheduler.

Dans le cadre de nos joujoux...
Le problème est bien différent, car par nature nous avons un processus qui impérativement doit rester au premier plan (Ex-notion du Focus...) durant plusieurs heures.
Ce qui fait que par héritage les Threads et Fibers seront eux également en premier plan.
Donc, de ce fait l'OS et le Thread Director ne savent plus faire de différence sur ce processus et ne peuvent pas dispatcher "judicieusement" tous ce beau monde en fonction des deux types de Core alors que la demande en puissance CPU est élevée.

Perso, si on me forçait à utiliser ce type d'architecture, je bloquerai ce mécanisme, même si c'est au détriment d'une fréquence maxi moins élevée.

 

[Ptipilot]

Il y a quelques années , le dev en chef de Laminar préconisait de :

1. ne pas overclocker le CPU
2. ne pas désactiver le multi-threading dans le bios
3. ne pas utiliser Process Lasso

Je comprends le dev en chef de chez Laminar...
Process Lasso est un super produit et terriblement puissant. Je l'utilise pratiquement depuis son origine.
Par contre, lorsqu'il est mis entre de mauvaises mains... Il peut causer plus de problèmes que de ne pas l'utiliser!...

Après ça dépend peut-être aussi de ce qui tourne à côté du simu : avec tous nos soft annexes (LNM, client IVAO/Vatsim, tracker de compagnie virtuelle, etc...) le résultat ne serait peut-être pas le même.

C'est bien la fameuse phase d'Intégration... Et, Process Lasso est particulièrement efficace pour la configuration de cette partie.

 

[Ptipilot]

AMS Ryzen Threadripper 1950x 27,593 ( @Ptipilot , heureusement que tu as du coeur ! )

C'est ce que je cherchais lorsque je l'ai acheté.

Perso, je ne regarde JAMAIS les benchs!...
Par contre, je suis très attentif à l'architecture du proc.

Pour l'instant, j'étudie tranquillement le remplacement de mon poste actuel et je regarde les proc avec 2 noeuds de 16 cores. En Janvier je vais commencer à coucher tous cela sur une feuille Excel.

 

[Typpex]

Et si les performances sont limitées (c'est combien, limitées ?), je cite, "lorsqu'on élève le niveau de détail", il y a des chances que le pb soit dans la CG, non ?

 

[Ptipilot]

Et si les performances sont limitées (c'est combien, limitées ?), je cite, "lorsqu'on élève le niveau de détail", il y a des chances que le pb soit dans la CG, non ?

Il y a des chances... Ou pas!...

 

[Playrec]

@Ptipilot !

Tu me sors les bench quand ça t'arrange et tu oses dire que tu ne les regardes pas !???!
Ton proc est à la rue .... tu passes plus temps à surveiller tes scripts LUA qu'à voler ... chacun son truc !
C'´est connu , avec tout le respect que je te dois , les gens du programme et la technique ça fait deux mon vieux ... Parfois tu as raison ... Parfois tu as tort ... Moi également ...
Je retourne dans mon cockpit avec mon logiciel de Simu qui ne me prends pas la tête ...

 

[Loader]

Ce qui fait que par héritage les Threads et Fibers seront eux également en premier plan.

Du coup il n'y a pas de problème : les threads et fibers du simu seront sur les P-cores. Les E-cores n'ont pas vocation à être utilisés par les threads et fibers du simu. Ils sont là pour faire tourner les autres programmes qui sont là en tâches de fond et ainsi libérer du temps CPU sur les P-cores.

 

[Jackpilot]

Hé BÉ.....comme d'hab....rien compris....

 

[Ptipilot]

Tu me sors les bench quand ça t'arrange et tu oses dire que tu ne les regardes pas !???!
Ton proc est à la rue .... tu passes plus temps à surveiller tes scripts LUA qu'à voler ... chacun son truc !

Fred, je ne comprends pas ta réaction...

Les benchs, je ne les regarde pas pour mon futur choix de proc (en tous genres...) et même dans mes réponses sur le forum, je ne les utilise presque jamais. Seulement pour éventuellement faire passer un message.

Que ma configuration soit aujourd'hui dépassée... Rien de nouveau sous le soleil!...
Elle a 5 ans, je vais me refaire une configuration principale (Mon projet 2024) et celle-ci va devenir mon poste secondaire de simu.

Pour ton information, j'ai encore mon ancien 1100T dans mon bureau sous XP qui ne me sert pratiquement plus à rien.

C'´est connu , avec tout le respect que je te dois , les gens du programme et la technique ça fait deux mon vieux ... Parfois tu as raison ... Parfois tu as tort ... Moi également ...

Là... Je n'ai pas vraiment compris ce que tu voulais dire!...


Sinon, il y a un point sur lequel je suis entièrement d'accord avec toi et je ne m'en cache pas...
Mon simulateur qui est mon fil rouge de retraité afin de ne pas m'emmerder, me permet de "consommer" mes heures avant de voir arriver la grande Faucheuse. Et dans ce cadre, comme j'ai toujours aimé la technique (En tous genres...), même si professionnellement j'ai fait un choix de carrière qui m'en a éloigné de manière volontaire et délibérée vers l'age de 45 ans, je continu à passer le plus d'heure sur celle-ci au travers de divers chantiers de mon simu.

Le vol proprement dit, c'est moins de 10% des heures de présence sur le simu.

Bah, il faut en profiter tant que la mécanique fonctionne encore à peu près correctement...

 

[Ptipilot]

Du coup il n'y a pas de problème : les threads et fibers du simu seront sur les P-cores. Les E-cores n'ont pas vocation à être utilisés par les threads et fibers du simu. Ils sont là pour faire tourner les autres programmes qui sont là en tâches de fond et ainsi libérer du temps CPU sur les P-cores.

Il n'y a pas de problème... Si, tu fais une intégration correcte et que tu joues sur le masque d'affinité de manière formelle pour lui interdire ou pas l’accès à ses cores en fonction de ta stratégie choisie de configuration de ton poste.
Sinon, tu auras des engagements sur ces E-Cores en fonction de la demande en charge CPU de ton Processus simu.

De manière explicite, il n'y a aucun flag discriminant qui permet de savoir au sein d'un processus, quel thread ou fiber doit et peut tourner en arrière-plan donc par effet de cascade sur les E-Cores de ces proc hybrides.
Et heureusement qu'il n'y a pas de flag de ce type, car le programmeur serait dans de beaux draps pour incorporer cette contrainte supplémentaire dans la logique de son programme.

Je ne suis pas contre ce type de proc à priori, par contre ils induisent des contraintes supplémentaires pour une utilisation comme les nôtres à partir du moment où l'on cherche à faire les choses correctement.


Après, chacun fait comme il le souhaite chez lui!...

 

[Churchill]

Hé BÉ.....comme d'hab....rien compris....

Et ben moi, j’ai parfaitement compris que je ne comprendrai jamais !

 

[forum_eric]

Merci pour vos commentaires qui, pour le coup, dépassent largement mes faibles connaissances en info...