Windows thread vom Scheduling ausschließen

yaro schrieb:
> Wenn es
> möglich wäre, einen Kern explizit für diesen Thread zu reservieren, wäre
> das das Beste.

dann mach das doch. Gehe jeden Process durch und setze die Process 
Affinität so das eine CPU frei wird. Dann setzt du bei deinem Thread die 
Affinität so das diese CPU genutzt wird.

Er wird zwar weiterhin über das Scheduling laufen, aber andes geht es 
meines wissens nicht. Wenn du dazu noch die Prio auf höchste stufe 
setze, muss das doch reichen.

yaro schrieb:
> ist es möglich, in Windows einen thread vom Scheduling auszuschließen?

Das Scheduling ist doch dafür verantwortlich, dass mehrere Programme 
gleichzeitig laufen. Ich kann mir nicht vorstellen, dass man das einen 
Prozess bzw. Thread nur auf einen Kern laufen lassen kann.

yaro schrieb:
> Ich möchte ein zeitkritisches Programm laufen lassen, dass sehr schnell
> antworten können muss (in Kooperation mit einer Grafikkarte).

Was verstehst Du unter zeitkritisch? Wie viel ist zu berechnen?

Rufe SuspendThread auf und dein Thread wird nie wieder Rechenzeit vom 
Scheduler bekommen.

>Windows hat ein recht umfangreiches Prioritätskonzept. Ein Thread mit
>höchster Echtzeitpriorität muss sich also allenfalls mit einem
>ebensolchen Kollegen rumärgern.

Ja, windows hat dieses Konzept, aber als Benutzer (das schließt auch den 
Admin ein!) kann man einem Prozess keine "Echtzeit"-Prio verpassen, auch 
wenn die höchste Prio-Stufe, die man vergeben kann, so heißt!
Ein Prozess kann keine Prio höher 15 erreichen, bzw kann keine höhere 
prio manuell vergeben werden, da die höheren Prio-Stufen reserviert sind 
(system interrupts, etc!).
Sollte soweit auch klar sein. Wenn ein vom User gestarteter Prozess eine 
höhere Prio hat, als system prozesse, wie soll das system dann im 
zweifells falle reagieren, wenn es selbst ja keine cpu-zeit mehr 
bekommt, weil da so'n dummer user prozess die cpu blockiert?!

Selbst wenn die basis-prio sehr hoch ist, und das priorityboosting/aging 
zuschlägt, so kann diese gewisse magische grenze der Prio-stufen nicht 
überschritten werden! (sofern man nicht selber in den windows-kernel 
eingreift, und das dürfte eher schwer werden)

>dass sehr schnell antworten können muss
was heißt das? das was für uns menschen "sehr schnell" ist, das sind für 
eine moderne cpu äonen wo sie sich langweilt.
Einen prozess vom scheduling auszunehmen macht keinen sinn, da dem 
Prozess ja CPU-Zeit zugeteilt werden muss. Und ich bezweifel das du in 
der Lage bist die Zeit zu berechnen, die dein Prozess braucht.
Es ist möglich einen Prozesse auf einen einzelnen CPU-Kern "fest zu 
nageln", was aber lediglich bedeutet das der Prozess ausschließlich von 
diesem Kern ausgeführt wird, was aber nicht bedeutet das dieser cpu-kern 
nichts anderes macht! Das einzige was man hier dann an zeit sparen 
würde, wäre das die synchro mit threads, die sonst auf anderen kernen 
ausgeführt werden, entfällt. Ansonsten dürfte dieses vorgehen eher zu 
einer (im gesamten betrachtet) verlangsamung führen.

yaro schrieb:
> Ich möchte ein zeitkritisches Programm laufen lassen, dass sehr schnell
> antworten können muss

Dann wirst du wohl einen Kernel Mode Interrupt Service schreiben müssen. 
Von der User-Seite aus ist das was du möchtest mit gutem Grund 
ausgeschlossen.

Gruss Reinhard

Danke schonmal für die Antworten, auch wenn sie etwas demotivieren.

Es geht um Bildverarbeitung auf einer Grafikkarte mit CUDA. Zeitkritisch 
heißt bei mir, dass ich innerhalb von ca. 5µs reagieren muss, um einen 
Benefit zu ziehen.

Einige Verarbeitungen sind auf einem massiv parallelen Prozessor nicht 
optimal und sollten auf die große CPU ausgelagert werden. Das Schedulig 
zieht einem da ohne echtzeit Betriebssystem aber wohl einen Strich durch 
die Rechnung. Wenn der Thread erst eingewechselt werden muss, können 
Millisekunden vergehen, was viel zu viel ist. Da nehme ich lieber die 
unvorteilhafte Berechnung auf der Grafikkarte inkauf, bei der ich mir 
aber sicher sein kann, dass sie jedes mal in ähnlicher Zeit ausgeführt 
wird.

Ich werde es trotzdem mal mit höherer Prozesspriorität versuchen. Weiß 
jemand, ob man sie auuch aus dem Programm heraus ändern kann?

Gruß, Yaro

Danke schön, werde das mal probieren!

5µs sind immerhin ca. 10.000 Takte. Da die heutigen Prozessoren 
superlinear sind, können in jedem Takt mehrere Befehle in die Pipelines 
geschoben werden, sodass sich die Zahl vervielfacht.

Ich führe eine normierte Korrelation im umkreis von +-10 pixeln um eine 
Position durch. Bekomme also ein Bild mit 21*21 Pixeln raus, bei dem ich 
die Stelle mit dem höchsten Wert heraussuchen will. Eigentlich ist das 
eher was für die CPU und müsste in weniger als 1µs fertig sein.

Auch wenn die GPU eventuell schneller ist, kann ich mir bei den wenigen 
daten schon vorstellen das die Transferzeit in und von der GPU zu lange 
dauert.

In welcher Form kommen denn die Daten in den PC und wie erfolgt dann die 
ausgabe?

Noch kommen die Daten nicht in Echtzeit in den PC, soll aber irgendwann 
auch so laufen. Momentan sind sie im Arbeitsspeicher.
Die Daten befinden sich schon auf der GPU, wenn ich das 21*21 Bild habe. 
Ich korreliere zwei größere Bilder mit der GPU und dies ist das 
Ergebnis.

Auf der GPU können verschiedene Threads (abhängig davon, von welchem 
Prozessor sie ausgeführt werden) nur sehr schlecht kommunizieren, sodass 
man u.U. die Aufgabe mit insgesammt nur 32 von 448 Kernen lösen muss. Es 
ist wahrscheinlich immer noch sehr schnell, reizt die Geschwindigkeit 
aber eben nicht aus. Der Transport der Daten von der Grafikkarte auf den 
Arbeitsspeicher verläuft mit ca 8GBit/s per DMA, sodass sie in weniger 
als 1µs da sind.
Ich werde versuchen, für die GPU noch andere Arbeit zu finden, damit ich 
die CPU parallel nutze. Das wäre am effektivsten.

> Noch kommen die Daten nicht in Echtzeit in den PC

Definiere doch bitte erstmal "Echtzeit",...

Schonmal überlegt einen anderen Algorithmus zu nehmen, der vllt. 
schneller ist?! Vllt. mal in eine andere richtung denken und nicht 
zwingend auf dem Weg beharren, von dem Du meinst, das du ihn gehen 
musst?!
Und Wer setzt überhaupt die Grenzwerte, von denen du meinst das du sie 
einhalten musst?

Yaro schrieb:
> Der Transport der Daten von der Grafikkarte auf den
> Arbeitsspeicher verläuft mit ca 8GBit/s per DMA, sodass sie in weniger
> als 1µs da sind.

rechnerisch schon, aber es muss auch der Treiber und die Anwendung davon 
erfahren. Außerdem gibt es bei den paar Byte noch Overhead auf dem Bus.

Yaro schrieb:
> Ich werde versuchen, für die GPU noch andere Arbeit zu finden, damit ich
> die CPU parallel nutze. Das wäre am effektivsten.

Das ist schon eine etwas seltsame Art zu programmieren. Aber ich kann 
dich beruhigen: GPUs sind es durchaus gewohnt, die meiste Zeit 
arbeitslos zu sein.

Gruss Reinhard

Peter II schrieb:
> rechnerisch schon, aber es muss auch der Treiber und die Anwendung davon
> erfahren. Außerdem gibt es bei den paar Byte noch Overhead auf dem Bus.

Jop, da hast du völlig Recht. Hab mal eben gemessen, der gesammte 
Kopiervorgang dauert 4µs. Davon sind ca. 2µs das Anstoßen des 
Kopiervorgangs und 2µs das Kopieren selbst. Der throughput ist dabei nur 
ca. 800MB/s, weil es so wenig Daten sind (1723KB), sodass die volle 
Geschwindigkeit nicht ausgereizt werden kann.

Kaj schrieb:
> Definiere doch bitte erstmal "Echtzeit",...

Echtzeit bedeutet, dass jede 5ms ein neues Bild reinkommt.

Kaj schrieb:
> Schonmal überlegt einen anderen Algorithmus zu nehmen, der vllt.
> schneller ist?! Vllt. mal in eine andere richtung denken und nicht
> zwingend auf dem Weg beharren, von dem Du meinst, das du ihn gehen
> musst?!

Versuche ich ständig =)

Robert L. schrieb:
> auch wenn ich es (so) nicht 100% verstehe was du genau machst, aber es
> sollte doch recht einfach möglich sein, während man dieses "korreliere"
> macht,  sich den "hellsten" punkt zu merken...

Das ist echt gut! Es lässt sich zwar nicht zu 100% so einfach machen, 
aber ich kann das 21*21 Bild recht einfach auf ein 1*14 Bild bringen, 
mit dem ich dann weiterarbeite. Vielen Dank für die Idee.

Reinhard Kern schrieb:
> Yaro schrieb:
>> Ich werde versuchen, für die GPU noch andere Arbeit zu finden, damit ich
>> die CPU parallel nutze. Das wäre am effektivsten.
>
> Das ist schon eine etwas seltsame Art zu programmieren. Aber ich kann
> dich beruhigen: GPUs sind es durchaus gewohnt, die meiste Zeit
> arbeitslos zu sein.

Es ist so, dass die GPU diese Arbeit trotzdem irgendwann ausführen muss. 
Wenn ich die Lücke fülle, spare ich mir später Ausführungszeit.
Und mal ehrlich, findest du es nicht auch befridigender, wenn die 
Hardware sinnvoll arbeitet statt brach zu liegen?