HI Leute,
ich hab ma ne Frage:

Es geht um meinen Raytracer, da heute ja eigentlich fast jeder Rechner einen mehr-kernigen Prozessor eingebaut hat, wollte ich alles auf Threads auslagern, wieviele Threads sollten denn da maximal gleichzeitig Laufen?

cuz
bubble

_________________
Wenn Worte nichts als Worte sind,
dann müssen's Steine sein!
Solange - bis sie pleite sind - schmeißt Fensterscheiben ein!
- Fidl Kunterbunt -

Wenn alle Threads die gleiche Aufgabe erfüllen macht ein Thread pro Core/CPU Sinn. Der Overhead beim Umschalten der Threads ist dank Hyperthreading (*) heutzutage ziemlich gering. Wenn sich Phasen von großen Speicherzugriffen mit Phasen aufwendiger Berechnungen abwechseln könnten zwei Threads pro Kern Sinn machen. So kann die Zeit für den Speicherzugriff sinnvoll genutzt werden. Das kommt auf den Fall an und hängt sicher auch von der CPU (**) ab => also ausprobieren.

Mehr Threads machen nur dann Sinn, wenn die Threads hin und wieder auf langsame Geräte (z.B. Festplatte) warten müssen. Wenn es um Hintergrundtätigkeiten (z.B. streamen von Musik) geht sind viele Threads kein Problem.

Was ist jedem Fall ganz schlecht ist: Threads sollten wenn irgendwie möglich unabhängig arbeiten. Wenn sie aufeinander warten müssen bringt das ganze gar nichts...

(*) Beim Hyperthreading sind alle Register und der Stack im Core doppelt ausgelegt. Jeder Core kann also jeweils mit nur einem einzigen Bit-Switch zwischen zwei Threads (oder Prozessen) umschalten.

(**) z.B. Speichermanager innerhalb der CPU oder auf dem Mainboard

_________________
Yeah!

Coolcat. Ich bin mir nicht sicher ob du nicht auch genau das meinst. Allerdings klingt das ein wenig verwirrend auf mich. Deswegen versuch ich das mal etwas anders.

Hyperthreading ist eine Technologie von Intel die es ermöglicht die Leistung eines Kerns besser nutzen zu können. Das hat nicht viel mit dem Overhead von Softwarethreads zu tun. Durch Hyperthreading ist ein Kern in der Lage 2 Hardwarethreads "gleichzeitig" ausführen zu können. In Wirklichkeit schaltet der Kern jedes mal dann auf einen anderen Thread, wenn der aktuelle gerade auf den Speicherkontroller oder was auch immer warten muss. Dadurch werden nur Wartenzeiten vermieden. Und das bei sehr geringem Platzaufwand auf dem DIE. Was es aber bringt hängt vom jeweiligen Anwendungsfall ab. Im schlimmsten Fall ist ein DualCore + Hyperthreading nicht schneller als ein einfacher DualCore.

Ich will da nur den Unterschied zwischen SoftwareThread und HardwareThread klar getrennt sehen. Auf einer CPU ohne Hyperthreading bringen zusätliche SoftwareThreads nämlich keine Vorteile. Wenn die CPU warten muss, dann tut sie das. Ob es einem gefällt oder nicht.

Ansonsten stimme ich deiner Aussage voll zu. Bei rechenintensiven Anwendungen 1 Thread pro Kern. Wenn man auf Hardware waren muss, dann dürfen es auch mehr sein. Wobei bei der Festplatte würde ich sogar sagen generell nur 1 Thread. Wenn du 2 Threads hast die beide auf der gleichen Platte etwas lesen, dann muss die Platte immer hin und her springen was das Einlesen sogar ausbremmst anstelle es zu beschleunigen.

Prinzipiell bekommt man keine Software Threads mehr angeboten, sobald man windows.h und dessen api CreateThread, CreateThreadEx bzw. pthread(windows oder mac/linux/unix) nutzt bekommt man ein Hardware Thread vor gesetzt, welcher von der Kernel auf die Anzahl der Kernel möglichst effizient aufgeteilt wird. Ist nur ein einzelner Kern vorhanden, dann gibt es ein Hardware Thread, welcher halt auf einem einzigen Kern switchen muss(hier wird es überhaupt erst kritisch). Wärend man unter windows sehr wohl auf seine Threads gucken, muss, da der Switch recht lange dauert(kann noch auf 1ms gepimpt werden) braucht man sich unter linux/unix/mac keine sorgen machen, die thread switches sind im micro bis nanosekunden bereich, je nach CPU, Programmcode und compiler flags. Wichtig ist nur bei Linux/Unix, dass du etwas über Kernel 2.4 hast, da wurden die Threads von RedHat offiziell gepatched. MacOS basiert auf Unix und hat daher gleiche Fähigkeiten.
Im Prinzip kannst du Thread nutzen wie du lustig bist, solange du die Anzahl der Switches klein hälst. Hier ist aber zu sagen, das bei 32k Thread schluss ist, wenn du die Default Compiler Settings nutzt, denn dann sind die 32Bit Adressraum zu, bei 64Bit kannst du mehrere Millionen erstellen, bis der Addressraum zu ist(man braucht natürlich auch den Speicher). Ein Thread der durch ein blockierenden Befehl in warteposition geparkt wird wartet und fällt niemandnen zu lasten. Erst wenn DMA der Kernel sagt, fertig, dann gibt die Kernel ein Signal/Message an den Thread und macht ihn wach.
Sleep ist mit Vorsicht zu geniessen, es kann sinnvoller sein den Thread zu töten und bei bedarf ein neuen zu erstellen als ihn alle Naselang wieder aus sein Schlaf zu holen(Threadswitch und bei Windows default mit 16,2ms minimal Schlafzeit). Threads machen auch nicht überall sinn und können oft durch Thread-Pools wesentlich besser agieren. Thread-Pools sind dann je nach implementierung eigentlich nur ein Thread der dann nach aussen wie mehrere wirkt aber per Software auf ein Hardware Thread läuft oder wirklich mehrer Hardware Threads(die guten). Du musst dich bei der Thematik leider in die API lesen, die du für deine Programmiersprache und Bibliothek nutzt, da es einige unterschiede gibt. Das Platformübergreifende sowie Performanteste ist pthread aber nicht leicht zu verwenden. Es gibt auch noch OpenMP, welches von MS VS und gcc supported wird aber das ist noch ne ecke häftiger als pthreads, da hier quasi micro optimization statt findet.
Threads machen in erster linie nur auf blockierende Befehle sinn und wenn dann noch kerne frei sind, packt man die größte aufgabe in einzelne threads, da kleine Aufgaben nicht so effizient sind. Netzwerk, IO(HDD,DVD), Konsolenausgabe, Grafik und Sound sind empfehlenswerte Opfer für Threads und wenn noch einzelne Kerne frei sind oder Luft haben, dann packt man Physik, Ki halt noch in threads.
In einigen Fällen kommt es auf reaktionszeit an, wie z.B. Netzwerk, daher macht es Sinn, neben den Sockets im Thread zu packen noch die logische verarbeitung und data crunching in Thread zu packen, damit man möglichst geringe pings hin bekommt. Es macht wenig Spaß, wenn man ne Latenz von 45ms zum Server hat aber ein Ping von 220ms und höher, weil der Server aufgrund des nicht parallel laufenden number crunching ewig braucht um eine Antwort zu schicken.
Ein Thread verbraucht zwischen 4-32Kb an Speicher, je nach Compiler und OS da braucht man sich also keine sorgen machen und wenn das einem immer noch zu viel ist(z.B. bei Netzwerk), dann kann man beim Compiler die stackgröße kleiner einstellen.
Also kurz und knapp nutzt für jedes blockierende device mindestens ein thread und guck wie du verarbeitungsprozesse noch auf threads auslagserst um die Wartezeiten, zwischen den threads, möglichst gering zu halten. Man kann nicht zuviele Threads haben, nur zu wenige und zu schlecht konzipierte(das sind die eigentlichen übeltäter).

Schau dir Thread-Pools mal an, dabei baut man seine Datenstruktur so auf, dass sie parallel von mehreren Threads verarbeitet werden kann ohne aufeinander warten zu müssen. Ganz bekannt ist hier Physik, wo man ja üblicherweise im ersten durchlauf alle Objekte auf ihre neue Position positioniert. Sind alle fertig werden schnittpunkte ausfindig gemacht. Im nächsten Schritt werden die Objekte aufgrund ihrer Kollisionen korrigiert, was alles in Etappen passiert, aufgrund der zwischenzeitlichen abhängigkeiten aber halt Parallel. Bei einem Thread-Pool wird die Anzahl an CPU-Kernen mit übergeben bzw. es werden n(CPU-Kerne) Threads in den Pool erstellt. Der Pool führt dann alles Threads aus und wenn einer schneller fertig ist als ein anderer gibt der Pool den Thread den nächsten job und lässt ihn garnicht erst pausieren, bis alle Jobs getan sind, dann halten alle Threads an und die Etappe ist geschafft, nun kann die nächste beginnne, indem wieder Jobs rein gefüllt werden(z.B. nach der neu positionierung aller Objekte, die erkennung der Kollisionen von allen Objekten). Festplatten können seit Uhrzeiten DMA, selten wird das benutzt(die api für windows und linux hat es echt in sich) und man greift zum einfachen blocking mode. Dieser blockiert aber und man will in der Regel nicht darauf warten, bis eine Datei fertig im Speicher liegt, um die nächste zu laden. Das ist die schlechteste Möglichkeit um Datein zu laden. Um dies zu verbessern kann man Threads nutzen.
Hierbei nutzt man gerne Thread-Pools, gleiches schema wie oben, man fügt dann einfach mehrere Datein rein und per signal/callback/event/messagehandler bekommt man beshceit, wenn der Background Loader die Datei hat. Dies ist ein wesentlicher unterschied, denn die Festplatte bekommt nun mehrere Datein und er kann schon die Jobs erledigen, die sowieso auf dem Weg zu dem Ursprünglich ersten Job liegen(ja meine Herren, Festplatten und OS sind nicht Dumm!!!). Dies kann mehrere MB/s an Geschwindigkeit hinzubringen.

_________________
"Wer die Freiheit aufgibt um Sicherheit zu gewinnen, der wird am Ende beides verlieren"
Benjamin Franklin

Projekte: https://github.com/tak2004

32.000+ Threads, Netzwerk, HDD, Physik. Du hast scheinbar überlesen (oder ignoriert), dass thebubble NUR seinen Raytracer parallelisieren will.

Und um das Klar zu stellen. Mit Software-Thread meine ich die Threads die vom Betriebssystem verwaltet werden und mit Hardware-Threads die Threads die von der CPU selbst verwaltet werden. Auf die Hardwarethreads hat man keinen Einfluss und die zeigen sich im Betriebssystem als eigenständige CPUs.

Nein hab ich nicht überlesen und nicht ignoriert, es ist alles drin was drin sein sollte. Ressourcenverbrauch, Maxima, wann setzt man Threads ein, welche Threads gibt es, Arbeitsdauer eines Thread und dessen Einfluss und im 2. Teil bin ich auf Threadpools eingegangen.
Falls es nicht deutlich genug war, ideal ist ein Threadpool mit Kernanzahl*2 Threads, die größere berechnungs Jobs entgegen nehmen und für das laden der Meshdaten,Materialien und so weiter. Timing und sync sind das a und o und bringen den Geschwindigkeitsvorteil.

Ich hab in der Schule gelernt, dass Hardwarethreads die Kernel Threads sind, Softwarethreads die alten lustigen bibliotheken die parallelisierung vorgegaugelt haben, in dem sie per windowing und ähnliche verfahren das switchen von jobs in der Hochsprache machen aber halt nur auf einem Kern.

_________________
"Wer die Freiheit aufgibt um Sicherheit zu gewinnen, der wird am Ende beides verlieren"
Benjamin Franklin

Projekte: https://github.com/tak2004

Ach das wolltest du damit sagen? Das habe ich, anhand der Fülle an unterschiedlichsten Informationen die du in deinem Beitrag zusammen getragen hast, nicht herauslesen können. Ich denke diejenigen die bisher wenig/weniger mit Threads zu tun gehabt haben dürftest du bereits mit den ersten zwei Absätzen sehr deutlich in die Schranken verwiesen haben.

Sync: Natürlich. Die beste Syncronisierung ist die auf die man verzichten kann.

Festplatte: Dazu habe ich oben schon mal was geschrieben. Welche Struktur man auch immer benutzt man sollte versuchen gleichzeitiges Lesen durch 2 Threads zu vermeiden. Wobei sich diese Frage wohl eh nicht stellt, da ich davon ausgehe, dass bei einem Raytracer zu Begin schon die Daten geladen sind. Und wenn man nicht vor hat so etwas wie Crysis zu rendern, dann dürfte die Fülle an Daten auch eher übersichtlich sein. Wodurch normalsterbliche auf Threads in dem Fall eh auch verzichten können.

Keine Ahnung wo du das her hast aber in der Praxis hab ich mehr Festplattendurchsatz, wenn ich ThreadPool nutze um mehrere Datein parallel zu laden. Hab auch geschrieben wieso, Datein die auf dem Weg liegen werden gleich mit ausgelesen. Wobei das in der Produktivumgebung wieder anders ist, da man ja üblicherweise alles in bis zu 1GB große Archivdatein packt und somit Festplatten Caching und optimale Leseraten bekommt und sich das wieder ausgleicht. Wenn man nicht gerade Java oder C# nutzt ist Thread programmierung auch nicht gerade unkompliziert. Allerdings stimme ich dir zu, dass es übertrieben ist, in dem Bereich zu optimieren.

_________________
"Wer die Freiheit aufgibt um Sicherheit zu gewinnen, der wird am Ende beides verlieren"
Benjamin Franklin

Projekte: https://github.com/tak2004

Das hatte ich selber schon mal festgestellt. Einlesen von recht großen Logdaten. Das Parsen hat kaum Zeit in Anspruch genommen. Single Core mit Hyperthreading. Zu erst war es so, dass die Threads alle selber gelesen haben. Was dazu geführt hat, dass sich das Programm in einen Benchmark für Spur zu Spurzugriffe verwandelt hat. Als dann nur das Parsen der Logdaten im Thread geschah lief die Platte nicht nur ruhiger sondern auch insgesammt schneller. Die Dateien waren auch recht groß. Ich denke, wenn man so was wie Texturen (500kb) oder Modelle (auch nicht viel größer) einlesen will, dann wird sich das nicht so stark äußern. Und es muss auch deutlich mehr mit den Daten gemacht werden. Was wieder dazu führt, dass die Platte nicht dauerhaft beschäftigt ist. Bei kleineren Dateien und mehr zusätzliche Arbeit kann es beschleunigend wirken. Wenn aber mehr auf der Platte gemacht wird ist es aber definitv nachteilig mehr als einen Thread zu verwenden.