Programm für automatische Prozessor Affinity setzten?

Mr. Zet

Vereinsmitglied
resident spacenerd

Registered: Oct 2000
Location: Edge of Tomorrow
Posts: 12067

03.11.2009 - 11:45

Es ist auch ein ziemlicher no-brainer, dass 4 Threads, jeder auf einem Core, deutlich schneller sind als wenn diese 4 Threads lustig über alle 4 Cores hüpfen.

Natürlich wäre es wünschenswert, wenn der Scheduler so etwas optimal löst. Aber woher soll der denn Wissen, ob es für einen arbeitsintensiven Thread besser wäre bei einer Unterbrechung zu warten oder auf einen anderen Core transferiert zu werden?

PIMP

Elder
Elder

Registered: Sep 2002
Location: Wien ❤️
Posts: 8924

03.11.2009 - 12:03

Das ut99 problem mit der verzögerung auf moderner hardware lässt sich btw nicht immer mit affinity lösen (xp/fista/7). Selbes spiel unter osx läuft 1a auf einem c2d (rosetta).

Mr. Zet

Vereinsmitglied
resident spacenerd

Registered: Oct 2000
Location: Edge of Tomorrow
Posts: 12067

03.11.2009 - 12:10

Hab ich doch eh geschrieben

Chrissicom

Rise of the Ryzen

Registered: Jul 2006
Location: Falkensee
Posts: 1942

03.11.2009 - 15:46

Zitat
Es ist auch ein ziemlicher no-brainer, dass 4 Threads, jeder auf einem Core, deutlich schneller sind als wenn diese 4 Threads lustig über alle 4 Cores hüpfen.

Das sehe ich anders. Es ist durchaus realistisch anzunehmen, dass es möglich ist 4 Threads die maximale Last auf einem Core verursachen und erst durch User Interaktion beendet werden zu erkennen. Wenn man nur einen einzigen dieser x264 Threads ohne MT ausführt, wechselt er die Cores auch (egal ob Linux oder Windows) und das ist einfach nicht nötig... wozu? Na ja, nächstes Semester höre ich Betriebssysteme, da werde ich dann tiefer in Scheduler einsteigen

COLOSSUS

Administrator
GNUltra

Registered: Dec 2000
Location: ~
Posts: 12174

03.11.2009 - 15:54

Das ist keineswegs immer so - CPUtime ist nicht die einzige Resource, die ein Scheduler im Auge behalten muss. Disk-IO ist z. B. eine Sache, auf NUMA-Systemen aber auch die Speicherlokalitaet (das kann der "vanilla" Linux-Scheduler z. B. noch nicht richtig, afaik).

Zu behaupten, es waere fuer die Anwendungsperformance grundsaetzlich besser, Affinitaet fuer einen Prozess auf einen Kern festzulegen, ist jedenfalls einfach falsch.

Ringding

Pilot

Registered: Jan 2002
Location: Perchtoldsdorf/W..
Posts: 4300

03.11.2009 - 15:56

Klar ist's langsamer, wenn ein Task zwischen Cores herumhüpft. Aber das passiert typischerweise vielleicht ein paar Mal pro Sekunde, und das ist wirklich nicht spürbar. Wenn es 20% Performance-Einbruch gibt, dann muss da irgendwas richtig im Argen sein.

stevke

in the bin

Registered: Sep 2001
Location: Wien
Posts: 3965

03.11.2009 - 16:04

Zitat von COLOSSUS
Zu behaupten, es waere fuer die Anwendungsperformance grundsaetzlich besser, Affinitaet fuer einen Prozess auf einen Kern festzulegen, ist jedenfalls einfach falsch.

Er hat ja auch nicht geschrieben das es grundsätzlich besser ist, sondern wenn er 4 x264 Videos gleichzeitig encoden will ist das manuelle setzen performanter.

Maekloev

linux addicted

Registered: Oct 2002
Location: Absam
Posts: 920

03.11.2009 - 16:22

ich sags mal so: threads sind verglichen zu prozessen sehr leicht-gewichtig. nicht umsonst werden sie auch so bezeichnet. d.h. im klartext: wenn es sich im beispiel oben mit den 4 threads um vier prozesse handeln würde, dann würde ich das problem noch einigermaßen nachvollziehen können. bei threads geht der context switch bedeutend schneller vonstatten, da viele strukturen nicht gesichert werden müssen, da sie ja ohnehin geshared werden. es macht also bei 4 cores keinen _wesentlichen_ unterschied, ob du jetzt einen prozess auf 4 threads oder auf 100 aufteilst. erst im (wesentlich) höherstelligen bereich wirds dann schon spürbar, dass der scheduler mehr mit dem verteilen von threads, als mit dem eigentlichen arbeiten aktiv ist. ein paar infos dazu gibts auf den angehängten vorlesungsfolien zu diesem thema (s. p. 40ff).

wie hast du die zeiten gemessen? 30% find ich dann schon etwas sehr viel.

prozesseiii_147612.pdf (downloaded 82x)

Ringding

Pilot

Registered: Jan 2002
Location: Perchtoldsdorf/W..
Posts: 4300

03.11.2009 - 19:18

Ich möchte das zwar jetzt nicht mit Sicherheit behaupten, aber ich glaube zu wissen, dass die Zeit für einen Context-Switch zumindest bei x86/x86_64 bei einem Prozess-Switch nicht wesentlich höher ist als bei einem Thread-Switch. Aber darum geht’s auch überhaupt nicht. Die paar Context Switches, die bei langlaufenden CPU-intensiven Prozessen passieren – höchstens ein paar hundert pro Sekunde, typischerweise weit weniger – machen das Kraut nicht wirklich fett.

Chrissicom

Rise of the Ryzen

Registered: Jul 2006
Location: Falkensee
Posts: 1942

03.11.2009 - 21:51

@Maekloev

Ok, wenn man es genau nimmt, dann sind es 4 x264 Prozesse und diese Prozesse starten logischerweise Threads. Es ist nicht ein x264 Prozess, der 4 Threads startet, falls meine Aussage so aufgefasst wurde. Das sollte in der Tat deutlich effizienter sein!

Ich überlege mir grad wie man das vergleichen könnte. 1* 1 Stunde WVC-1 nach H.264 encoden mit 1 Prozess in 4 Threads (x264 ist ja an sich MT fähig) und dann die gleiche 1 Stunde in 4* 15 Minuten WVC-1 splitten und nach H.264 encoden und dann mit 4 Prozessen die je 1 Thread starten arbeiten. Mal schauen ob es da einen Unterschied gibt, werd ich aber erst nächste Woche machen. Im Moment muss ich paar Datenbank Benchmarks unter Ubuntu für die Uni machen

Zitat
wie hast du die zeiten gemessen? 30% find ich dann schon etwas sehr viel.

Ich hab keine genauen Daten notiert, da ich es nicht als Benchmark ausgeführt hab. Ich hab einfach getestet auf welche Weise ich am schnellsten viele WVC-1 Videos nach H.264 konvertieren/encoden kann und mir die verstrichene Zeit angeschaut. Ich gebe zu das es durch unterschiedliches Input Material zu Abweichungen kommen kann, dass die so groß sind kann ich mir aber nicht vorstellen. Wie gesagt ich schau es mir nochmal genauer an.

Bearbeitet von Chrissicom am 03.11.2009, 21:55

johnny1981

Little Overclocker

Registered: Apr 2008
Location: europe
Posts: 63

12.11.2009 - 16:31

Hier ist eine recht interessante Maske der process Affinity, die ich von einem multiboxing guide kopiert habe.

╔══════╦════════╤════════╤════════╤════════╗

║ Mask ║ Core 1 │ Core 2 │ Core 3 │ Core 4 ║

╠══════╬════════╪════════╪════════╪════════╣

║ 1 ║ ██ │ ░░ │ ░░ │ ░░ ║

╟──────╫────────┼────────┼────────┼────────╢

║ 2 ║ ░░ │ ██ │ ░░ │ ░░ ║

╟──────╫────────┼────────┼────────┼────────╢

║ 3 ║ ██ │ ██ │ ░░ │ ░░ ║

╟──────╫────────┼────────┼────────┼────────╢

║ 4 ║ ░░ │ ░░ │ ██ │ ░░ ║

╟──────╫────────┼────────┼────────┼────────╢

║ 5 ║ ██ │ ░░ │ ██ │ ░░ ║

╟──────╫────────┼────────┼────────┼────────╢

║ 6 ║ ░░ │ ██ │ ██ │ ░░ ║

╟──────╫────────┼────────┼────────┼────────╢

║ 7 ║ ██ │ ██ │ ██ │ ░░ ║

╟──────╫────────┼────────┼────────┼────────╢

║ 8 ║ ░░ │ ░░ │ ░░ │ ██ ║

╟──────╫────────┼────────┼────────┼────────╢

║ 9 ║ ██ │ ░░ │ ░░ │ ██ ║

╟──────╫────────┼────────┼────────┼────────╢

║ 10 ║ ░░ │ ██ │ ░░ │ ██ ║

╟──────╫────────┼────────┼────────┼────────╢

║ 11 ║ ██ │ ██ │ ░░ │ ██ ║

╟──────╫────────┼────────┼────────┼────────╢

║ 12 ║ ░░ │ ░░ │ ██ │ ██ ║

╟──────╫────────┼────────┼────────┼────────╢

║ 13 ║ ██ │ ░░ │ ██ │ ██ ║

╟──────╫────────┼────────┼────────┼────────╢

║ 14 ║ ░░ │ ██ │ ██ │ ██ ║

╟──────╫────────┼────────┼────────┼────────╢

║ 15 ║ ██ │ ██ │ ██ │ ██ ║

╚══════╩════════╧════════╧════════╧════════╝

Ringding

Pilot

Registered: Jan 2002
Location: Perchtoldsdorf/W..
Posts: 4300

12.11.2009 - 20:02

Ah, hier hat jemand das Binärsystem entdeckt…

Mr. Zet

Vereinsmitglied
resident spacenerd

Registered: Oct 2000
Location: Edge of Tomorrow
Posts: 12067

12.11.2009 - 20:23

Zitat von Ringding
Ah, hier hat jemand das Binärsystem entdeckt…

Made my Day!

johnny1981

Little Overclocker

Registered: Apr 2008
Location: europe
Posts: 63

12.11.2009 - 23:59

hättest ja vorher hinweisen können, wie sich die nummer der process affinity ergibt.

ich helf dagegen wenigstens.

sk/\r

i never asked for this

Registered: Dec 2002
Location: oö
Posts: 11145

13.11.2009 - 00:55

Zitat von Mr. Zet
Aha, wusste nicht, dass das auch vom Prozessor so stark beeinflusst wird. Ich kann nur sagen, dass es mit Athlon 64 X2 (3800+) weder mit WinXP, noch mit Win7 geht.

Es hängt fest, rennt im Anschluss super schnell, quasi Zeitraffer, bis wieder der Punkt erreicht wurde, wo man eigentlich gerade sein sollte, und das ganze wiederholt sich sogleich von vorne.

Auf einen Core beschränken und es geht problemlos (meistens jedenfalls)...

1) leider erst jetzt gelesen.

nein. auf einen core beschränken hat bei mir nicht geholfen und ja es lief auch auf meinem a64 schon zu schnell.

2) problemlösung: click here <= angefügte opengl datei ins system verzeichniss von ut, to (jedes game dass halt die erste ue nutzt) kopieren. wurde von fans geschrieben iirc.
jeweiliges spiel mit opengl starten.
tab (console) => preferences => rendering => opengl => frame limit auf zB 100 setzen. dann gibts weder zeitraffer noch zeitlupen momente.
nachdem ich selbst noch immer begeisterter ut und to zocker bin, weiß ich wovon ich hier spreche. hth

Mr. Zet Vereinsmitglied resident spacenerd Registered: Oct 2000 Location: Edge of Tomorrow Posts: 12067	03.11.2009 - 11:45 Es ist auch ein ziemlicher no-brainer, dass 4 Threads, jeder auf einem Core, deutlich schneller sind als wenn diese 4 Threads lustig über alle 4 Cores hüpfen. Natürlich wäre es wünschenswert, wenn der Scheduler so etwas optimal löst. Aber woher soll der denn Wissen, ob es für einen arbeitsintensiven Thread besser wäre bei einer Unterbrechung zu warten oder auf einen anderen Core transferiert zu werden?
PIMP Elder Elder Registered: Sep 2002 Location: Wien ❤️ Posts: 8924	03.11.2009 - 12:03 Das ut99 problem mit der verzögerung auf moderner hardware lässt sich btw nicht immer mit affinity lösen (xp/fista/7). Selbes spiel unter osx läuft 1a auf einem c2d (rosetta).
Mr. Zet Vereinsmitglied resident spacenerd Registered: Oct 2000 Location: Edge of Tomorrow Posts: 12067	03.11.2009 - 12:10 Hab ich doch eh geschrieben
Chrissicom Rise of the Ryzen Registered: Jul 2006 Location: Falkensee Posts: 1942	03.11.2009 - 15:46 Zitat Es ist auch ein ziemlicher no-brainer, dass 4 Threads, jeder auf einem Core, deutlich schneller sind als wenn diese 4 Threads lustig über alle 4 Cores hüpfen. Das sehe ich anders. Es ist durchaus realistisch anzunehmen, dass es möglich ist 4 Threads die maximale Last auf einem Core verursachen und erst durch User Interaktion beendet werden zu erkennen. Wenn man nur einen einzigen dieser x264 Threads ohne MT ausführt, wechselt er die Cores auch (egal ob Linux oder Windows) und das ist einfach nicht nötig... wozu? Na ja, nächstes Semester höre ich Betriebssysteme, da werde ich dann tiefer in Scheduler einsteigen
COLOSSUS Administrator GNUltra Registered: Dec 2000 Location: ~ Posts: 12174	03.11.2009 - 15:54 Das ist keineswegs immer so - CPUtime ist nicht die einzige Resource, die ein Scheduler im Auge behalten muss. Disk-IO ist z. B. eine Sache, auf NUMA-Systemen aber auch die Speicherlokalitaet (das kann der "vanilla" Linux-Scheduler z. B. noch nicht richtig, afaik). Zu behaupten, es waere fuer die Anwendungsperformance grundsaetzlich besser, Affinitaet fuer einen Prozess auf einen Kern festzulegen, ist jedenfalls einfach falsch.
Ringding Pilot Registered: Jan 2002 Location: Perchtoldsdorf/W.. Posts: 4300	03.11.2009 - 15:56 Klar ist's langsamer, wenn ein Task zwischen Cores herumhüpft. Aber das passiert typischerweise vielleicht ein paar Mal pro Sekunde, und das ist wirklich nicht spürbar. Wenn es 20% Performance-Einbruch gibt, dann muss da irgendwas richtig im Argen sein.
stevke in the bin Registered: Sep 2001 Location: Wien Posts: 3965	03.11.2009 - 16:04 Zitat von COLOSSUS Zu behaupten, es waere fuer die Anwendungsperformance grundsaetzlich besser, Affinitaet fuer einen Prozess auf einen Kern festzulegen, ist jedenfalls einfach falsch. Er hat ja auch nicht geschrieben das es grundsätzlich besser ist, sondern wenn er 4 x264 Videos gleichzeitig encoden will ist das manuelle setzen performanter.
Maekloev linux addicted Registered: Oct 2002 Location: Absam Posts: 920	03.11.2009 - 16:22 ich sags mal so: threads sind verglichen zu prozessen sehr leicht-gewichtig. nicht umsonst werden sie auch so bezeichnet. d.h. im klartext: wenn es sich im beispiel oben mit den 4 threads um vier prozesse handeln würde, dann würde ich das problem noch einigermaßen nachvollziehen können. bei threads geht der context switch bedeutend schneller vonstatten, da viele strukturen nicht gesichert werden müssen, da sie ja ohnehin geshared werden. es macht also bei 4 cores keinen _wesentlichen_ unterschied, ob du jetzt einen prozess auf 4 threads oder auf 100 aufteilst. erst im (wesentlich) höherstelligen bereich wirds dann schon spürbar, dass der scheduler mehr mit dem verteilen von threads, als mit dem eigentlichen arbeiten aktiv ist. ein paar infos dazu gibts auf den angehängten vorlesungsfolien zu diesem thema (s. p. 40ff). wie hast du die zeiten gemessen? 30% find ich dann schon etwas sehr viel. prozesseiii_147612.pdf (downloaded 82x)
Ringding Pilot Registered: Jan 2002 Location: Perchtoldsdorf/W.. Posts: 4300	03.11.2009 - 19:18 Ich möchte das zwar jetzt nicht mit Sicherheit behaupten, aber ich glaube zu wissen, dass die Zeit für einen Context-Switch zumindest bei x86/x86_64 bei einem Prozess-Switch nicht wesentlich höher ist als bei einem Thread-Switch. Aber darum geht’s auch überhaupt nicht. Die paar Context Switches, die bei langlaufenden CPU-intensiven Prozessen passieren – höchstens ein paar hundert pro Sekunde, typischerweise weit weniger – machen das Kraut nicht wirklich fett.
Chrissicom Rise of the Ryzen Registered: Jul 2006 Location: Falkensee Posts: 1942	03.11.2009 - 21:51 @Maekloev Ok, wenn man es genau nimmt, dann sind es 4 x264 Prozesse und diese Prozesse starten logischerweise Threads. Es ist nicht ein x264 Prozess, der 4 Threads startet, falls meine Aussage so aufgefasst wurde. Das sollte in der Tat deutlich effizienter sein! Ich überlege mir grad wie man das vergleichen könnte. 1* 1 Stunde WVC-1 nach H.264 encoden mit 1 Prozess in 4 Threads (x264 ist ja an sich MT fähig) und dann die gleiche 1 Stunde in 4* 15 Minuten WVC-1 splitten und nach H.264 encoden und dann mit 4 Prozessen die je 1 Thread starten arbeiten. Mal schauen ob es da einen Unterschied gibt, werd ich aber erst nächste Woche machen. Im Moment muss ich paar Datenbank Benchmarks unter Ubuntu für die Uni machen Zitat wie hast du die zeiten gemessen? 30% find ich dann schon etwas sehr viel. Ich hab keine genauen Daten notiert, da ich es nicht als Benchmark ausgeführt hab. Ich hab einfach getestet auf welche Weise ich am schnellsten viele WVC-1 Videos nach H.264 konvertieren/encoden kann und mir die verstrichene Zeit angeschaut. Ich gebe zu das es durch unterschiedliches Input Material zu Abweichungen kommen kann, dass die so groß sind kann ich mir aber nicht vorstellen. Wie gesagt ich schau es mir nochmal genauer an. Bearbeitet von Chrissicom am 03.11.2009, 21:55
johnny1981 Little Overclocker Registered: Apr 2008 Location: europe Posts: 63	12.11.2009 - 16:31 Hier ist eine recht interessante Maske der process Affinity, die ich von einem multiboxing guide kopiert habe. ╔══════╦════════╤════════╤════════╤════════╗ ║ Mask ║ Core 1 │ Core 2 │ Core 3 │ Core 4 ║ ╠══════╬════════╪════════╪════════╪════════╣ ║ 1 ║ ██ │ ░░ │ ░░ │ ░░ ║ ╟──────╫────────┼────────┼────────┼────────╢ ║ 2 ║ ░░ │ ██ │ ░░ │ ░░ ║ ╟──────╫────────┼────────┼────────┼────────╢ ║ 3 ║ ██ │ ██ │ ░░ │ ░░ ║ ╟──────╫────────┼────────┼────────┼────────╢ ║ 4 ║ ░░ │ ░░ │ ██ │ ░░ ║ ╟──────╫────────┼────────┼────────┼────────╢ ║ 5 ║ ██ │ ░░ │ ██ │ ░░ ║ ╟──────╫────────┼────────┼────────┼────────╢ ║ 6 ║ ░░ │ ██ │ ██ │ ░░ ║ ╟──────╫────────┼────────┼────────┼────────╢ ║ 7 ║ ██ │ ██ │ ██ │ ░░ ║ ╟──────╫────────┼────────┼────────┼────────╢ ║ 8 ║ ░░ │ ░░ │ ░░ │ ██ ║ ╟──────╫────────┼────────┼────────┼────────╢ ║ 9 ║ ██ │ ░░ │ ░░ │ ██ ║ ╟──────╫────────┼────────┼────────┼────────╢ ║ 10 ║ ░░ │ ██ │ ░░ │ ██ ║ ╟──────╫────────┼────────┼────────┼────────╢ ║ 11 ║ ██ │ ██ │ ░░ │ ██ ║ ╟──────╫────────┼────────┼────────┼────────╢ ║ 12 ║ ░░ │ ░░ │ ██ │ ██ ║ ╟──────╫────────┼────────┼────────┼────────╢ ║ 13 ║ ██ │ ░░ │ ██ │ ██ ║ ╟──────╫────────┼────────┼────────┼────────╢ ║ 14 ║ ░░ │ ██ │ ██ │ ██ ║ ╟──────╫────────┼────────┼────────┼────────╢ ║ 15 ║ ██ │ ██ │ ██ │ ██ ║ ╚══════╩════════╧════════╧════════╧════════╝
Ringding Pilot Registered: Jan 2002 Location: Perchtoldsdorf/W.. Posts: 4300	12.11.2009 - 20:02 Ah, hier hat jemand das Binärsystem entdeckt…
Mr. Zet Vereinsmitglied resident spacenerd Registered: Oct 2000 Location: Edge of Tomorrow Posts: 12067	12.11.2009 - 20:23 Zitat von Ringding Ah, hier hat jemand das Binärsystem entdeckt… Made my Day!
johnny1981 Little Overclocker Registered: Apr 2008 Location: europe Posts: 63	12.11.2009 - 23:59 hättest ja vorher hinweisen können, wie sich die nummer der process affinity ergibt. ich helf dagegen wenigstens.
sk/\r i never asked for this Registered: Dec 2002 Location: oö Posts: 11145	13.11.2009 - 00:55 Zitat von Mr. Zet Aha, wusste nicht, dass das auch vom Prozessor so stark beeinflusst wird. Ich kann nur sagen, dass es mit Athlon 64 X2 (3800+) weder mit WinXP, noch mit Win7 geht. Es hängt fest, rennt im Anschluss super schnell, quasi Zeitraffer, bis wieder der Punkt erreicht wurde, wo man eigentlich gerade sein sollte, und das ganze wiederholt sich sogleich von vorne. Auf einen Core beschränken und es geht problemlos (meistens jedenfalls)... 1) leider erst jetzt gelesen. nein. auf einen core beschränken hat bei mir nicht geholfen und ja es lief auch auf meinem a64 schon zu schnell. 2) problemlösung: click here <= angefügte opengl datei ins system verzeichniss von ut, to (jedes game dass halt die erste ue nutzt) kopieren. wurde von fans geschrieben iirc. jeweiliges spiel mit opengl starten. tab (console) => preferences => rendering => opengl => frame limit auf zB 100 setzen. dann gibts weder zeitraffer noch zeitlupen momente. nachdem ich selbst noch immer begeisterter ut und to zocker bin, weiß ich wovon ich hier spreche. hth

Programm für automatische Prozessor Affinity setzten?

Forum Index > Software > Windows

Mr. Zet

PIMP

Mr. Zet

Chrissicom

COLOSSUS

Ringding

stevke

Maekloev

Ringding

Chrissicom

johnny1981

Ringding

Mr. Zet

johnny1981

sk/\r