Newsmeldung von slashCAM:
Auf der diesjährigen Computex-Pressekonferenz trat AMDs CEO Lisa Su sichtlich selbstbewusster auf als in den letzten Jahren. Und das mit gutem Grund, denn was AMD für die...
Hier geht es zur Newsmeldung auf den slashCAM Magazin-Seiten:
Killer-Workstation Prozessoren und Grafikkarten von AMD - Threadripper II mit 32 Cores
Antwort von Frank Glencairn:
Na ja, die Top CPUs kommen schon jetzt mit so ziemlich allem was ne aktuelle Kamera auswirft spielend zurecht, und die Verlagerung von immer mehr Prozessen in Richtung GPU, mindert die Bedeutung von CPU Kernen immer mehr. Selbst bei der aktuellen Generation ist man in fast allen (Video) Fällen mit ner schnelleren CPU besser bedient, als mit einer langsameren, die mehr Kerne hat. Im 3D Bereich sieht es natürlich anders aus.
Antwort von iasi:
"Frank Glencairn" hat geschrieben:
Na ja, die Top CPUs kommen schon jetzt mit so ziemlich allem was ne aktuelle Kamera auswirft spielend zurecht, und die Verlagerung von immer mehr Prozessen in Richtung GPU, mindert die Bedeutung von CPU Kernen immer mehr. Selbst bei der aktuellen Generation ist man in fast allen (Video) Fällen mit ner schnelleren CPU besser bedient, als mit einer langsameren, die mehr Kerne hat. Im 3D Bereich sieht es natürlich anders aus.
Wobei es beim Rendern mit CPU in Premiere doch noch Qualitätsvorteile gegenüber GPU-Rendern gibt. Dies ist aber dann wohl nur bei der endgültigen Ausgabe relevant - und da kann der Rechner auch mal die Nacht durchlaufen.
32 Kerne sind wohl wirklich der Overkill - es fragt sich dann eh, ob die Programme mit den vielen Threads überhaupt etwas anfangen können.
Antwort von Largo:
Selbst bei der aktuellen Generation ist man in fast allen (Video) Fällen mit ner schnelleren CPU besser bedient, als mit einer langsameren, die mehr Kerne hat.
Worauf stützt du diese Aussage? Die sehr umfangreichen Premiere Prozessortests von Pugedsystems zeigen da etwas anderes. Wobei das Preis-Leistungsverhältnis natürlich noch ein anderes Thema ist.
https://www.pugetsystems.com/labs/artic ... 350K-1047/
https://www.pugetsystems.com/labs/artic ... 80XE-1034/
Antwort von Frank Glencairn:
Ähem...
gerade die Puget Tests belegen meine Aussage.
Export 8K DNXHR HQ nach H265:
i9 14 Core 3.1 GHz = 556 sec.
i9 10 Core 3.3 GHz = 469 sec.
i7 8 Core 3.6 GHz 0= 415 sec.
selbst ein läppischer i5 6 Core 3.6 GHz ist mit 515 sec. immer noch schneller als das teure 14 Core Monster.
Und ja, bei dem RED Material sieht es anders aus, das liegt aber an der lausigen Optimierung des Codes, die völlig unnötig ein totaler Ressourcenfresser ist - nicht umsonst mußten sie seinerzeit extra ne eigene Decoderkarte bauen, damit das Zeug halbwegs flüssig läuft.
Wie man einen Wavelett-Codec extrem schlank und rasend schnell macht, hat Cineform gezeigt.
Antwort von Roland Schulz:
...und ganz ehrlich, die H.265 Main10 Qualität vom Coffeelake QuickSync muss man mit x265 erstmal toppen, egal wie lange das da rechnet...
Antwort von iasi:
"Frank Glencairn" hat geschrieben:
Ähem...
gerade die Puget Tests belegen meine Aussage.
Export 8K DNXHR HQ nach H265:
i9 14 Core 3.1 GHz = 556 sec.
i9 10 Core 3.3 GHz = 469 sec.
i7 8 Core 3.6 GHz 0= 415 sec.
selbst ein läppischer i5 6 Core 3.6 GHz ist mit 515 sec. immer noch schneller als das teure 14 Core Monster.
Und ja, bei dem RED Material sieht es anders aus, das liegt aber an der lausigen Optimierung des Codes, die völlig unnötig ein totaler Ressourcenfresser ist - nicht umsonst mußten sie seinerzeit extra ne eigene Decoderkarte bauen, damit das Zeug halbwegs flüssig läuft.
Wie man einen Wavelett-Codec extrem schlank und rasend schnell macht, hat Cineform gezeigt.
"der lausigen Optimierung des Codes" ???
Render Previews (AMD 16-core)
Red 8k = 49,4s
DNXHR HQ 8k = 73,7s
ProRes 4444 = 99s
Also ich nehm da lieber die 49s des lausigen Red-Codecs, als die 73s von DNXHR.
Hingegen werde ich den Unterschied von 0,6s zum 18-core wohl kaum merken.
Antwort von Frank Glencairn:
Die Tests waren auf einem PC, wo ProRes ein 32bit Handicap hat, das kann man nicht vergleichen.
Vergleich lieber mal Redcode und Cineform.
Außerdem hab ich ja geschrieben, daß Redcode von mehreren Kernen profitiert.
Antwort von Largo:
Ähem...
gerade die Puget Tests belegen meine Aussage.
Ähem... hüstel... Wie kommt es denn, das Puget zu einem anderen Fazit kommt? Du beziehst dich quasi auf die Ausnahme, nicht auf die Regel.
Ignorieren der unliebsamen Resultate, damit es zum eigenen Argument passt....
Antwort von Largo:
Largo hat geschrieben:
Ähem...
gerade die Puget Tests belegen meine Aussage.
Ähem... hüstel... Wie kommt es denn, das Puget zu einem anderen Fazit kommt? Du beziehst dich quasi auf die Ausnahme, nicht auf die Regel.
Ignorieren der unliebsamen Resultate, damit es zum eigenen Argument passt....
Wobei bei 14/16/18 Cores die 14/16 tatsächlich des öfteren bessere Resultate liefern.
Antwort von freezer:
"Frank Glencairn" hat geschrieben:
Die Tests waren auf einem PC, wo ProRes ein 32bit Handicap hat, das kann man nicht vergleichen.
Wieso hat ProRes ein 32 bit Handicap? Das ist seit CC2017 native 64-bittig integriert
Antwort von Frank Glencairn:
Umso schlimmer,
wenn RED raw Material incl. Debayering schneller läuft, als "fertiges" DNX/ProRes, spricht das nicht gerade für ne gelungene Implementierung.
Antwort von iasi:
"Frank Glencairn" hat geschrieben:
Die Tests waren auf einem PC, wo ProRes ein 32bit Handicap hat, das kann man nicht vergleichen.
Vergleich lieber mal Redcode und Cineform.
Außerdem hab ich ja geschrieben, daß Redcode von mehreren Kernen profitiert.
Red 8k = 49,4s
DNXHR HQ 8k = 73,7s
So sehr profitiert Redcode ab einer bestimmten Core-Zahl eigentlich gar nicht mehr von noch mehr Kernen.
Mir ist eigentlich nur wichtig, dass während des Schnitts alles flüssig läuft. Auf die Zeit für den Export kommt es mir nicht sonderlich an.
AMD hat wieder Schwung in die CPU-Welt gebracht und nun hat man eine breite Auswahl an Prozessoren, die flüssiges Arbeiten ermöglichen.
Die 32 Cores brauche ich zumindest jetzt noch nicht.
