[Ellersiek]

Zitat von tempus fugit

Haja, nicht signifikant schneller, obwohl doppelt so viele Kernevorhanden sind, also eigentlich die Arbeit in fast der halben Zeit gelöst hätte werden können.
Gut, der RYZN clockte mit 3,6 - 4,2 GHz, aber der Intel halt mit 4,2-4,5 GHz.
Aber der Frequenzunterschied macht die Kühe hier nicht fett!

108sek beim RYZEN vs 118sek beim 7700K

Die Anzahl der Kerne aber irgendwann auch nicht.
Das Lesen (xl) und Schreiben (xs) einer Bilddatei dauert, egal wie viele Kerne Du hast, xl + xs.
Das xl+xs ist durch bessere Hardware (SSD-NVMe) und bessere Protokolle und Systemarchitekturen sicher immer kleiner geworden, aber es bleibt ein mehr oder weniger sequentieller Prozess mit einem maximalen Durchsatz*.

Die Verarbeitungszeit y_single lässt sich durch mehr Kerne sehr wohl verkürzen (y_real = y_single/AnzahlKerne), allerdings nicht linear. Es kommt zu einem Verwaltungsaufwand für die Parallelisierung von zv und die Aufteilung nach dem Lesen (zl) und die Zusammenführung vorm Schreiben (zs) ist ebenfalls ein serieller Prozess.

Das bedeutet für die gesamte Verarbeitungszeit

v = xl + zl + zv + y_real + zs + xs

Lediglich der Zeitaufwand von y_real ist von der Anzahl der Kerne abhängig und der Zeitaufwand für zv verschlechtert zusätzlich noch die Effektivität der Parallelisierung**.

Teilt man die Verarbeitung in zwei Teile (Lesen/Schreiben/Verwaltung lsv = v - y_real und Berechnung b = y_real) so wird man wahrscheinlich (Achtung: Reine Vermutung) feststellen, dass der Anteil lsv bei einer normalen Bildbearbeitung höher ist, als b.

Der Flaschenhals ist also womöglich nicht der Prozessor sondern der Lese-, Schreib- und Verwaltungsprozess: Wenn lsv 40% einnimmt kannst Du im Idealfall (und davon ist nicht wirklich auszugehen) aus den verbleibenden 60% bei 4 Kernen 30% bei 8 Kernen machen. In Summe hättest Du 30% Geschwindigkeitszuwachs bei 100 % mehr Kernen.

Dieser Ansatz geht von einer Parallelisierung je Bild aus. Im Massenverarbeitungsprozess könnte es auch effektiver sein, den Gesamtprozess zu parallelisieren (je Kern/Thread ein Bild). Allerdings bleibt auch hier der i/o-Flaschenhals und die Software müsste einen weiteren Weg der Parallelisierung kennen und können.

Hinweis: Diese Betrachtung ist eine stark vereinfachte Darstellung. Natürlich ist die Welt etwas komplizierter und erst recht auf einem allgemeinen Rechner wie einem PC, der ja auch noch ein paar andere Aufgaben mit erledigen muss. Außerdem ist bei dieser Betrachtung die Möglichkeit der Aufgabenübernahme durch die Grafikkarte noch gar nicht berücksichtigt. Hier wäre der Vorteil eines noch höheren Parallelisierungsgrades allerdings mit den Nachteilen eines noch höheren Verwaltungsaufwandes, dem zusätzlichen Flaschenhals der Datenübergabe zur und von der Grafikkarte und einer weiteren, sehr speziellen Parallelisierungsoftware.

Mein Fazit: Alles aufeinander abstimmen und glücklich sein, nicht mehr die Hardware von 1985 nutzen zu müssen (damals gab es eine ähnliche Situation und man hat versucht, via Parallelisierung mehr Leistung zu bekommen - im MFlop-Bereich - grins).

Gruß
Ralf

* selbst wenn zwei Dateien "gleichzeitig" geschrieben werden können, wird es nahezu egal sein, ob die zwei Dateien hintereinander oder parallel liest bzw. schreibst (Achtung: nahezu und nicht von der Anzahl der Kerne abhängig!)

** und zwar um so mehr, je mehr Kerne Du einsetzt. Bestenfalls bleibt zv konstant. Davon ist jedoch nicht auszugehen, das es auch einen Verwaltungsaufwand je Kern geben wird:
zv = zv_grundsätzlicher_Aufwand + zv_Aufwand_je_Kern