Das hier sollte bezüglich Thread-to-Core-Pinning interessant sein.
http://www.hipeac.net/system/files?file=carsten.pdf so ab Seite 11 sieht man was los ist.
oder halt CPU-Control 2.1 zum Thead-pinning nehmen. max. 4Cores
http://www.chip.de/downloads/CPU-Control_32204368.html
noch etwas dazu:
Nun sollen MC-CPUs dem Alltagsgeschäft und dem Spielspaß auf die Sprünge helfen. Bei den ersten Desktops mit zwei Prozessoren traten Dilemmas zu Tage: Den meisten Applikationen ist es schnurzegal, wie viel Prozessoren auf Arbeit warten, sie kennen und nutzen eh nur einen. Das verschärft sich bei der Integration in MC.
„Ja, wo laufen Sie denn?“ leitet das mehr oder weniger missliche Vergnügen ein, das beim Nutzen von Multi-core-Systemen aufkommen kann. Ohne zusätzliche Eingriffe von außen verteilen die Scheduler die anstehenden Prozesse nach eigenem Gutdünken. Zwar sind die aktuellen Betriebssysteme inzwischen darauf geeicht, die Wanderschaft zwischen den Kernen nicht ausufern zu lassen, doch wann und auf welchem Kern ein Prozess zum Zuge kommt und vor allem, wann er zum Ende kommt, ist nicht vorhersagbar. Es sei denn, Entwickler oder Anwender greifen zu Hilfsmitteln wie Affinities (Windows), taskset (Linux) oder pbind (Solaris), um nur einige zu nennen. Damit verspielt man aber einen wesentlichen Vorteil des MC: die Arbeit dynamisch verteilen zu können. Unter dem Strich kommt wieder heraus: ein Großteil des Rechenwerks schläft.
http://www.hipeac.net/system/files?file=carsten.pdf so ab Seite 11 sieht man was los ist.
oder halt CPU-Control 2.1 zum Thead-pinning nehmen. max. 4Cores
http://www.chip.de/downloads/CPU-Control_32204368.html
noch etwas dazu:
Nun sollen MC-CPUs dem Alltagsgeschäft und dem Spielspaß auf die Sprünge helfen. Bei den ersten Desktops mit zwei Prozessoren traten Dilemmas zu Tage: Den meisten Applikationen ist es schnurzegal, wie viel Prozessoren auf Arbeit warten, sie kennen und nutzen eh nur einen. Das verschärft sich bei der Integration in MC.
„Ja, wo laufen Sie denn?“ leitet das mehr oder weniger missliche Vergnügen ein, das beim Nutzen von Multi-core-Systemen aufkommen kann. Ohne zusätzliche Eingriffe von außen verteilen die Scheduler die anstehenden Prozesse nach eigenem Gutdünken. Zwar sind die aktuellen Betriebssysteme inzwischen darauf geeicht, die Wanderschaft zwischen den Kernen nicht ausufern zu lassen, doch wann und auf welchem Kern ein Prozess zum Zuge kommt und vor allem, wann er zum Ende kommt, ist nicht vorhersagbar. Es sei denn, Entwickler oder Anwender greifen zu Hilfsmitteln wie Affinities (Windows), taskset (Linux) oder pbind (Solaris), um nur einige zu nennen. Damit verspielt man aber einen wesentlichen Vorteil des MC: die Arbeit dynamisch verteilen zu können. Unter dem Strich kommt wieder heraus: ein Großteil des Rechenwerks schläft.
Zuletzt bearbeitet:
) für volle Last sorgt, einen dedizierten core in dieser Zeit erhielte (so eine Art kurzfristiges pinning), hätte man einerseits etwas mehr performance durch das Wegfallen des cache-refills und würde andererseits auch Energieeinsparungen spürbar erleichtern, da die cores einzeln gemanaged werden könnten, ohne dass das delay (für das Rauf-/Runtertakten während/nach einer Last; die Last muss ja schließlich erst mal erkannt werden) für deutlich schlechtere performance sorgt, da es weniger Lastwechsel gäbe, wodurch auch mehr Energie gespart werden könnte.
Hab ja die spannungen noch zu hoch für die einzelnen P-Stats 
