AMD und Intel Prozessoren vergleichen

AMD und Intel Prozessoren vergleichen (10 Beiträge, 578 Mal gelesen)

Du bist nicht angemeldet. [ Login/Registrieren ]

Hallo,
früher konnte man Prozessoren von AMD UND Intel in einer EINZIGEN Liste vergleichen.

Heute:
Aufruf von Prozessoren: https://geizhals.de/?o=4

Als erstes MUSS ich dann ZWINGEND AMD oder Intel wählen.
Wie soll ich dann AMD und Intel vergleichen?

Ich wähle z.B. als Filter 8 Kerne, da ist es mir im ersten Schritt egal, ob AMD oder Intel.

Warum geht das nicht mehr? Und wenn es doch noch geht, bitte einen Link dazu?

IMHO ging das auf Geizhals nie - man musste immer den Prozessor nach Sockeltyp wählen.

lg
Maximus

My name is Maximus Decimus Meridius, Commander of the Armies of the North,
General of the Felix Legions, loyal servant to the true emperor, Marcus Aurelius.

Dafür kannst du die Vergleichsliste verwenden. Einfach die CPUs die dich interessieren in die Liste schmeißen, und dann die Vergleichsliste öffnen.

Servus noxe68,

früher konnte man Prozessoren von AMD UND Intel in einer EINZIGEN Liste
vergleichen.

du kannst hier den Geizhals-Preisvergleich zu jedem beliebigen vergangenen Zeitpunkt ansehen.
http://web.archive.org/web/*/geizhals.at

Die Prozessoren von AMD und Intel waren immer schon in zwei unterschiedlichen Kategorien gelistet.
Einzelne Kategorien sind für unsere Website wie unterschiedliche Lagerhallen; wenn man in einer Lagerhalle drin ist, hat man die Möglichkeiten, welche es dort gibt - aber man kann nie "gleichzeitig" in dieser Lagerhalle auch die Produkte liegen haben, die in einer anderen Lagerhalle (andere Kategorie) "gelagert" sind.
Daher war es technisch noch nie möglich, dass man die Prozessoren unterschiedlicher Hersteller in einer einzigen Liste anzeigen und (auf diese Art) vergleichen kann.

Die einzige Möglichkeit dies durchzuführen, ist unsere Vergleichsfunktion:
https://geizhals.eu/?cmp=2536507&cmp=2613572

Wir müssen natürlich selbst auch immer wieder mal nachsehen, ob es eine Funktion "wirklich" noch nie gegeben hat - aber das mit den Prozessoren ist definitiv so, wie gerade beschrieben.

Selbst bei "Komplettprodukten" wie z.B. Notebooks, ist es noch nicht so lange Zeit möglich, Geräte mit CPUs von zwei unterschiedlichen Herstellern miteinander in einer Liste anzeigen zu lassen - aber da geht es immerhin:

https://geizhals.eu/?cat=nb&xf=1482_AMD%7E1482_Intel%7E17607_2020.1%7E6748_0.4%7E6748_22%7E6748_23%7E6748_24%7E6763_Ryzen+4000%7E6763_Ryzen+5000%7E6763_zzw

Die Sinnhaftigkeit, die Zahlenwerte von Prozessoren unterschiedlicher Serien (und erst recht von unterschiedlichen Herstellern) direkt zu vergleichen, ist ziemlich rasch erschöpft. Die Anzahl der Kerne, die Kosten pro Kern und vielleicht die maximal mögliche RAM-Unterstützung, können sicher sinnvoll verglichen werden. Sobald es aber um die Leistungsfähigkeit geht, ist eine Gegenüberstellung von Zahlenwerten nutzlos. Man hätte da zwar die Auskunft, welcher Prozessor mehr Threads gleichzeitig bearbeiten kann und wie hoch die maximale Taktfrequenz ist. Man weiß aber nicht, ob der eine Prozessor für eine Operation vielleicht 20 Takte benötigt und der andere nur 15 Takte benötigen würde. Auch kann es sein, dass ein Prozessor eine bestimmte Taktfrequenz überhaupt nicht für alle (gleichartigen) Kerne gleichzeitig zur Verfügung stellt.

Ich will nicht behaupten, dass diese Gegenüberstellung manchmal nicht irgendwie von Interesse sein könnte. Aber, es ist wirklich so: das ging bisher noch nie.

Es ist durchaus möglich, dass wir diese Option mittelfristig anbieten, indem wir die Prozessoren in einer einzelnen Kategorie listen und die Aufteilung dann über die Filter realisieren. Kurzfristig kann das aber nicht angeboten werden. Die technische "Problematik", dass die Werte einzelner Prozessoren nicht sinnvoll miteinander verglichen werden können, weil die vergleichbaren Werte nicht "das gleiche bedeuten", besteht dann aber weiterhin.

Ich danke für das Verständnis und wünsch einen angenehmen Jahresausklang!

LG,

LL

> Die technische "Problematik", dass die Werte einzelner Prozessoren nicht sinnvoll miteinander verglichen werden können, weil die vergleichbaren Werte nicht "das gleiche bedeuten", besteht dann aber weiterhin.

Wenn ihr solche herstellerübergreifenden Vergleichsfilter schon evaluiert, hier ein bisschen Nudging: Performance/Area und Performance/Watt, bitte danke. Die ließen sich immerhin auch mit stupiden und einfach reproduzierbaren Durchsatzbenches anfertigen und (so sinnlos sie für Ottonormalverbraucher auch auf den ersten Blick sein mögen) man könnte damit zumindest die ganzen fanboy dabbler, die sich mit irgendwelchen Essensabfällen von Twitter zufriedengeben, sehr schnell ruhigstellen.

Auch euch einen entspannten Jahresausklang.

Servus,

Wenn ihr solche herstellerübergreifenden Vergleichsfilter schon evaluiert,
hier ein bisschen Nudging: Performance/Area und Performance/Watt, bitte danke.

Also du schlägst vor, dass wir "einfach nur" das, was wir - in Ermangelung geeigneter (über alle möglichen Serien verfügbarer) Daten - nicht vernünftig vergleichbar quantifizieren können, auch noch pro Watt ausgeben sollen.

Und hinsichtlich der Leistung - sollen wir da dann die TDP nehmen - also die quasi offizielle maximale "Heizleistung"? Oder irgend einen anderen "Spitzenwert", für welchen nicht genau bekanntgegeben wird, was ein- und zutreffen muss, dass er erreicht wird, und/oder ob er überhaupt wirklich ein Limit darstellt oder vielleicht nur ein durchschnittliches Maximum repräsentiert?

Bitte verzeih mir meinen Sarkasmus. Dein Vorschlag ist schön, nachvollziehbar und wurde von uns schon unzählige Male (aus diversen Perspektiven) in Angriff genommen, aber er lässt sich nicht vernünftig realisieren.
Ich recherchiere z.B. seit gut fünf Jahren Daten, hinsichtlich der Rechenleistung pro Takt und Kern (DMIPS/INT/FPxx) für diverse RISC-Architekturen und habe noch nicht mal zu allen ARM-Architekturen zuverlässige/reproduzierbare Werte ermitteln können.
Bei CISC-Prozessoren, ist dieses Unterfangen noch illusorischer (vgl. auch https://forum.geizhals.at/t903242,8093594.html#8093594 ).

Oder mit anderen Worten:
https://www.youtube.com/watch?v=hoZervGXQyI&t=173s

(...) einen entspannten Jahresausklang.

Dir auch!

LG,

LL

Also du schlägst vor, dass wir "einfach nur" das, was wir - in Ermangelung geeigneter (über alle möglichen Serien verfügbarer) Daten - nicht vernünftig vergleichbar quantifizieren können, auch noch pro Watt ausgeben sollen.

Ich hatte bereits beim Verfassen die Befürchtung, dass es (trotz Smiley) nicht unbedingt so ankommt wie es eigentlich ankommen sollte, aber der Beitrag war nicht ganz ernst gemeint, sondern schlug eher in die Kerbe "Feuer mit Feuer bekämpfen" - sinnlosen Benchmarketeerdünnpfiff mit ebenso sinnlosem Gebenche durch den Kakao ziehen.

Ein mit mir in keiner Art und Weise verwandtes oder verschwägertes Ex-Individuum (

) hier im Forum hat btw vor längerer Zeit sehr weise Worte geschrieben, als es um den Vorschlag eines "Performance/Geld"-Scores für GH selber ging - der Aufwand ist euch nicht zumutbar und wer für seine Workloads relevante Vergleiche anstellen möchte, der muss dies halt selbst tun.

Und hinsichtlich der Leistung - sollen wir da dann die TDP nehmen - also die quasi offizielle maximale "Heizleistung"? Oder irgend einen anderen "Spitzenwert", für welchen nicht genau bekanntgegeben wird, was ein- und zutreffen muss, dass er erreicht wird, und/oder ob er überhaupt wirklich ein Limit darstellt oder vielleicht nur ein durchschnittliches Maximum repräsentiert?

*im CEA Guide blätter und räusper* Ähem...aaalso...ne. Für Workloads mit fixem Input sowieso nicht, aber grundsätzlich misst man sowas direkt am EPS-Stecker und ermittelt dabei die durchschnittliche Leistungsaufnahme, integriert diese dann über die Zeit und gibt die drei ermittelten Größen an. Fertig. Das Rundherum (PL4 oder irgendwelche anderen Transienten, die als "Maximum" nur dann als Artefakte aufplöppen, wenn man mit sehr hoher Frequenz sampled) sind erstmal für Ottonormalverbraucher uninteressant - das sind Dinge um die sich PDN-Designer kümmern können und die allerhöchstens dann relevant werden, wenn der Saugkreis so wenig puffert, dass die OCP im Netzteil w.o. gibt.

Sollte ein Hersteller der Meinung sein, dass er aufgrund von ~~technischer Unterlegenheit~~ "Marktbedürfnissen" mit der Brechstange opportunistisch an die Grenze dessen gehen muss, für das man das Silizium noch (technisch sinnvoll) binnen kann, dann wird dies auch ohne Angabe einer ausschließlich in corner cases erreichbaren "maximalen Heizleistung" für Workloads (Blender/C4D, also alle leicht parallelisierbaren Renderer mit Praxisrelevanz) sichtbar, bei denen die ALUs nicht unbedingt aufgrund von Locks, Cache misses, $XSnp requests und/oder anderem Threadsynchronisierungsbrimborium (was für ein Wort!) mal kurz "ein Snickers essen" können.

Ich recherchiere z.B. seit gut fünf Jahren Daten, hinsichtlich der Rechenleistung pro Takt und Kern (DMIPS/INT/FPxx) für diverse RISC-Architekturen und habe noch nicht mal zu allen ARM-Architekturen zuverlässige/reproduzierbare Werte ermitteln können.

Taktnormalisierte Leistungsangaben sind in der häufig von Herstellern angegebenen "Kurzfassung" ein reines Gimmick (da ein moving target). Entweder misst man aus akademischem Interesse heraus - da dann allerdings mit dem vollen Programm (BPU MPKI, Anzahl aller verschwendeten Zyklen im Front-End und Back-End und die Gründe für Stalls,...), an unterschiedlichen Frequenzpunkten und Ratios (sowohl Core als auch Uncore) und baut darauf basierend dann eine Liste von (möglichen) Engpässen, oder du kannst den ganzen Dreck in den Kübel schmeißen.

Nachdem du bspw. bereits bei RKL oder ADL keine einheitlichen Betriebsparameter für den Uncore über alle SKUs hinweg hast (und ARM SoCs noch viel heftiger divergieren, siehe Samsung und ihre Liebe für Pre-Release SystemVerilog Zeug und single-ported caches), läuft's natürlich dann darauf hinaus, dass die Taktnormalisierungsexperimente schnell für den Hugo sind - das haben übrigens renommierte Reviewer bereits erkannt, denn die bauen mittlerweile fast ausschließlich auf oben beschriebenen Ansatz (soweit sinnvoll möglich).

Die Daten von AnandTech sind zwar teilweise etwas abenteuerlich (die Werte für ICL im TGL-Review decken sich bspw. nicht mit dem ursprünglichen ICL-Review, wurden allerdings im Bench-Archiv gefixt), aber liegen im Rahmen dessen was man erwarten kann wenn man die Plattform mit JEDEC Specs betreibt und sind auch reproduzierbar (so man denn Zugriff auf eine SPEC harness hat, leichter zu ermittelnde/vergleichende Benches decken sich mit anderen Reviews).

Bei CISC-Prozessoren, ist dieses Unterfangen noch illusorischer

?????

Das einzig wirklich relevante (weil was Exceptions und Kosten angeht nicht trivial handhabbare) CISC-Überbleibsel welches in x86 steckt sind die bescheuerten Mod r/m Verrenkungen im Vektorreich (also Käse wie bspw. VADDPS ?mm, ?mm, ?mmptr), die aber heutzutage von jeder x86-CPU in (logisch zu RISC) äquivalente Loads/Stores transformiert werden (beim Hazarding gibt's dann halt noch ein paar Baustellen extra, aber das kann dir als Bencher wurscht sein). Selbst der REP-Schmu wird von beiden ISAs intern mehr oder weniger äquivalent behandelt (ARM CPUs müssen dafür halt Code auf test/decrement Schleifen überprüfen und eliminieren repetitive Fetches dann durch ein GPR + FReg).

Erstere kriegst du nur dann in deinen Code rein, wenn du wirklich willst oder wenn die LLVM Autovektorisierung die Kosten für ebenjene Instruktionen als ETWAS zu gering einschätzt (GCC schlägt sich hier besser) und letztere kostet nichts und scheint auch in den Performance countern (issued/retired ops) auf, zumal sich an der grundsätzlichen Quantifizierung der Performance dadurch nicht viel ändert: Was hinten rauskommt (Durchsatz/Zeit) und wie viel ich investieren (Energie) darf zählt, alles andere sind nette Beigaben oder Memes, die ich mir zur persönlichen Belustigung reinziehen kann - meistens natürlich dann, wenn Intel gerade mal ein neues Produkt mit zwei Jahren Verspätung auf den Markt klatscht.

Thank you for coming to my TED talk.

Ich hatte bereits beim Verfassen die Befürchtung, dass es (trotz Smiley) nicht
unbedingt so ankommt wie es eigentlich ankommen sollte

Doch, kam es. War auch schon kurz davor, einen erläuternden Beitrag zu verfassen, aber da Du mir den Talk schon abgenommen hast, hier noch kurz meine 5 Cent (also inflationsbereinigte 2) zur BoF-Session.

grundsätzlich misst man
sowas direkt am EPS-Stecker und ermittelt dabei die durchschnittliche
Leistungsaufnahme, integriert diese dann über die Zeit und gibt die drei
ermittelten Größen an.

Für eine gegebene Referenzumgebung. Sonst hast Du selbst bei vorgegebener Softwarelast schon auf Hardwareseite wunderbare Unwägbarkeiten in der Gleichung. Offensichtliche (wie effizient arbeitet die Spannungswandlung) und weniger offensichtliche (wie schnell schafft der Speicher die Daten ran - denn auch das trägt ja dazu bei, wie oft die CPU sich ein Snickers gönnen kann).

Workloads (Blender/C4D, also alle leicht parallelisierbaren Renderer mit
Praxisrelevanz)

So ein Zufall, grad die Tage mal wieder ein paar Blender installiert, um einen anderswo in einem Forum abgeworfenen Benchmarkwert für einen Einfachstlaptop in Relation zu meinen Systemen zu setzen (den aktuellen wie den gut abgehangenen). Auf meinem 5700G kommt der selbst bei der eher handlichen BMW-Szene vielleicht auf eine IPC von 1.3 in der Spitze (pro Hyperthread, aber trotzdem) und pendelt bei komplexeren Sachen eher um etwa 1. Von den eigentlich 4.6 GHz Singlecore-Turbo bleiben so immerhin noch 4.3 für Allcore übrig.

Die 65W TDP werden dabei mit gut 70 bis knapp 75W nur geringfügig überschritten. Obwohl ich mir nicht ganz sicher bin, wieso turbostat dabei zeitweise CorWatt über PkgWatt auswirft, ich genieße die Werte daher mit einem Körnchen Salz.

Wenn ich andererseits die Kerne wirklich zu fordern versuche, z.B. mit dem Torturetest von Prime95 (Small/Smallest FFT, damit der Speicher nicht bremst), dann geht zwar die IPC über 1,8, dafür bricht der Allcore-Turbo sogar unter die eigentliche Nominalfrequenz von 3,8 ein. Aber PkgWatt pendelt plötzlich nur noch zwischen 50 und 60. (Ich würd jetzt ja gern noch auf die Temperatur schauen, aber der Temperature-Sensor-Support für Cezanne hatte auch den aktuellen Kernel nochmal knapp verpasst und kommt wohl erst im nächsten).

Mod r/m Verrenkungen im Vektorreich (also Käse wie bspw. VADDPS ?mm, ?mm,
?mmptr), die aber heutzutage von jeder x86-CPU in (logisch zu RISC)
äquivalente Loads/Stores transformiert werden

Stores? Also Memory-Parameter sind ja auch in Vektorcode durchaus mal sinnvoll (auch wenn sie vielleicht nicht mehr ganz so nötig sind wie zu seligen MMX-Zeiten), aber als Destination eines Nicht-Store-Befehls sind sie mir dann doch noch nicht untergekommen. Von den echten CISC-Altlasten wie Read-Modify-Write in GPR-Code will ich mal gar nicht anfangen - aber ich beschwere mich keineswegs darüber, im Gegenteil, auch das lässt sich mitunter durchaus performancefördernd (und nicht bloß für kompakteren Code) einsetzen.

Was hinten rauskommt (Durchsatz/Zeit) und wie viel ich investieren (Energie)
darf zählt,

Der Sweetspot für Performance pro Watt ist sicherlich prozessabhängig, dürfte aber unabhängig davon ohnehin weit von dem Leistungsbereich entfernt liegen, den man sich in einem Desktop heutzutage so vorstellt. Wenns wirklich schnell gehen soll, muss man halt (viel) mehr Energie reinschaufeln, und gemeinerweise ist der Zusammenhang da ja auch alles andere als linear, schon lange bevor die Leistungsfähigkeit des Kühlsystems zu bremsen beginnt.

Aber immerhin gibts heute MCUs, die schon mit wenigen µA/MHz ein vielfaches der Rechenleistung des ursprünglichen PCs abliefern können.

Thank you for coming to my TED talk.

Aber immer gerne.

28.12.2021, 23:38 Uhr - Editiert von someonelikeme, alte Version: hier

Dieses Forum ist eine frei zugängliche Diskussionsplattform.
Der Betreiber übernimmt keine Verantwortung für den Inhalt der Beiträge und behält sich das Recht vor, Beiträge mit rechtswidrigem oder anstößigem Inhalt zu löschen.
Datenschutzerklärung