Dualcore Auslastung

Hallo, ich habe einen Dualcore. Nun würde mich interessieren, ob der Prozessor mein geschriebenes Programm auf beide Prozessoren aufteilt, oder ob es schneller ist, wenn ich 2 Threads erstelle die jeweils die Hälfte erledigen?
Danke!

Hallo Teletabi,

Das ist abhängig von der Aufgabenstellung und ob es sich lohnt dafür extra 2 Threads zu erstellen. Was willst du denn in Threads auslagern?

Ist jetzt nichts systemspezifisches, es ist ungefähr eine sehr lange aufzählung von allen möglichen kombinationen eines strings

Hallo Teletabi,

ein Programm mit nur einen Thread wird nicht auf verschiedene Prozessoren aufgeteilt. Wenn du die Auslastung eine Dulacore erhöhen willst, musst du das Programm in mehrere Threads aufteilen.

Ob ein Programm dadurch schneller wird, hängt von den Umständen ab. Ein Programm dessen Geschwindigkeit durch die Festplattenzugriffe begrenzt wird, wird auch nach einer Aufteilung in Threads nicht schneller werden. Im schlimmsten Fall tritt sogar das Gegenteil ein, weil die Festplatte die Daten nicht mehr sequentiell liest (max. Dauertransferrate), sondern immer zwischen zwei Positionen in der Datei hin und her springen muss und daher zusätzliche, zeitaufwändige Lesekopfbewegungen notwendig werden.

Auch der Hauptspeicherzugriff kann auf ähnliche Weise zur Bremse werden.

Am besten funktioniert es, wenn beide Prozessoren aufwändige Berechnungen durchführen müssen (z.B. Raytracing) und ihre Daten dabei im Wesentlichen aus ihrem eigenen Cache laden können.

herbivore

Da ich mich gerade damit beschäftige einen Demonstrator für die Sinnhaftigkeit paralleler Programmierung im Bereich Wegsuche zu bauen geb ich auch mal meinen Senf dazu.

Parallelisierung ist ein spannendes Thema, weil es notgedrungen sehr aktuell ist, aber noch nicht ausreichend erforscht, als das man eine bewährte Herangehensweise hätte, wie man bestehende Applikationen parallelisiert. Auf der anderen Seite muss man genau das aber tun, weil die Clients immer öfter immer mehr Kerne haben und dieser Trend wird sich beim besten Willen nicht aufhalten oder verlangsamen, weil es aus energietechnischen Gründen keinen Sinn mehr macht die Taktraten der einzelnen Kerne noch weiter hoch zu setzen.

Prinzipiell ist schonmal das Problem, was herbivore schon angeschnitten hat, dass ein Thread immer sequentiell abläuft, also nur von maximal einem Prozessor bearbeitet werden kann, also muss man um überhaupt eine Parallelisierung hinzukriegen auf mehrere Threads aufteilen. Dazu gibt es jetzt aber auch gleich mehrere Möglichkeiten, einmal wirklich Threads, aber es ist genausogut möglich, Delegates asyncron auszuführen (BeginInvoke), das ist für kurzlebige Threads sogar oft genug sinnvoller, weil die CLR offenbar optimiert (greift wahrscheinlich automatisch auf den Threadpool zurück). Aber in jedem Fall kostet dieser Overhead Zeit.

Wenn du jetzt mit Mitteln wie Threads oder asyncronen Delegates jede einzelne Schleife parallelisieren willst, dann bringt das in den meisten Fällen ziemlich genau nichts, weil der Overhead viel mehr Zeit frisst als die parallele Abarbeitung wieder rausholt. Wie es aussieht macht Parallelisierung dann am meisten Sinn, wenn sie möglichst grob ist, also wenn du die Threads möglichst lange leben lässt. Interessanterweise ist das bei den Parallel Extensions nicht so tragisch, wenn man die Strukturgröße kleiner wählt, also Schleifen parallelisiert, die einen verhältnismäßig kleinen Schleifenkörper haben, da wurde bei der Optimierung offenbar ganze Arbeit geleistet.

Besser ist es aber im Allgemeinen, die Algorithmen an sich zu parallelisieren und zu schauen, was man parallel machen kann. Bei manchen Algorithmen (u.a. leider klassische Wegsuche-Algorithmen wie Dijkstra oder A*) geht es aber auch einfach nicht oder nicht wirklich, weil immer ein Ergebnis auf dem anderen aufbaut. Im Moment sieht die Situation dann so aus, dass man sich dann was überlegen darf, wie man diese Algorithmen dann doch irgendwie parallelisiert kriegt oder gleich neue parallelisierbare Algorithmen entwickelt. Oder auch überlegen, wo man sonst noch rechenaufwändige Operationen parallelisieren kann.

huhu,

nachdem das sich ja irgendwie zu nem Thread-Tip-Thread entwickelt:

Man kann auch bei klassischem Programmdesign darüber nachdenken ob man nicht bestimmte Dinge auf Threads aufteilen will. Ich finde dass sich auch die einzelnen Programm-Layer dafür eignen. Natürlich bekommt man bei kurzen Überprüfungen im Business-Layer mehr Leistungseinbussen als Gewinne, aber bei einem Daten-Layer kann sich asynchrones Laden dann schon wieder deutlich lohnen.

😃

Xynratron