On commence à voir fleurir sur les sites d'info généralistes (clubic...) des tests des nouveaux pékat dual-core d'Intel.
Et nos joyeux drilles de constater que les gains sont pas terribles du tout, sur les applications grand public. (en gros, le FX55 bouffe toujours le P4EE toutes options)
On leur a expliqué que le SMP était quand même une technologie pas trop nouvelle ?
Sinon, question plus générale, pourrait-il y avoir une possibilité d'optimiser le SMP pour les processeurs dual core: par exemple, peut-on profiter d'une vitesse de communication accrue entre deux dies d'un même processeur ? Ou bien le scheduler d'un noyau est-il tellement complexe à écrire qu'il faudra des années pour en tirer avantage ?
Journal Le dual core : faussement nouveau ?
18
avr.
2005
# À la pointe de l'info
Posté par Jak . Évalué à 8.
Pas sûr qu'ils aient les capacités de comprendre (moi, méchant ? Juste un peu :) ).
De plus, les processeurs multicores existent déjà depuis pas mal d'années chez IBM, par exemple. Il se trouve juste qu'aujourd'hui, les processeurs grand-public vont utiliser ce principe pour améliorer les performances en environnements multitâches/multithreadés afin de compenser les difficultés actuelles des fondeurs à faire monter leurs puces en fréquence.
Ensuite, il y a plusieurs façons de faire la liaison interprocesseur, qui ne dépend que de la technologie déjà utilisée sur les gammes modifiées. Par exemple, sur les P4 d'Intel, le gain par arpport à une solution avec 2 processeurs distincts est très faible, car les processeurs se partagent un bus externe (ou un truc du genre), alors que les Athlon 64 d'AMD sont reliés, comme sur une solution à 2 processeurs, par un bus HyperTransport(TM), mais interne, ce qui améliore un chouia plus les performances du bicore.
En ce qui concerne l'amélioration des performances, je doute qu'il y ait quoique ce soit de particulier à faire au niveau du gestionnaire de processus noyau, mais bon, je n'y connaît pas grand'chose en SMP.
[^] # Re: À la pointe de l'info
Posté par Nicolas Boulay (site web personnel) . Évalué à 4.
Ainsi, Linux est Numa aware (bi-opteron, RAM séparé), Smt aware (Tous les niveaux de caches commun), Smp aware (RAM commune mais pas les caches)
"La première sécurité est la liberté"
# Scheduler domains
Posté par Thomas Petazzoni (site web personnel) . Évalué à 10.
D'après ce que j'ai compris, l'ordonnanceur du noyau dispose déjà d'un mécanisme appellé «scheduling domains», qui permet de prendre en compte la répartition des coeurs dans un systèmes : sur une même puce, sur deux puces différentes dans la même machine, sur des puces différentes dans des machines différentes (NUMA). Et en fonction de ça, l'ordonnanceur peut optimiser le placement des threads. Ainsi, au lieu de changer brutalement un thread d'un processeur à un autre, il peut essayer de le conserver dans le même processeur, pour bénéficier des effets de cache communs dans une architecture multi-coeur.
Voir paragraphe 5.7.2 de http://josh.trancesoftware.com/linux/linux_cpu_scheduler.pdf(...)
Thomas
[^] # Re: Scheduler domains
Posté par Lucas . Évalué à 5.
[^] # Re: Scheduler domains
Posté par Christophe Fergeau . Évalué à 5.
En ce qui concerne les procs dual-core d'intel, a priori ils n'ont rien du tout en commun, pas même le cache (c'est 1 Mo pour chaque coeur), l'article à ce sujet sur hardware.fr dit même :
« lorsque les deux core ont besoin de communiquer, on a l’obligation de passer par le chipset de la carte mère, comme c’est le cas d’une véritable configuration bi-processeur chez Intel. »
Le scheduler ne doit donc pas pouvoir faire grand chose de "rusé" sur ces procs là (hors hyperthreading).
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.