Re(4): AMD und Intel Prozessoren vergleichen

AMD und Intel Prozessoren vergleichen (10 Beiträge, 602 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?

Re: AMD und Intel Prozessoren vergleichen

(Maximus am 26.12.2021, 17:14:31)

Re: AMD und Intel Prozessoren vergleichen

(ein Kritiker am 26.12.2021, 17:46:57)

Re: AMD und Intel Prozessoren vergleichen

(langlaeufer am 27.12.2021, 10:08:48)

Re(2): AMD und Intel Prozessoren vergleichen (scientificallyilliterate am 27.12.2021, 10:30:40)

Re(3): AMD und Intel Prozessoren vergleichen

(langlaeufer am 27.12.2021, 11:26:49)

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.

Re(5): AMD und Intel Prozessoren vergleichen (someonelikeme am 28.12.2021, 23:34:51)

Vom Autor zurückgezogen oder Autor hat seine Registrierung nicht bestätigt (scientificallyilliterate am 29.12.2021, 02:34:03)

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