erlaube mir bitte zu deinen nachfolgenden Feststellungen/Äußerungen ein paar Korrekturen/Klarstellungen
1. Die Parallele Variante wird nicht besser je mehr Daten verarbeitet werden, sondern weil das Verhältniss Parallelisierungskosten zu Anzahl der ausgeführten Operation die Parallelisierbar sind sich verändert.andreas hat geschrieben: ↑Mo, 05. Aug 2019 10:25 Ich habe einiges gelesen, an Vorträgen gehört und selbst Tests unter C# mit Parallelausführung auf mehreren CPUs (keine Threads) ausprobiert.
Die Job-Verteilung auf mehrere CPUs kostet viel Zeit! Das ist von vielen Experten bewiesen!
Deswegen raten diese, vor der Anwendung der Parallelausführung auf mehreren CPUs jeden einzelnen Fall zu bewerten!
Ich habe Beispiele in C# nachgebaut, die das gleiche mit unterschiedlicher Menge der Operationen/Daten ausführen.
Die Ergebnisse: die Ausführung auf mehrere CPUs löhnt sich nur bei sehr großen Operations-/Datenmenge aber auch nicht immer!
Bei kleinen Mengen ist die Parallelität viel langsamer! Und ob es bei den Größeren Mengen und kleinen ms-Unterschieden es sich lohnt, ist auch die Frage, die jeder für sich selbst und je Projekt beantworten muss.
Im folgenden Bild habe ich Screenshot von dem C#-Programm angehängt. Die Schleifen machen nur mathematische Operationen. Bei dem Beispiel mit den Namen werden diese auf Bildschirm ausgegeben. Die Ergebnisse müssten für alle Programmiersprachen gelten! Die Verteilung der Aufgaben auf Threads würde hier bestimmt noch das ganze etwas beschleunigen, würde aber von der eigener Programmierung und richtiger Aufgabenverteilung abhängen!
2. Ich kenne deinen Testcode nicht, muss aber aus deiner Aussage "nur mathematische Operationen" sowie deinen Messdaten vermuten das du keine Komplexen Operation durchführst (File I/O, sorts in memory, scan von byte-arrays, Windows API Calls, UI calls), auch muss ich bei deinen Messdaten davon ausgehen das du keine Daten auf die gleichzeitig Zugegriffen werden muss zwischen den Threads synchronisierst. Beides würde deine Parallelisierungskosten weiter erhöhen und damit das ganz noch mehr zu ungunsten der Parallelisierung verschieben.
Wenn mann 1+2 verstanden hat und berücksichtigt dann ist es leider so, das nur wenige Szenarien von Multithreading über CPU Kerne hinweg im Sinne einer Skalierung der Verarbeitungsgeschwindigkeit profitieren. Photoshop Filter sind ein gutes Beispiel, das Bild wird in Partitionen unterteilt und dann wird auf jedem Thread einer anderen CPU der Filter auf die Bilddaten angewandt. Funktioniert aber auch nur wirklich schneller wenn bis auf Assembler Ebene alles optimiert ist - und die haben bei Adobe dafür tatsächlich ein eigenes Team das sich mit diesem Aspekt auseinandersetzt.
Nochmals, Multihreading war niemals dafür gedacht über mehrer Kerne hinweg eine Skalierung zu erreichen. Die besten Skalierung erreicht man heute indem über Prozesse auf unterschiedlichen Kernen die Aufgaben verteilt werden. Dazu wird am besten die CPU für den Prozess zufällig aus den Verfügbaren CPUs ausgewählt - also ungefähr: SetLogicalProcessor( RandomInt(GetLogicalProcessorCount()) )
Multithreading ist dafür gemacht mehrere Ausführungspfade innerhalb eines Prozesses ohne yielding zu erhalten oder in der Praxis ganz einfach dafür Sorge zu tragen das ein Anwender nicht darauf warten muss das der Druckjob fertig ist, oder der Auswertungslauf fertig ist. Er kann trotzdem in der multithreaded Anwendung weiterarbeiten und zum Beispiel einen Kunden editieren.
Gruss
Steffen F. Pirsig
Alaska Software Inc.