Du verwendest einen veralteten Browser. Es ist möglich, dass diese oder andere Websites nicht korrekt angezeigt werden. Du solltest ein Upgrade durchführen oder einen alternativen Browser verwenden.
NewsIntel Nova Lake-S: Core Ultra 5 mit 8 P-Cores, Ultra 9 mit 52 Kernen, DDR5-8000 dazu
Wie gesagt, die Server-CPUs, wo der Fehler tatsächlich relevant ist, behalten HT bisher. Ausnahme die reinen E-Core-CPUs.
KarlAlbrecht schrieb:
Es ist ja nicht ein reines Intel Problem, SMT ist ja ziemlich identisch implementiert. Ich denke wenn AMD anfängt ihre c-Cores beizupacken werden sie SMT auch zeitnah fallen lassen. Es bietet einfach nicht mehr so den Mehrwert, Kerne genug sind da mittlerweile. Und Intel mit den E-Cores zeigt, wie viel Leistung aus kleines Cores geholt werden kann.
Bei Intel ist das Scheduling halt sehr viel komplizierter, da die E-Cores n größeren Abstand zu den P-Cores haben, als es bei AMD der Fall ist. Also hinsichtlich der absoluten Leistung und auch hinsichtlich Funktionsumfang. AMD C-Cores sind ja nur etwas anders angeordnet mit nem geringeren Cache, soweit ich weiß.
"Damals" als CPUs noch 2-4 Kerne hatten, war es eine sinnvolle Erweiterung, heutzutage ist es meist nur tödlich für die Latenzen, wenn dann wirklich alle Threads ausgelastet werden sollen.
Wenn die Rechenwerke früher Pausen einlegten weil sie auf Daten warteten war das verlorenes Potential, das man durch einen zweiten Thread (teilweise) heben konnte. Heute rauschen die ALUs eher ins thermische Limit, worauf man mit Drosseln reagiert. Da ist es natürlich Quatsch, zwei Threads aufwendig auf ein einzelnes Rechenwerk zu knallen, wenn man den zweiten Thread mit weniger Aufwand auf ein anderes auslagern kann (und dazu noch zahlreiche Sicherheitsimplikationen loswird).
Ein "Stall" der ALUs wird also nicht mehr als verschenktes Potential, sondern als willkommene Cool-Down-Pause wahrgenommen.
Im Übrigen sind die Rechenwerke auch viel besser ausgelastet als vor 20 Jahren, oder wo sonst soll die gesteigerte IPC hergekommen sein?
Vorerst. Wie sich bereits abgezeichnet hat, so führt Intels Entscheidung, das Thread-Level Parallelism einzustellen, nicht nur auf einen sicherheitsrelevanten Aspekt zurück, dem Redesign der Cache-Hierarchie betreffend, sondern auch die Energieeffizienz und die Temperatur standen zuletzt für maßgebliche Kriterien, weshalb Intel an seiner Hyper-Threading Technology nicht weiter festhalten wolle.
Video Encoding. 3 Minuten Video, 20 Minuten warten, wenn man alles auf "best quality H265" stellt, selbst wenn man schon eine aktuelle, schnelle CPU hat.
Könnte nicht schaden, wenn es 4x so schnell wäre, spätestens falls irgendwann 6K oder 8K Video reinkommt, aber da limitiert vielleicht eher die Festplatte.
Für CPU-Enkoding (Shader-Array: CPU + GPU) braucht es so 'n Monster wie den AMD Ryzen Threadripper mit mindestens 32 Cores, jedenfalls für das rechenintensive HVC1/ HVC2.
Solange man das nicht hat, muss man entweder auf AVC1 ausweichen oder AV1 in Kauf nehmen. Ansonsten gehe man in dem HVC1-/ HVC2-Enkoding über die VPU (CPU + GPU für die Vor-und Zwischenschrittberechnung; die VPU in der Hauptberechnung).
Intels SMT ist deutlich schlechter als AMDs. AMD hat mehr Sicherheitsbarieren, weshalb sie weniger anfällig für die Cache Angriffe sind. Zudem kann AMDs SMT mehr rausholen als Intel (bis zu 80%, aber eher so 20-30%)
Es kommt auf den workload an. Intel kann auch 80% rausholen, wenn genau die duplizierten Register genutzt werden. Da ist kein meilenweiter Unterschied.
Sie nutzen zum Teil auch andere physische Schaltungen für die gleiche Logik, wodurch weniger Platz benötigt wird, aber auch der erreichbare maximale Takt sinkt. Genau deshalb nutzt AMD die auch nur da, wo sie sowieso schon in den Taktraten begrenzt sind (also nicht im Desktop).
Video Encoding. 3 Minuten Video, 20 Minuten warten, wenn man alles auf "best quality H265" stellt, selbst wenn man schon eine aktuelle, schnelle CPU hat.
Jagut... große Firmen haben dafür dedizierte Render Server, als Privatberufler kann man über eine Workstation nachdenken...
Es ist nicht so, als ob es da nicht schon Möglichkeiten gäbe, wenn man einer der wenigen User ist, die tatsächlich einen Usus für massive Parallelität haben.
Video Encoding. 3 Minuten Video, 20 Minuten warten, wenn man alles auf "best quality H265" stellt, selbst wenn man schon eine aktuelle, schnelle CPU hat.
Könnte nicht schaden, wenn es 4x so schnell wäre, spätestens falls irgendwann 6K oder 8K Video reinkommt, aber da limitiert vielleicht eher die Festplatte.
Man wird immer Leute oder Anwendungen finden, die jede noch so potente CPU auslasten können.
Dein Beispiel ist zwar jetzt nicht konstruiert, aber auch fern ab von Mainstream. Wer eine 52-Core-CPU auslasten kann, den kann man schon getrost als Enthusiast bezeichnen, oder als professioneller Anwender.
Nicht falsch verstehen, ich freu mich auch auf mehr Cores, aber 90% der Kunden kommen prima mit 8 Cores und 99% mit 16 Cores aus, und das wird sich auch nicht in den nächsten 5 Jahren wesentlich verschieben.
Schon recht, aber machst du es beruflich? Jemandem der vielleicht 3-4 mal im Jahr ein paar Videos bearbeiten möchte, können die "3-4min" völlig egal sein. Das ist so wie mit der 1Gbit/s Leitung fürs Internet, schön eine zu haben und sich alle paar Monate den neusten Blockbuster in 5 Minuten herunterladen zu können, es würde aber auch niemandem ein Zacken aus der Krone fallen, wenn er 10 Mal so lange benötigt und in der Zwischenzeit was anderes macht.
Ich jage im monatlichen Turnus zu zwei, drei Anime je zwei BDMVs durch Handbrake.
Dies ergebe bei einer Season von 12/13 Episoden in einer Duration von ca. 24 Minuten mal dem, was er dort oben aufgeführt hat, in 1080p auf HEVC unfassbare rund drei Stunden pro Folge.
Ohne NVENC braucht man ans Enkodieren gar nicht erst zu denken: Der Nachteil des VPU-Encodings sind die tendenziell zu großen Dateien.
Und Intels QuickSync, was ich hier auch gelesen habe, kann man sich schenken: Es erfordert nicht nur mehr Zeit, weil eine Intel-iGPU mit einer NVIDIA-GPU nicht ansatzweise konkurrieren kann, es erzeugt zudem noch größere Dateien in der Ausgabe.
Und bei so manchem Anime muss eine Filterung herhalten (z. B. LapSharp), weil die Anime-Industrie schlampig arbeitet, beziehungsweise nur Blinde tätig sind, diese meinen, ein Anime muss durch Unschärfe und Farbrauschen so hässlich aussehen wie auf dem Blatt Papier eines Manga. Dieses weitgehend herauszufiltern beansprucht an die Enkodierung zusätzliche Zeit.
Ergänzung ()
12nebur27 schrieb:
Anime transcodieren doch recht schnell typischerweise?
Auch mit ner CPU ist das nicht sooo schlimm? Preset slow mit ein paar anpassungen je nach anime bei sowohl crf sowie psyrd etc. geht auf ner modernen CPU doch recht zügig. Da finde ich live action Filme deutlich problematischer.
Ist halt Geschwafel ohne Fakten.
Die Performance laut der Folie liegt ja bei 32-45% eines Zen5. Im Vergleich zu den Zen6 dann nochmals weniger.
Zudem wurde hier doch nur IPC und Takt eines einzelnen Kerns ermittelt. Das bedeutet ja nicht lange nicht, dass mehrere Kerne noch vernünftig skalieren. Erst Recht nicht 16. Um das sparsam zu gestalten werden die nicht an einem fetten Ringbus mit viel Cache hängen. Wenn ich 24 fette Zen6 Kerne habe, sind die LP Kerne komplett irrelevant bei Vollast. Genauso wie die 4 LP Kerne bei Intel. Ich würde da gar nicht von 52 Kern CPUs sprechen.
.
