Anzahl Threads?
-
Termite schrieb:
...oder über eine semaphore oder sonst was eine Task ( thread ) aufwecken der die berechnungen durchführen soll. danach legt sich der Thread wieder schlafen, bis zum nächsten aufwecken.
solch manuelles scheduling ist meistens keine tolle idee
-
ist die rechenlast so extrem dass ein thread mehr als 50ms braucht um V fuer einen wagen zu errechnen?
-
ne jungs, ist ein normaler P4 mit WinXX oder Win 2000.. es geht nicht unbedingt um die rechenlasst, es geht nur um den still...
Es ist also schon besser sowenig wie möglich an thread verwenden. ob ich jetzt in einem thread 10 berechnungen nacheinander aufrufe, oder 10 thead eine berechnung, kommst ja auf das selbe raus.. da die 10 trhead ja die berechnung nauch hintereinander ausführen. es geht darum das die berechnungn der auto ziemlich genau umd die gleiche zeit geschehen.. das ist mit echtzeit gemeint..
bei 10 threads müsste man sich evtl. noch darum kümmern das sie immer in der gleiche nreihenfolge gestartet und gestoppt werden
-
fricky schrieb:
Termite schrieb:
...oder über eine semaphore oder sonst was eine Task ( thread ) aufwecken der die berechnungen durchführen soll. danach legt sich der Thread wieder schlafen, bis zum nächsten aufwecken.
solch manuelles scheduling ist meistens keine tolle idee
wieso manuelles Scheduling. ich verwend ein os
hierbei handelt es sich nicht um scheduling sondern darum, die berechnungen nicht im irq machen zu müssen, da ein irq alle anderen eingehenden irqs blockieren könnte, was ggf zimlich böse sein kann. ein irq sollte so kurz wie möglich gehalten sein. ( genau so wie bei den handlern für gui events, die dann den gui update blockieren )
Da auf einem PC, würde ich für jede berechnung einen Thread anlegen. ( multicore, multithreading cpus )
-
So wie die Aufgabenstellung zunächst mal klingt scheint es so zu sein, dass sich die einzelnen Autos tatsächlich unabhängig voneinander berechnen lassen. Wenn Du jetzt die Möglichkeit zur Parallelisierung zumindest schaffen möchtest würde ich empfehlen nicht explizit Threads zu verwenden, sondern eher sowas wie OpenMP oder so. Alternativ sowas wie MCSTL. Dann kannst du nach Bedarf soviele Threads erzeugen wie nötig bzw. auf einem Rechner mit mehreren Cores auch wirklich alle Cores nutzen, sozusagen die Anwendung mit dem Rechner skalieren.
-
Ich denke mal das ist ähnlich wie mit Sockets und Threads.
ein Server wird in einem Workerthread mehrere Sockets bedienen aber mehrere dieser Threads haben.
d.H. mach für X Autos einen Thread bis du den ersten CPU Kern auslastest dann nehme einen weiteren Thread. Die Sache ist dann aber wenn du in einem Takt arbeitest müsste zwischen den Threads dieser "Takt" syncronisiert werden.
Aber nochmal spezifisch zu deinen Problem, 2 Hz Takt kannst du locker erreichen auch wenn du alle 10 Autos in einem Thread berechnest. Mann kann unter Windows circa einen Takt von 100 Hz ereichen der allerdings eine Abweichung von 36% hat. Die Abweichung kann man dann dadurch ausgleichen indem man in einem Takt mehrere Takte zusammenlegt ohne ein Sleep zu machen.
-
BorisDieKlinge schrieb:
Es ist also schon besser sowenig wie möglich an thread verwenden. ob ich jetzt in einem thread 10 berechnungen nacheinander aufrufe, oder 10 thead eine berechnung, kommst ja auf das selbe raus.. da die 10 trhead ja die berechnung nauch hintereinander ausführen.
Einfache Antwort: Falsch.
Lange Antwort: Wenn Du 10 Rechnungen in einem Thread ausführst hast due die 100%tige Kontrolle darüber in welcher Reihenfolge berrechnet wird. Wenn Du dagegen 10 Threads laufen läßt die jeweils 1 Auto berrechnen übergibst Du diese Kontrolle dem Task-Sheduler des Betriebssystems. Wann die einzelnen Threads wieviel Rechenzeit bekommen ist dabei im prinzip reiner Zufall. Vergiss nicht: Auf Deinem Rechenr laufen zu jeder Zeit ein paar 100 Threads die alle um Rechenzeit auf der einen CPU fighten... Du darfst Dir das nciht so vorstellen das der Thread erst die Berrechnung ausführt und dann der nächste Thread usw. MUltitasking bedeutet, daß zu jedem beliebigen Zeitpunkt der Thread vom Sheduler angehalten und die Kontrolle zu einem anderen Thread übergeben werdne kann. (->Preemtives Multitasking)
BorisDieKlinge schrieb:
es geht darum das die berechnungn der auto ziemlich genau umd die gleiche zeit geschehen.. das ist mit echtzeit gemeint..
Ok, da kommt der Klugscheisser hervor... Echtzeit im Bezug auf Threads ist ein feststehende Begriff. Lern was er bedeutet.
BorisDieKlinge schrieb:
bei 10 threads müsste man sich evtl. noch darum kümmern das sie immer in der gleiche nreihenfolge gestartet und gestoppt werden
Darauf hast Du keinen Einfluss. Einen Thread zu starten bedeutet nciht zwingend das er dann auch vom Sheduler ausgeführt wird. Es _kann_ es bedeuten, _muss_ es aber nicht.
-
loks schrieb:
Wann die einzelnen Threads wieviel Rechenzeit bekommen ist dabei im prinzip reiner Zufall.
Nicht wirklich. Wenn es reiner Zufall wäre, würdest du keinen PC bedienen können
Vergiss nicht: Auf Deinem Rechenr laufen zu jeder Zeit ein paar 100 Threads die alle um Rechenzeit auf der einen CPU fighten...
Nö, die meiste Zeit macht dein PC garnix, idlet nur rum und wartet, das mal ein Thread was tun will.
(Soll jetzt aber nicht heisen, dass das was Boris schreibt richtig ist.)
-
Termite schrieb:
fricky schrieb:
Termite schrieb:
...oder über eine semaphore oder sonst was eine Task ( thread ) aufwecken der die berechnungen durchführen soll. danach legt sich der Thread wieder schlafen, bis zum nächsten aufwecken.
solch manuelles scheduling ist meistens keine tolle idee
wieso manuelles Scheduling. ich verwend ein os
hierbei handelt es sich nicht um scheduling sondern darum, die berechnungen nicht im irq machen zu müssen, da ein irq alle anderen eingehenden irqs blockieren könnte, was ggf zimlich böse sein kann. ein irq sollte so kurz wie möglich gehalten sein.
ja, aber sowas macht man, wenn ein gerät aufwendige behandlung benötigt, die sonst die reaktion auf den nächsten interrupt unnötig verzögern könnte. siehe z.b. unter windoofs die sogenannten 'deferred procedure calls'. für das problem unseres OP ist dieses verfahren unnötig, weil sein sinn (auf interrupts in schneller folge reagieren können) hierbei keinen vorteil brächte.
ich würde dafür keine extra threads/tasks erzeugen. wahrscheinlich ist die komplette berechnung so schnell fertig, daß ein thread noch nicht mal eine ganze zeitscheibe benötigt.
-
bluuu schrieb:
loks schrieb:
Wann die einzelnen Threads wieviel Rechenzeit bekommen ist dabei im prinzip reiner Zufall.
Nicht wirklich. Wenn es reiner Zufall wäre, würdest du keinen PC bedienen können
Wann ein Thread wieviel Rechenzeit bekommt ist von vielen Faktoren abhängig mit dem Ergebnis, das Du praktisch nicht vorhersagen kannst welcher der wartenden Threads als nächster drankommt. In meinem Sprachgebrauch nenne ich das Zufall.
Die reine Tatsache, daß die Reihenfolge in der Threads abgearbeitet werden eher zufällig ist hat nichts damit zu tuen das der PC nicht bedienbar sei. Solange genug Rechenkapazität vorhanden ist kommen alle Threads früher oder später an die Reihe -> System bleibt bedienbar.
-
@BorisDieKlinge:
Was den "still" angeht (-> Stil): lass Threads mal Threads sein, und kümmer dich lieber darum dein Programm sauber zu designen. Solange du nicht aus irgend einem Grund auf mehrere Threads angewiesen bist fällt die Verwendung von mehreren Threads wohl unter "premature optimization" und ist daher schlechter Stil.
Wenn du dann irgendwann ein greifbares Performance Problem hast kannst du immer noch überlegen wie man die verschiedenen Teile am besten auf verschiedene CPUs verteilen kann.
-
kurz und knapp ich verwende ein Thread und berechne alle auto hintereinader in einbe best. intervall ab:)
-
Falls du 10 gleiche Autos bauen willst, ist Arbeitsteilung per Fließband (d.h. Vektorisierung) wahrscheinlich effizienter, als jeden Arbeiter ein einzelnes Auto in Gänze bauen zu lassen.
