Guten nachmittag Leute
Mal eine Frage und zwar wie sieht das bei Multithreading aus. Wenn man einen Algorithmus zwecks Optimierung Multithreading fähig macht, wonach sollte man da gehen um die Anzahl der parallelen Threads bestimmen.

Hat da einer nen Tipp?

Wenn du davon ausgehen kannst, dass alle Threads gleich und vollständig ausgelastet sind, kannst du die Anzahl der Threads gleich der Anzahl der CPUs setzen.

Multithreading ist nur dann ein Hilfsmittel zur Skalierung, wenn die Architektur bei Parallelverarbeitung selbst skaliert. Mein Computer kann das zum Beispiel nicht, weil er nur einen Kern und nur einen Prozessor hat, Multithreading würde also bei mir keinerlei Mehrleistung bringen, was rechenintensive (I/O-unabhängige) Operationen angeht.
Im Gegenteil. Mehrere Threads erzeugen Verwaltungsoverhead, mindestens im Scheduler, oft auch bei der Datensynchronisation, und das kostet Rechenzeit, die meiner Berechnung nicht zur Verfügung steht.
Du solltest also, wie Spaceguide schon schrieb, so viele Threads erzeugen, wie du tatsächlich Threads parallelisiert ausführen kannst (das ist heute zwischen einer und vier, wenn man von einem gewöhnlichen Computer bis zu einer guten Workstation ausgeht). Aber keinen einzigen mehr! Zumindest nicht mehr dem Ziel, die Operations zu beschleunigen, sondern nur mit dem Ziel, die Operation von anderen Flaschenhälsen zu entkoppeln (Stichwort: "Meine Anwendung reagiert nicht mehr, wenn ich was rechne!!einhundertelf").
Üblicherweise ist man heutzutage auch nicht mehr alleine auf einem Rechner. Wenn ein Anwender zwei Kerne hat, möchte er vielleicht in einem Kern dein Programm die dreihundertsiebzigtausendfünfhundertdreiundachzigste Mersenne-Primzahl bestimmen, mit dem anderen Kern aber seine DVD schauen, weil er keinen Hardware-MPEG2-Dekoder hat. Wenn du da zwei Threads erzeugst und diese an die beiden Kerne aufteilst, wird der Anwender sich entsprechend darüber ärgern, daß er mit seinem System nix mehr machen kann. Er kann zwar beide Threads fest auf nur einen Kern legen, damit er den anderen Kern frei hat, aber dann greift wieder die Geschichte mit dem unnötigen Verwaltungsoverhead.
Bei gewissen Programmen kann man ruhig ein *wenig* Fachwissen vom Anwender verlangen. Ich würde an dieser Stelle einen sinnvollen Preset nehmen (Anzahl der Kerne), dem Anwender aber die Möglichkeit geben, die Anzahl der Threads selbst zu bestimmen, je nachdem, was er im Augenblick sonst noch zu tun gedenkt.

Aber ich bin ja in der Regel nicht der einzige Prozess. Ist das nicht schon wieder schlecht da das Zeitscheiben management und das Umschalten zu viel Zeit braucht?

digi_c hat folgendes geschrieben:

Aber ich bin ja in der Regel nicht der einzige Prozess. Ist das nicht schon wieder schlecht da das Zeitscheiben management und das Umschalten zu viel Zeit braucht?

Ist es. Das kannst du aber unter Windows nicht beeinflussen (und selbst unter Linux nur beschränkt).
Du kannst auch nicht Rücksicht auf andere Prozesse nehmen, die im Hintergrund arbeiten. Heutige Systeme haben deutlich mehr Prozesse als Prozessoren. Der Unterschied ist, daß diese Prozesse die Kerne nicht ständig auslasten. Es kommt also darauf an, wie sehr du eventuell vorhandene weitere Kerne tatsächlich Edit: mit Nutzarbeit auslasten möchtest. Die Kontextwechsel zwischen mehreren Prozessen hast du so oder so, und zwar ständig, und du kannst auch nicht das geringste dagegen tun, außer DOS zu verwenden.

Lohnt sich da der Aufwand überhauptnoch außer, dass es vielleicht professioneller ist?

digi_c hat folgendes geschrieben:

Lohnt sich da der Aufwand überhauptnoch außer, dass es vielleicht professioneller ist?

Er lohnt sich, um Aufgaben abzugrenzen, damit beispielsweise die Anwendung noch reagiert oder irgendein I/O-Puffer nicht überläuft. Das wäre aber das Auslagern einer rechenintensiven Operation in einen einzigen Thread. Diese Rechenarbeit auf mehrere Threads zu verteilen, wird sich in Zukunft immer mehr lohnen, weil die Prozessorhersteller langsam einsehen, daß heute mehr Parallelverarbeitung als reine Gigahertz-Zahlen gefragt sind. Der Trend geht sehr eindeutig hin zu Multicore-Systemen, und zwar nicht nur für Spielekonsolen sondern auf für den Consumer-Markt.
An diesen Stellen ist beispielsweise die Kodierung von Audio- oder Video-Daten interessant. Habe ich vier Kerne, könnte ich von meiner DVD viermal so schnell eine Sicherheitskopie als DivX haben, wenn ich alle Kerne auch benutzen kann. Und dazu ist es notwendig, daß das entsprechende Programm das mitmacht.

Ob der Nutzen in brauchbarem Verhältnis zum Aufwand steht, hängt vom Algorithmus, vom Anwendungsgebiet, der Anwendungszielgruppe und letztendendes vom Programmierer und seiner Erfahrung ab.

Ja das mit den vielen Cores wird ja ordnetlich durch die Fachpresse gekaut. Also kann man das so sheen, dass jder Core/HT oder einzelne CPU ihre einzelne Zeitscheibe hat? Und Windows verteilt alle laufenden Programme/Threads so darauf, das alle möglichst ausgelastet sind? Der einzelne Core teilt dann den ihm zugeordneten Prozessen einen entsprechenden Anteil an der Rechenzeit zu?

Aber ich sehe echt schwarz, wenn mn das noch mit handgefeilten MMX/SSE/SSE2 Routinen kombinieren will

digi_c hat folgendes geschrieben:

Ja das mit den vielen Cores wird ja ordnetlich durch die Fachpresse gekaut. Also kann man das so sheen, dass jder Core/HT oder einzelne CPU ihre einzelne Zeitscheibe hat? Und Windows verteilt alle laufenden Programme/Threads so darauf, das alle möglichst ausgelastet sind? Der einzelne Core teilt dann den ihm zugeordneten Prozessen einen entsprechenden Anteil an der Rechenzeit zu?

Einzelne Cores implementieren in Hardware keinen Scheduler. Wie sich der Windows-Scheduler bei Multicores exakt verhält, weiß ich auch nicht. Allerdings gibt es auch mehrere Optimierungsmöglichkeiten. Ich bin mir ziemlich sicher, daß bei mehreren Cores die Last einigermaßen auf alle vorhandenen Cores verteilt wird. Allerdings kann man mittlerweile auch bei Multicores einzelne Kerne abschalten, um Strom zu sparen (interessant bei Notebooks). Dort wäre es dann sinnvoll, einen Core voll auszulasten und den anderen Core komplett auszuschalten, weil das wahrscheinlich mehr Energie spart, als beide Cores nur mit halber Leistung zu betreiben. Da kommt es dann darauf an, ob der Scheduler von den Stromsparfunktionen weiß und was der Anwender in dieser Hinsicht haben möchte.

digi_c hat folgendes geschrieben:

Aber ich sehe echt schwarz, wenn mn das noch mit handgefeilten MMX/SSE/SSE2 Routinen kombinieren will

Warum? SSE und andere SIMD-Befehle können in jedem Kern getrennt ausgeführt werden, wenn die Kerne das unterstützen und zwei SIMD-Einheiten vorhanden sind. Dadurch kannst du doppelt parallelisieren, zum einen durch die Aufteilung der zu verarbeitenden Daten auf zwei Prozessoren und zum anderen durch Parallelisierung mehrerer Instruktionen innerhalb eines Prozessors.
SSE und Multicores sind unterschiedliche Methoden zur Parallelisierung, die prinzipiell unabhängig voneinander funktionieren können.

Aha. ja das SIMD/Multicore getrennt ist wußte ich aber ich dachte das diese Erweiterungen zum Flaschenhals werden indem sie nur einmal vorhanden sind. Na da kann man ja richtig Spass mit haben (vorrausgesetzt man hat die nötige Hardware dafür )

digi_c hat folgendes geschrieben:

Aha. ja das SIMD/Multicore getrennt ist wußte ich aber ich dachte das diese Erweiterungen zum Flaschenhals werden indem sie nur einmal vorhanden sind.

Ich weiß nicht, ob sie mehrmals vorhanden sind. Wie gesagt, *wenn* beide Kerne es unterstützen und die entsprechenden Rechenwerke doppelt da sind, geht es. Aber selbst wenn nur eine SIMD-Einheit für zwei Kerne zur Verfügung steht, dürfte es für den Prozess transparent sein. Beide Kerne werden getrennt SIMD-Operationen ausführen können, sie werden halt nur wieder serialisiert. In dem Fall wäre das tatsächlich ein Flaschenhals, ja.
Da die modernen DualCore-Layouts tatsächlich zwei Kerne enthalten, sollten aber auch die SIMD-Werke doppelt vorhanden sein.
Bei HT sieht es anders aus, da dort nur ein Kern arbeitet. HT hat lediglich die logischen Merkmale zweier CPUs (zwei Registersätze, Instruktionszeiger und so weiter. Die Rechenwerke selbst sind nur einmal vorhanden und werden nur pseudovirtualisiert, indem die lange NetBurst-Pipeline, die normalerweise größtenteils brach liegt, vorne mit neuen Instruktionen verwendet wird, während hinten noch die alten abgearbeitet werden. Die Befehle sind also tatsächlich ein wenig zeitversetzt, es erhöht sich nur die Gesamtauslastung der Pipeline (und somit die Gesamtauslastung der einzelnen Rechenwerke).