[tempus fugit]

Zitat von Schmiddi

Hallo,

ich habe aufgehört, bei PCs an Zukunftstauglichkeit zu denken - es kam immer anders Soll heißen: wenns denn mal wieder sein muss, kommt unter den Tisch, was aktuell am besten passt. Und aktuell sind wenige, dafür schnellere Kerne immer noch vorne. Das würde wohl aktuell noch (?) für Intel sprechen...

Viele Grüße, Andreas

Gut dass ich noch etwa zwei Wochen bis zur Bestellung habe.
Bis dahin werde ich mich wohl noch 10 weitere male umentscheiden

[m.rup]

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

Interessanter Link, kannte ich noch gar nicht. Sieht wohl so aus als ob im Moment ein höher getakteter Vierkerner (und Hyper Threading gibt's ja auch noch) für LR die beste Option wäre.
Ansonsten hat's Schmiddi ganz gut ausgedrückt. Wenn die Computer-Zukunft da ist (so in einem Jahr ), gibt's hundertprozentig schon wieder was viel tolleres für weniger Geld. Ich würde mir jetzt wegen der Videos einen AMD anschaffen. Wenn das mit der Encodiererei nicht wäre würde es jetzt ein Intel Vierkerner. Leistungsstark genug für die nächsten Jahre sind die beide.

[wiseguy]

Zur Lightroom-Performance gibts auch andere Benchmarks:
http://www.pcgameshardware.de/Ryzen-...eview-1222033/

Da schneidet der AMD hervorragend ab. Wem sollten wir nun mehr glauben?

[m.rup]

Das widerspricht sich ja nicht. Der erste Link sagt nur dass Lightroom bei mehr als vier Kernen nicht mehr so gut skaliert, über die absolute Geschwindigkeit mit verschiedenen Prozessoren wird nichts gesagt.

[tempus fugit]

Zitat von wiseguy

Zur Lightroom-Performance gibts auch andere Benchmarks:
http://www.pcgameshardware.de/Ryzen-...eview-1222033/

Da schneidet der AMD hervorragend ab. Wem sollten wir nun mehr glauben?

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

[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