Intel vergleicht 96 Cascade-Lake-AP-Kerne gegen 64 AMD-Zen-Kerne

[empy]

Der Index hier ist nicht der heilige Gral, je nach Gamezusammenstellung etc können die Resultate deutlich schwanken.
Außerdem läuft der Ryzen hier mit langsamem RAM und der schnelle RAM wird nun mal benötigt bei Ryzen um Intel auf die Pelle zu rücken.
Taktbereinigt nehmen die sich nicht so viel. YouTube

Jup, wenn man viele Games spielt, die mich nicht interessieren, allen voran die Synthetic-Benchmark-Collection, die den Top-Hit CineBench beinhaltet, dann ist der Ryzen nah dran.

 

[empy]

Der CISC-Overhead besteht nur noch aus dem Decoder, eröffnet aber auch Möglichkeiten für Low-Level-Optimierungen innerhalb der CPU. Bisherige Hochleistungs-ARM-Prozessoren liegen fertigungsbereinigt gar nicht mal soweit von der x86-Konkurrenz entfernt. Da sind Software-Optimierungen für die jeweilige Architektur auf alle Fälle wichtiger.

Ich würde es halt so sehen: Der Decoder braucht Zeit, das führt zu Latenzen, die widerum bei Abhängigkeiten zu Stalls führen können. Dass ARM eigentlich schon nahe rankäme, würde ich auch so sehen, aber mir waren da noch keine Modelle geläufig. Bin in dem Thema aber auch nicht so drin.

 

[gaussmath]

empy, du bist so CB fixiert, was ist los mit dir? Ist was in der frühbenchlichen Phase schief gelaufen?

 

[Duvar]

Jup, wenn man viele Games spielt, die mich nicht interessieren, allen voran die Synthetic-Benchmark-Collection, die den Top-Hit CineBench beinhaltet, dann ist der Ryzen nah dran.

Hab dir doch extra einen Riesenbenchmark rausgesucht mit 36 Games, reicht dir das nicht? http://extreme.pcgameshardware.de/n...-aber-nur-als-tray-version-8.html#post9593240

empy, du bist so CB fixiert, was ist los mit dir? Ist was in der frühbenchlichen Phase schief gelaufen?

Er hat die CB Allergie, weil Ryzen da gute Ergebnisse liefert, aber wenn man über den Tellerrand hinweg schaut wie zB in den von mir verlinkten Tests, dann sieht man, dass unsere heiligen Ryzens, nicht nur bei CB scheinen.

 

[gaussmath]

Er hat die CB Allergie, weil Ryzen da gute Ergebnisse liefert, aber wenn man über den Tellerrand hinweg schaut wie zB in den von mir verlinkten Tests, dann sieht man, dass unsere heiligen Ryzens, nicht nur bei CB scheinen.

Ja, so ist es. Dabei bin ich davon ausgegangen, dass empy klar ist, dass Threadripper bei Workloads punktet, die sich dadurch auszeichnen, dass sie chache-lastig, stark parallelisierbar und zumeist unabhängige Threads fahren, was zum Beispiel bei diskreten Optimierungsverfahren mit small Data Objective Function der Falle ist, welche multiinstanziell auf großen Lösungsräumen operieren und kontraktiv auf einem Big Valley wirken.

Aber Cinebench ist auch geil!

 

[wolflux]

Ja, so ist es. Dabei bin ich davon ausgegangen, dass empy klar ist, dass Threadripper bei Workloads punktet, die sich dadurch auszeichnen, dass sie chache-lastig, stark parallelisierbar und zumeist unabhängige Threads fahren, was zum Beispiel bei diskreten Optimierungsverfahren mit small Data Objective Function der Falle ist, welche multiinstanziell auf großen Lösungsräumen operieren und kontraktiv auf einem Big Valley wirken.

Aber Cinebench ist auch geil!

Eigentlich suche ich meist Cinebenchwerte, am liebsten Singelcoreleistung.
Geht einfach schnell.

 

[empy]

Ja, so ist es. Dabei bin ich davon ausgegangen, dass empy klar ist, dass Threadripper bei Workloads punktet, die sich dadurch auszeichnen, dass sie chache-lastig, stark parallelisierbar und zumeist unabhängige Threads fahren, was zum Beispiel bei diskreten Optimierungsverfahren mit small Data Objective Function der Falle ist, welche multiinstanziell auf großen Lösungsräumen operieren und kontraktiv auf einem Big Valley wirken.

Jetzt werden hier aber die großen Fachbegriffe ausgepackt. Wenn du jetzt noch im Kontext hättest bleiben können, wäre das schon fast gut gewesen. Blöd wenn die eigene Hochspezialisierung grade nicht zum Thema passt, versuchen kann man es aber ja mal.

 

[gaussmath]

empy, hier ist dein Kontext: mach' dich mal locker und sei nicht so eine Spaßbremse.

 

[Duvar]

Jetzt werden hier aber die großen Fachbegriffe ausgepackt. Wenn du jetzt noch im Kontext hättest bleiben können, wäre das schon fast gut gewesen. Blöd wenn die eigene Hochspezialisierung grade nicht zum Thema passt, versuchen kann man es aber ja mal.

Er meint damit folgendes und zwar, warte mal, dieses Video erklärt es: YouTube

 

[PCGH_Torsten]

Ich würde es halt so sehen: Der Decoder braucht Zeit, das führt zu Latenzen, die widerum bei Abhängigkeiten zu Stalls führen können. Dass ARM eigentlich schon nahe rankäme, würde ich auch so sehen, aber mir waren da noch keine Modelle geläufig. Bin in dem Thema aber auch nicht so drin.

Zu den Cavium Thunder findet man einige Artikel, aber ich kenne mich mit den dort verwendeten Benchmarks nicht gut genug aus, um ein eigenes Urteil zu fällen. Aber es liegen zumindest keine Größenordnungen zwischen den verschiedenen Architekturen.

Problematische Latenzen dürften durch den Decoder meiner Einschätzung nach kaum entstehen, denn letztlich müssen auf allen Plattformen die gleichen Berechnungen durchgeführt werden. Bei ARM steckt der komplexe Teil des Codes halt im Quelltext, bei x86 wird ein Befehl an die CPU gegeben und die kümmert sich um den Rest. Das kostet gegebenenfalls etwas zusätzliche Zeit, aber dafür kann die CPU den gesamten weiteren Ablauf optimal abstimmen. Wenn sich ein Entwickler sehr viel Mühe gibt und hardware-nah optimiert, hat er bei RISC prinzipiell mehr Möglichkeiten – deswegen hat Intel bei Itanium damals sehr viel Organisatinslogik dem Compiler überlassen. Aber wir wissen ja alle, was daraus wurde.

 

[empy]

Zu den Cavium Thunder findet man einige Artikel, aber ich kenne mich mit den dort verwendeten Benchmarks nicht gut genug aus, um ein eigenes Urteil zu fällen. Aber es liegen zumindest keine Größenordnungen zwischen den verschiedenen Architekturen.

Das hätte mich auch gewundert, aber wäre halt schon mal interessant, wie gut ARM dann schlussendlich doch nach oben mitskaliert. Als Energiesparwunder werden sie ja schon lange bezeichnet, allerdings war das damals noch so fernab der Vergleichbarkeit zu den größeren x86-CPUs, dass man sich unweigerlich gefragt hat, wieviel davon wohl noch übrig bleiben würde, wenn man mit ARM ähnliche CPUs bauen würde.

Problematische Latenzen dürften durch den Decoder meiner Einschätzung nach kaum entstehen, denn letztlich müssen auf allen Plattformen die gleichen Berechnungen durchgeführt werden. Bei ARM steckt der komplexe Teil des Codes halt im Quelltext, bei x86 wird ein Befehl an die CPU gegeben und die kümmert sich um den Rest. Das kostet gegebenenfalls etwas zusätzliche Zeit, aber dafür kann die CPU den gesamten weiteren Ablauf optimal abstimmen.

Am Ende werden so oder so dem RISC-Teil irgendwelche Instruktionen um die Ohren gehauen und er schaut dann, welche er jetzt ausführen kann und reiht diese dann ein. Ob die jetzt direkt aus dem RISC-Kompilat (Quellcode ja jetzt nicht) oder per CISC-Kompilat aus dem Microcode kommen, sollte keine riesige Rolle spielen. Auf der anderen Seite ist wieder die Frage, ob die Latenzen durch die Decoderstufe nicht verpuffen, weil an der Stelle eh noch nichts passiert, das großartig Organisation braucht. Die Latenzen spielen ja erst dann wirklich eine Rolle, wenn Entscheidungen davon abhängen.

Wenn sich ein Entwickler sehr viel Mühe gibt und hardware-nah optimiert, hat er bei RISC prinzipiell mehr Möglichkeiten – deswegen hat Intel bei Itanium damals sehr viel Organisatinslogik dem Compiler überlassen. Aber wir wissen ja alle, was daraus wurde.

Naja, EPIC hatte halt das große Problem, dass es im Endeffekt VLIW war und die Parallelität, die die heutigen CPUs dynamisch managen, im Compiler gelöst werden sollte. Ich finde das ist insofern nicht richtig vergleichbar. Von dem Durchsetzungvermögen her kann man jetzt drüber streiten, ob die fehlende Unterstützung für alte Software oder die Mikroarchitektur selbst jetzt mehr Schuld war.