Le jeu 20/05/2004 à 00:05, Bruno Muller a écrit : > Je confirme, mais le 2.6 vanilla ou debian n'est pas encore au top sur > ce domaine : appliquez les patchs de Con Kolivas (Hyperthread smart > "nice" en particulier).
Intéressant (j'avais pas pensé au coup du nice ;). Par contre, si j'ai bien compris, son patch ne va qu'au 2.6.4 J'utilise le 2.6.5 (et le 2.6.6 est sortie dans unstable), le patch n'a pas été incorporé ? > Sinon, l'hyper-threading c'est une magouille (grandement marketing) de > intel pour être plus dans la mouvance "parallélisme"... [...] Ben, disons que pour le prix, ça fait quand même un bô petit processeur. En poste de travail, j'ai jamais monté la charge à plus de 20% ;) Concernant l'hyperthreading, ce que j'ai pu remarqué, c'est que sans kernel SMP, on a une gestion "classique" des process, avec un kernel SMP, j'ai 2 proc et un système qui réagit toujours très vite, même si une tâche prend bcp de temps processeur (elle est affecté à 1 des 2 processeurs virtuels). Tout ça est peut-être virtuel, mais en tout cas Linux arrive mieux à utiliser les possibilités du proc "hyperthreadeux" avec un kernel SMP. Mon inquiétude était : si je simule 2 proc, qu'une tâche est affectée à 1 seul des 2 proc, qu'elle en utilise les 100% (donc 50% du total), est-ce que ma tâche n'est pas "bridée" en quelque sorte par rapport à une utilisation sous un kernel non SMP. Il semble que non, mis à part le pb du nice. > (benchs by myself pour le taf) > > Bref, une machine "hyperthreadée" est loin d'une machine smp du point de > vue des perfs... C'est sur. Mais par rapport à un CPU non Hyperthreading, il y a quand même un peu de gain (au moins en utilisation "poste de travail", et sûrement en serveur aussi). Et la différence de prix est pas énorme. Eric. > Pour plus de détails sur le comment : > http://developer.intel.com/technology/hyperthread/index.htm > > Bruno
