erfahrung: threadprogrammierung

[protossgamer]

vorweg: habe mich mit dem thema noch nicht sonderlich viel beschaeftigt, aber nach den ersten versuchen, habe ich das gefuehl, dass die threadprogrammierung nur in den seltesten faellen zu einer performance-steigerung fuehrt.

ich hoffe natuerlich auf erheblichen widerspruch. der verwatungsaufwand fuer die threads (umschalten kernelmode) scheint sehr viel taktzyklen zu fressen. gerade bei operatonen, die im hauptspeicher stattfinden, beispiel( quicksort, travesieren von baeumen oder auch matrizenoperatioen. diese sind gut paralellisierbar, aber irgendwie scheint der performance gewinn, wenn man ueberhaupt davon sprechen kann, in keinem verhaeltnis zu stehen (sowohl von der performance alsauch vom programmieraufwand)

gibt es irgendwelche buecher, die sich mit dem thema beschaeftigen. z.b. wieviel taktzyklen werden fuer die verwaltung von threads benoetigt

 

[e-Funktion]

Zeug in einzelne Threads auslagern lohnt sich logischerweise nur, wenn der Overhead vom Multithread locker wieder reingeholt werden kann. Teilweise habe ich aus 4s single-Thread Rechenzeit bei Algorithmen 0,8s gemacht . Teilweise hat es sich nicht gelohnt. Musst du eben abwägen/nachmessen. Ich arbeite mit Visual Studio, da kann man sich mit Performance Timern Ticks und Zeit ausgeben lassen. In anderen IDE gibt's sicherlich auch Funktionen. Habe es hauptsächlich in C# verwendet und nur in VS.
Es handelt sich da um die Stopwatch aus der System.Diagnostics wenn ichs richtig im Kopf habe.

 

[Valeria]

Was glaubst du warum die meisten einfachen Programme immer noch nur mit einem Thread rennen?
Die Umstellung des Programmierers (z.B. aus einer älteren Zeit) und der Mehraufwand steht meist nicht in einem guten Verhältnis zum Performencegewinn. Dazu kommen noch Probleme, die zusätzlich auftreten können. (z.b. Deadlock)
Und für extrem parallelisierbare Sachen, wo ernsthafte Berechnungen gemacht werden nimmt man die GPU zur Hilfe mit OpenCL oder CUDA.

Doch in Zukunft sollte man natürlich mit mehreren Threads programmieren.

 

[e-Funktion]

Was glaubst du warum die meisten einfachen Programme immer noch nur mit einem Thread rennen?

Weil sich hier die Spreu vom Weizen trennt - oder es sich nicht lohnt bzw. in manchen Fällen keine Option ist. Oft jedoch ersteres habe ich das Gefühl.

Ich kann jetzt nur für mich sprechen da ich es nur in C# bisher verwendet habe, aber einfacheres Multithreading programmieren schafft hier zumindest auch ein Affe der 5 Wörter Gebärdensprache lernen kann.

Dazu kommen noch Probleme, die zusätzlich auftreten können. (z.b. Deadlock)

Hier hilft nur: Hirn benutzen. Sollte man beim Programmieren aber sowieso immer machen, egal wieviele Threads man erstellt.

Doch in Zukunft sollte man natürlich mit mehreren Threads programmieren.

In Zukunft? Das sollte heute eigentlich jeder machen der meint er müsse etwas rechenintensiveres Coden und sich mal ernsthaft damit befassen, zumindest wenn es nicht nur für den eigengebrauch ist. Wenn ich sehe wie manche Software (auch Spiele!) Single-Threaded rennen oder nur lausig parallelisiert sind könnt ich kotzen weil es in Zeiten von 4+ Kernen und mehr einfach nicht mehr Zeitgemäß ist.

 

[DJND]

Mehrere Threads zu benutzen macht nur in bestimmten Situationen wirklich Sinn. Nur wenige Programme benötigen überhaupt nennenswert Rechnerzeit für eine ihrer Aufgaben, und diese Aufgabe in einen alternativen Thread zu verlegen macht natürlich nur unter einigen Rahmenbedingungen auch Sinn. Dann ist da noch die Frage der Kosten und des Zeitaufwands.

Wenn Kunden auch für ein Programm bereit sind zu zahlen, was sie halt mal 5 Sekunden warten läßt bei größeren Datenmengen, wozu sollte der Entwickler zusätzlich Geld investieren? Solange der gewünschte Funktionsumfang gegeben ist reicht das doch. Effizienter Code, Sicherheit der Daten, das gehört doch alles zum Kapitel "Ferner liefen".

Oh, @Ursprungsposter: Ein Text, der weder Großschrift noch deutsche Sonderzeichen enthält und einem sowas wie "verwatungsaufwand, operatonen, travesieren, matrizenoperatioen, paralellisierbar" entgegenschleudern sind wirklich ekelig zu lesen. Wenn wir uns Zeit nehmen, deinen Post zu lesen und dir zu antworten, dann solltest du dir auch die Minute nehmen und unsere geopferte Freizeit entsprechend würdigen. Danke!

 

[VikingGe]

Mehrere Threads nutzen macht aber besonders Sinn, wenn

- ein rechenintensives Problem trivial parallelisierbar ist, also fast keine Kommunikation zwischen den rechnenden Threads stattfindet. Sowas wie Huffman-Kompression, zum Beispiel. Da hat man dann eine Queue, wo man Dinge reinstopft, und die Ergebnisse kommen woanders wieder raus, und im Idealfall eine 1:1-Skalierung auch über 20+ Kerne hinweg.

- mehrere Dinge getan werden, die nichts miteinander zu tun haben. Die kann man dann auch problemlos gleichzeitig erledigen, gerade bei Spielen dürfte man soetwas doch relativ häufig haben (KI eines NPCs, eine GUI-Animation und das Nachladen von Daten werden sich ja gegenseitig wohl kaum behindern).

In beiden Fällen kann man einfach eine feste Zahl von Threads starten, der Overhead reduziert sich dann quasi auf die Zugriffe auf eine wie auch immer geartete Queue.

Alles andere ist schwieriger, da muss man dann schon ein paar Minuten über seine Implementierung nachdenken, aber es geht definitiv und bringt auch etwas (siehe z.B. Video-Encoding).

 

[antred]

Alles andere ist schwieriger, da muss man dann schon ein paar Minuten über seine Implementierung nachdenken, aber es geht definitiv und bringt auch etwas (siehe z.B. Video-Encoding).

Selbst dann muß man ja nicht jedes Mal das Rad neu erfinden. Je nach Programmiersprache gibt es da schon diverse Frameworks/Libraries, die das Parallelisieren von Abläufen stark vereinfachen. Für C++ gibt es da zum Beispiel die Intel Threading Building Blocks library oder OpenMP.