[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

[NetrunnerAT]

Zitat von Ellersiek

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.

Wall of Text ...

Sehr idealisierte Ansicht. Es wäre schön, wenn es so laufen würde! Gerade Light Room kann nicht sequenziell im Stapel abarbeiten. Da ist das IO System aus Datenträger und Speicher nicht so limitierend wie man denkt. Eine SSD mit nur 300mb/sec VS (erfundene Werte!) einer PCI-E 4 LAN mit 2000mb/sec VS Ram Drive mit 6000mb/sec beeinflusst da weniger als man denkt. Je nach Speicherausbau Cached das OS so oder so alles und in der Rechenintensiven Phase, ist kein Datenzugriff vorhanden!

LR bearbeitet zb das Bild in einen durch, mit ein Worker. Capture One (Software aus den Mittel Format Sektor) bedient sich in vielen Punkten eine Arbeitsweise die ich von POV-Ray her kenne, nämlich eine segmentierte Bildbearbeitung! Das lässt sich besser auf mehr Core Systeme verteilen.

Daraus ergibt sich ... ein i7 bringt bei LR fast gar nix, da hier rohe Gewalt notwendig wird. Ein Single Core massiv übertaktet! Mit Prozess Affinität, Prio hoch und Turbo Mode schwer ausgereizt.

Ich neige da sogar eher dazu einen i5 in der K Version und Z-Chipsatz vorzuschlagen, um dieses Übertaktungspotenzial ausnutzen zu können. Eben weil diese Software so arbeitet wie sie es halt tut. Wie da ein AMD RYZEN mit seiner mathematischen Eigenheit da zurecht kommt, ist doch in Moment sehr spekulativ? So weit ich gehört habe, ist der ja in bestimmte Rechnungsarten verdammt schnell und in komplexeren nicht auf Intel's höhe angelangt?!? Benchmark auf PC-Games spiegelt zum Teil diese Aussage ja wieder. Interessant ist wohl ... Speicherkanäle scheinen positiv auf LR zu wirken. Also 2011-3 Chipset mit i7 und übertaktete RAM's?

Vor allem Perfmon wäre ein ideales Tool um die Flaschenhälse klar zu erkennen. Gerade Filesystem kann man gut mit ein kleinen RAM-Drive testen, bevor man sich eine SSD in RAID-0 antut.

https://www.pugetsystems.com/labs/ar...rformance-649/

[Ellersiek]

Zitat von NetrunnerAT

Sehr idealisierte Ansicht....

Schrieb ich doch.

Zitat von NetrunnerAT

...Capture One (Software aus den Mittel Format Sektor) bedient sich in vielen Punkten eine Arbeitsweise die ich von POV-Ray her kenne, nämlich eine segmentierte Bildbearbeitung!...

Was aber nur funktioniert, wenn die Berechnung eines Pixels nicht von der Berechnung eines Nachbarpixels abhängt. Da könnte der Korrekturpinsel oder der Kopierstempel Probleme bereiten. Dieser müsste also vor der Verteilung auf die Kerne/Threads aktiv werden.

Diese Überlegungen sind allerdings viel Kaffeesatzleserei, da wir den Softwareablauf nicht im einzelnen kennen.

Gruß
Ralf

[tempus fugit]

Zitat von Ellersiek

Schrieb ich doch.

Was aber nur funktioniert, wenn die Berechnung eines Pixels nicht von der Berechnung eines Nachbarpixels abhängt. Da könnte der Korrekturpinsel oder der Kopierstempel Probleme bereiten. Dieser müsste also vor der Verteilung auf die Kerne/Threads aktiv werden.

Diese Überlegungen sind allerdings viel Kaffeesatzleserei, da wir den Softwareablauf nicht im einzelnen kennen.

Gruß
Ralf

Mag sein, dass nicht alle Funktionen pixelunabhängig sind und sich daher nicht so gerne parallelisieren lassen. Aber das erste was man bei einem Bild so macht ist doch meist: "bissle heller/dunkler". Da machen mehr Kerne mehr Sinn. Und wenn man gleich zu beginn mit einem Stockenden Ablauf zu kämpfen hat, dann brauchen wir über den Rest nicht zu reden.

[Ellersiek]

Zitat von tempus fugit

Mag sein, dass nicht alle Funktionen pixelunabhängig sind und sich daher nicht so gerne parallelisieren lassen. Aber das erste was man bei einem Bild so macht ist doch meist: "bissle heller/dunkler". Da machen mehr Kerne mehr Sinn....

Mehr Kerne ergeben nur dann Sinn, wenn die Software die Erledigung der Aufgabe entsprechend parallelisiert. Und da scheint, laut NetRunner, LR Nachholbedarf zu haben.

Zitat von tempus fugit

... Und wenn man gleich zu beginn mit einem Stockenden Ablauf zu kämpfen hat, dann brauchen wir über den Rest nicht zu reden.

Das schafft mein 9 Jahre alter Dell Precision M6400 mit den A99M2-RAWs allerdings locker - ganz ohne Parallelisierung.

Gruß
Ralf

[tempus fugit]

Zitat von Ellersiek

Mehr Kerne ergeben nur dann Sinn, wenn die Software die Erledigung der Aufgabe entsprechend parallelisiert. Und da scheint, laut NetRunner, LR Nachholbedarf zu haben.


Das schafft mein 9 Jahre alter Dell Precision M6400 mit den A99M2-RAWs allerdings locker - ganz ohne Parallelisierung.

Gruß
Ralf

Mein schleptop hängt da leider etwas.
Vor allem, wenn ich reinzoome und dann heller oder dunkler mache.
Aber LR. wäre ja nur zu einen geringen Teil mein Anwendungsbedarf...