Bringen neue CPUs auch mehr Leistung? [Archiv]

Screemer

2020-08-11, 13:10:38

Ja ok. Ok. Vergessen.
Redesigns um mit der Entwicklung der Herstellungsprozesse mitzuhalten sollte man natürlich nicht unterschlagen...

edit:
Wenn irgendeiner der sonst PR-Reviewer wirklich EINMAL die Eier hätte, hätte er einen 3770k auch mal fairerweise auf 4.3 gedreht (was ja jetzt nicht eine besondere Leistung wäre) und es gegen den 3300x stock vergliechen. (auch fairerweise ohne AVX2).

Von mir aus den einen mit FlareX 3200/14 1.35V und den anderen mit Ballistix Elite und allem was bei 1.568V und ~0.943V Vccsa geht (macht in etwa 1956 mit 9-9-9-18-1 und sehr passablen Subs)

Könnte man wenigstens einmal sehen was die letzten ~7.5 Jahre x86 Entwicklung und ~3.8 Milliarden Transistoren gegen ~1.4 Milliarden Transistoren hervorgebracht haben.
genau man schaltet am besten alle instruktionsets und sonstige achivements die sich aus den zusätzlichen transitoren ergeben ab um einen fairen vergleich zu haben. wo glaubst du kommt der fortschritt her? ;D

Badesalz

2020-08-11, 13:21:24

genau man schaltet am besten alle instruktionsets und sonstige achivements abNein, davon war nicht die Rede. Wenn du maßlose Übertreibungen als rhetorischen Stilmittel benötigst bin ich wohl auf dem richtigen Pfad :up:
Zähle sonst einfach alle gebräuchlichen Programme auf, die gesichert AVX2 nutzen. Ich selbst hätte von meinen schwergewichtigeren Anwendungen außer dem Recoder leider sonst noch nichts im Petto.
Was von der Auflistung hast du selbst am laufen?

Damit du aber nicht gleich komplett zusammenklappst könnte man auch den 4790k nehmen. Der kann AVX2 und dann wären es halt ~5.5 Jahre x86 Entwicklung.

edit:
LOL. Ja genau. Der Fortschritt kommt von immer weiter ausgearteter Erweiterung der x86 ISA. Super. Nutzt dann nur kaum eine Sau, weil man Programme machen will welche von den allermeisten auch genutzt werden. Da achtet leider keiner auf Forenblasen.

y33H@

2020-08-11, 14:04:43

Badesalz

2020-08-11, 14:36:51

Ich kann dir zumindest einen 7700K stock anbieten, hat halt mehr IPC weil Skylake:Ja... aber das ist für einen nennenswert langen Zeitabschnitt nicht mehr ganz fair ;)
Es freut mich aber, daß deine Begeisterung für den 3300x, einer mittlerweile nicht mehr erhältlichen CPU (?) ähnlich meiner war :up:

Vom Takt her, wegen recht leichten Normierung auf 4.3Ghz - auch wenn unbedarfte Laien dazu "getunded bis zu geht nicht mehr" sagen - passen 3300x und 3770k wunderbar zusammen. Und natürlich fair, wenn man die Schwerpunkte auf RAM-Durchsatz und AVX(2) setzt

Und ~7.5 Jahre dazwischen wären eben schon ein beachtlicher und akzeptabler Zeitrahmen.

edit:
Mein alter Kumpel direkt in die gleiche Kerbe :wink:
https://www.phoronix.com/scan.php?page=news_item&px=Linus-Torvalds-On-AVX-512

Lehdro

2020-08-11, 14:51:44

Wenn irgendeiner der sonst PR-Reviewer wirklich EINMAL die Eier hätte, hätte er einen 3770k auch mal fairerweise auf 4.3 gedreht (was ja jetzt nicht eine besondere Leistung wäre) und es gegen den 3300x stock vergliechen. (auch fairerweise ohne AVX2).
Arbeite bitte mal an deinem Ton, ist ja grauselig. Hat schon fast etwas von einem Aluhutträger.

Aber hier ein paar Links extra nur für dich, ist wahnsinnig schwer google zu bedienen:
2600k @ 4.7 + DDR3 2400 vs 7700K/9700K Stock (https://www.anandtech.com/show/14043/upgrading-from-an-intel-core-i7-2600k-testing-sandy-bridge-in-2019/21)
3770K @ 4.5 + DDR3 2400 vs 4790K/7700K taktnormiert (https://www.youtube.com/watch?v=XHUfSIdyIfw)
2500K @ 4.6 GHz + DDR3 2133 / 3770K @ 4.5 GHz + DDR 3 2400 vs i5 6500 Stock (https://www.eurogamer.net/articles/digitalfoundry-2016-is-it-finally-time-to-upgrade-your-core-i5-2500k)
2600K @ 4.7 + DDR3 2133 vs 2018er Aufgebot (https://www.gamersnexus.net/hwreviews/3412-intel-i7-2600k-revisit-2018-benchmarks-vs-9900k-ryzen-more)
PCGH hatte, wenn ich mich recht erinnere, in einem der Hefte auch einen CPU Rückblick, bin aber gerade nicht zuhause um das rauszusuchen. Material von journalistischer Seite gibt es auf jeden Fall genug, nur für die Quervergleiche muss man dann selber Hand anlegen, was jetzt aber kein großer Aufwand ist.

Wie man dort überall sieht gibt es durchaus, trotz der eher mageren IPC Zugewinne von Intel in dem Zeitraum, durchaus einiges an Mehrperformance zu holen, selbst wenn man OC vs non OC vergleicht. Meist ist selbst bei Games schon ein Haswell Vierkerner mit HT schneller, also in Applikationen die eher nicht von neuen Instruktionen profitieren. Und wenn wir jetzt den Fakt nehmen das ein 3300X meist minimal über einem 7700K performed, so wissen wir, dass die Performancedifferenz zwischen deinem handzahmen 3770K @ 4.2 GHz und einem modernen low Budget 3300X viel größer ist, als du vielleicht annimmst. Du gehst sicherlich auch eher von den großen Leistungssprüngen der späten 1990er und frühen 2000er aus und blendest aber aus, dass sich dort im Taktrennen die Werte um ein Vielfaches gesteigert haben (~500 Mhz ->~3 GHz). Richtig massiv große IPC Sprünge gab es aber auch damals eher selten (Athlon, Conroe...), vielmehr war die allgemeine Entwicklungsfolge viel schneller (meist sub 12 Monate). Aber durch AMD erlebt diese Schnelllebigkeit des Marktes ja seit 2017 mittlerweile Gott sei dank eine Widergeburt, es geht wieder Schlag auf Schlag.

Gipsel

2020-08-11, 14:57:47

Mein alter Kumpel direkt in die gleiche Kerbe :wink:
https://www.phoronix.com/scan.php?page=news_item&px=Linus-Torvalds-On-AVX-512Nein, tut er nicht. Oder ist Dir etwa nicht aufgefallen, daß dort von AVX512 die Rede ist, was AMD gerade nicht unterstützt?

Badesalz

2020-08-11, 15:47:18

Nein, tut er nicht. Oder ist Dir etwa nicht aufgefallen, daß dort von AVX512 die Rede ist, was AMD gerade nicht unterstützt?Du musst den Text in Ruhe auch komplett lesen und nicht nur die Überschrift...

@Lehdro
Wie man erst in den Wald ruft, ist mal wieder außerhalb des Ereignishorizonts? ;)
Ja schau ich mir nachher an. Danke dir.

edit:
Nett, aber passt nicht so wirklich. Wenns sowas schon gäbe, was ich da meine, wüsste ich davon. Das mit dem 7700k passt aber brauchbar.

Gipsel

2020-08-11, 15:50:54

Du musst den Text in Ruhe auch komplett lesen und nicht nur die Überschrift...Keine Sorge, habe ich (schon bevor Du es hier verlinkt hast). Ändert nichts daran, daß Du da kein vernünftiges Argument hast.

Badesalz

2020-08-11, 15:54:51

Nein du findest den Bezug/Kontext zum Thema nicht. Wir reden über die Entwicklung und Weiterentwicklung von x86.

"I've said this before, and I'll say it again: in the heyday of x86, when Intel was laughing all the way to the bank and killing all their competition, absolutely everybody else did better than Intel on FP loads. Intel's FP performance sucked (relatively speaking), and it matter not one iota.

Because absolutely nobody cares outside of benchmarks."

"Stop with the special-case garbage, and make all the core common stuff that everybody cares about run as well as you humanly can. Then do a FPU that is barely good enough on the side, and people will be happy."

usw. Einfach nur lesen...

Dino-Fossil

2020-08-11, 16:00:24

@Badesalz:
Jedenfalls ist mal nicht klar warum du/ihr damit den Ryzen 4000 mobile Thread zuspammst.

Mach doch einfach ein neues Thema auf in dem ausführlich diskutieren werden kann, ob & warum x86 zu wenig Fortschritt zeigt und deswegen (deiner Meinung nach) ein alter 3770K mit leichtem OC immer noch mit modernen CPUs den Boden aufwischt.

Badesalz

2020-08-11, 16:46:10

und deswegen (deiner Meinung nach) ein alter 3770K mit leichtem OC immer noch mit modernen CPUs den Boden aufwischt.Wenn nicht jeder dieser Specialists hier gleich soviel rumfantasieren würde wie du grad, wäre das Teilthema schon vor 2 Seiten durch. Als Teil des Problems, kritisierst du das Problem. Ist klar =)

Das Thema hat sich aber soweit auch wirklich erschöpft. Man könnte nun beruhigt wieder zum Tagesgschäft übergehen. Wenns denn genehm ist.
Sich einfach nicht selbst zum Teil des Problems machen, dann läufts :wink:

Bin raus.

edit@Th3o
https://www.stupidedia.org/stupi/Aufgebrachter_Mob_mit_Mistgabeln_und_Fackeln

Th3o

2020-08-11, 16:46:35

Ist nicht der 1. Thread, den er damit zuspammt.

Badesalz

2020-08-11, 17:12:12

Bezüglich der gewohnten, da ewig gleichen, Benchmarks in PR-Reviews, die man sich dann in den Foren jubelnd gegenseitig hinwirft, liefern fefe/Lobo übrigens grad eine interessanten Gedanken für solches Verhalten...

https://blog.fefe.de/?ts=a1ccb2be

Gipsel

2020-08-11, 17:23:09

Ein Zen2 rennt Kreise um die ollen Sandybridges. Beim ursprünglichen Beispiel vom Encoding ist ein 4800U mit 15W ja schon mal grob doppelt so schnell wie so'n 2600K auf 95W. Leistung Faktor zwei bei 84% weniger Leistungsaufnahme (real vielleicht ein bißchen weniger, die alten CPUs waren ja schlechter, dabei die TDP auszunutzen [war ja auch ein Punkt von Torvalds, da gibt es also durchaus Fortschritte]) ergibt bei mir so gut Faktor 12 bessere Performance pro Watt (da Badesalz ja hochgezogene alte CPUs betrachten wollte).

Fun Fact am Rande:
Bei dem Beispiel nutzt AVX vielleicht sogar mal was und Torvalds steht mit seiner Inselmeinung bezüglich der Nebensächlichkeit der FPU (bzw. der dort verbauten Vektorerweiterungen) ein wenig bedröppelt da. Er hat ja einen Punkt, daß man es nicht übertreiben sollte. Aber eine gute Balance ist eben was Anderes, als reine Integerleistung anzubieten. Bei der war AMD auch schon zu Zeiten vom K6 konkurrenzfähig. Der Durchbruch kam aber erst, als man aber nicht nur Integrleistung hatte, sondern mit dem K7 auch bei der FPU wegzog. Weil die Leute haben es eben doch an der Performance gemerkt. Nicht Alle kompilieren wie Linus den lieben langen Tag Linux rauf und runter (und da schlägt AMD momentan z.B. mit einem Threadripper Alles, was man von intel kaufen kann [inklusive Dual Xeon Systeme]). Hatte Linus nicht vor kurzem von Intel auf ein Threadripper-System gewechselt und war von der Performance begeistert (https://www.heise.de/news/Von-Intel-zu-AMD-Linux-Chefentwickler-Linus-Torvalds-wechselt-nach-15-Jahren-4764230.html)? Hat AMD also vielleicht doch einen recht gut balancierten Ansatz gefunden? :wink:

Und wie hier schon mit verlinkten Benchmarks gezeigt wurde, hat auch intel über die Jahre merklich zugelegt. IPC kam was drauf, es gibt mehr Takt und mehr Kerne gibt es inzwischen auch, so daß für den Querschnitt der möglichen Anwendungsfälle dann doch recht beträchtlich was zusammengekommen ist.

Edit @letzter Post von Badesalz:
:confused: Was soll denn der Schrott jetzt?

y33H@

2020-08-11, 17:37:29

Der Zuwachs von Sandy über Ivy zu Haswell und Broadwell bis hin zu Skylake ist gar nicht so ohne.

Der_Korken

2020-08-11, 17:41:39

Ich meinte die Entwicklung von x86. Nicht die Entwicklung bei TSMC :wink:
(einfach nur kurz nachdenken...)

Du gehst sicherlich auch eher von den großen Leistungssprüngen der späten 1990er und frühen 2000er aus und blendest aber aus, dass sich dort im Taktrennen die Werte um ein Vielfaches gesteigert haben (~500 Mhz ->~3 GHz). Richtig massiv große IPC Sprünge gab es aber auch damals eher selten (Athlon, Conroe...), vielmehr war die allgemeine Entwicklungsfolge viel schneller (meist sub 12 Monate).

Das ist ein guter Punkt. Du (Badesalz) wirfst Intel und AMD vor, dass ihr Fortschritt hauptsächlich auf den Fertigungsfortschritten basieren und deren Architekturen eigentlich kaum besser geworden sind über die Jahre. Aber war das dann jemals anders gewesen? Auf welcher Grundlage ist damals das Ghz-Rennen gelaufen oder das Aufkommen von Dual- und Quadcores? Alles nur Fertigung, in Wirklichkeit würden die x86-Bauer heute noch mit 1Ghz Singlecores rumeiern ...

Klar ist die Fertigung wesentlich, aber irgendeiner muss auch die Desings bauen, die diese Fertigung ausreizen und Leistung draus generieren. Einfach ein altes Design zu nehmen und zu sagen, das wird ohne Zutun um Faktor 2 hoch (Anzahl Fertigungssprünge inder Zwischenzeit) schneller, ist eine krasse Fehlannahme.

Dass die Singlethread-Leistung nur schleppend besser wird, liegt nicht daran, dass die Hersteller zu blöd sind und weil sie Leute wie dich triggern wollen, sondern weil sie sich da am Rande von physikalischen Gesetzmäßigkeiten bewegen. Genauso wie du niemals einen Verbrennungsmotor mit 90% Effizienz wirst bauen können, wirst du in den nächsten 10 Jahren mit sehr großer Wahrscheinlichkeit keine CPU finden, deren Kerne doppelt so schnell wie dein 4,3Ghz Ivy Bridge sind. Möglich ist es vielleicht, aber keiner will einen solchen Ultrakern haben, der zwar singlethread super schnell ist, aber dafür 100W+ verbraucht und multithreaded gegen jeden 15W Renoir haushoch verliert.

=Floi=

2020-08-11, 18:13:07

edit:
Wenn irgendeiner der sonst PR-Reviewer wirklich EINMAL die Eier hätte, hätte er einen 3770k auch mal fairerweise auf 4.3 gedreht

Das hat gamernexxus gemacht.
https://www.gamersnexus.net/hwreviews/3412-intel-i7-2600k-revisit-2018-benchmarks-vs-9900k-ryzen-more
gibt es auch als video
https://www.youtube.com/watch?v=KPWEdbfJ0oE
von 05/20
wird dir aber wieder nicht passen.

Dein problem ist, dass du die cores einzel siehst und nicht den ganzen verbund. Sobald multicore wirklich benötigt wird, brechen die alten kisten ein.
Die ganzen jahre der entwicklung bei intel gingen (leider) in die energieeffizienz und in die core größe. Der desktop profitiert davon nur bedingt.

Nebenbei würde intel heute cpus, welche sich um 1ghz übertakten lassen einen riegel vorschieben oder irgendwie beschneiden.

Opprobrium

2020-08-11, 18:36:42

Verstehe den Sinn nicht so ganz von solchen Beiträgen... Gehts hier nur darum die großartige Leistung von AMD klein zu reden oder zu relativieren?

Eigentlich bestätigt seine vermeintlich verneinende Antwort Deine Vermutung:

AMDs "großartige Leistung" ist außer einem um 2018 rum endlich zu Intel allgemein vergleichbar effizientem x86 Design - Gründung von Intel 1968, von AMD 1969...

Denn trotz seines überheblichen "das ist hier ein Technikforum" "Totschlagargumentation"...

Da dein Problem also eher einer nicht technischen Natur ist solltest du dich auch nicht weiter verrenken in deine Rhetorik etwas technisches einzubauen. Es ist eben 3DC. Da interessiert man sich gelegentlich für mehr als Frametimes. Wolltest du dich grad vielleicht bei PCGH einloggen?

...übersieht er hier, bzw. überspielt er hier mit seiner Rhetorik, ganz geflissentlich, daß AMD mitnichten bis 2018 gebraucht hat um zu Intel aufzuschließen, gab es da ja durchaus füher schon Zeiten, in denen AMD Intel überlegen war. Genauso wird es in Zukunft ziemlich sicher auch wieder Zeiten geben, in denen Intel AMD überlegen sein wird ;)

______________________________________

Zum Thema: Auch abseits von Fertigung und extra Instruktinen gab es durchaus Fortschritte, auch wenn tatsächlich mehr Augenmerk auf die Effizienz gelegt wurde. Der geringe Verbrauch heutzutage hat aber nicht nur mit den kleineren Fertigungsprozessen zu tun, sondern auch damit, daß die CPUs viel intelligenter und schneller ihren Takt anpassen können. Auch sind die CPUs heutzutage fast immer SoCs, viele haben eine GPU integriert etc.

Desweiteren sehe ich einen nicht unerheblichen Anteil daran, daß die Leistung kaum zu steigen scheint, darin, daß die Softwareprogrammierer oftmals einfach faul sind und aufgrund der im Überfluß vorhandenen Leistung auch kaum mehr optimieren :D

Gipsel

2020-08-11, 18:49:01

Desweiteren sehe ich einen nicht unerheblichen Anteil daran, daß die Leistung kaum zu steigen scheint, darin, daß die Softwareprogrammierer oftmals einfach faul sind und aufgrund der im Überfluß vorhandenen Leistung auch kaum mehr optimieren :DWas oft nicht unbedingt mit Faulheit zu erklären sein dürfte, sondern auch dadurch, daß Software heutzutage deutlich komplexer geworden ist, als sie es vor 20 Jahren noch war.

Opprobrium

2020-08-11, 18:50:28

Was oft nicht unbedingt mit Faulheit zu erklären sein dürfte, sondern auch dadurch, daß Software heutzutage deutlich komplexer geworden ist, als sie es vor 20 Jahren noch war.
Weil komplexes, überladenes Rumgefrickel immer einfacher ist, als simple, elegante und effektive Lösungen ;)

Zossel

2020-08-11, 18:52:56

Desweiteren sehe ich einen nicht unerheblichen Anteil daran, daß die Leistung kaum zu steigen scheint, darin, daß die Softwareprogrammierer oftmals einfach faul sind und aufgrund der im Überfluß vorhandenen Leistung auch kaum mehr optimieren :D

Optimieren ist sehr zeitintensiv und fehleranfällig.

Badesalz

2020-08-11, 18:55:34

Das hat gamernexxus gemacht.Da ist kein 3770k bei oder?

Sobald multicore wirklich benötigt wird, brechen die alten kisten ein.Klar. Das gilt. Das fing aber eben auch mit der Diskussion über die Parallelisierung und daß core-flood leider nicht den allgemeinen Heil bringt
(man erinnert sich)

Die ganzen jahre der entwicklung bei intel gingen (leider) in die energieeffizienz und in die core größe. Der desktop profitiert davon nur bedingt.Wenn man genauer hinschaut hat man in der neueren Zeit noch viel stärker als früher, nur Abfälle der CPU-Entwicklung für Server.

@Opprobrium
Keine Bange. Ich war auf dich wie immer vorbereitet Deswegen stand da, ohne daß ich mich like-you im Beitrag mit der Person selbst beschäftigen musste - "allgemein vergleichbar effizientem x86 Design".

So ist das übrigens zu 100% auch heute noch nicht (sehe Idle-Werte bei Desktops)…
Aber egal. Erzähl mal einen vom Pferd. Macht nichts.

Zossel

2020-08-11, 18:56:39

Weil komplexes, überladenes Rumgefrickel immer einfacher ist, als simple, elegante und effektive Lösungen ;)

Wer würde heute noch eine Bildbearbeitung nutzen wollen die maximal 2048*2048 Pixel bearbeiten kann?

Baalzamon

2020-08-11, 18:59:25

Weil komplexes, überladenes Rumgefrickel immer einfacher ist, als simple, elegante und effektive Lösungen ;)

Meiner Erfahrung nach sind effektive Lösungen oft schwer zu lesen, verstehen und zu erweitern. Simple und elegante Lösungen sind zwar leichter zu verstehen und evtl. besser erweiterbar, aber selten Effektiv. ;)

Kein Programmierer (den ich kenne) tut sich freiwillig komplexes Gefrickel an. Die Gründe für schlechten Code sind Vielfältig, aber ich gehe da mit Gipsel und wage zu behaupten, dass gerade Faulheit nun nicht der Ausschlag gebende Faktor ist, sonder Zeit. ;)

Opprobrium

2020-08-11, 19:02:53

@Opprobrium
Keine Bange. Ich war auf dich wie immer vorbereitet Deswegen stand da, ohne daß ich mich like-you im Beitrag mit der Person selbst beschäftigen musste - "allgemein vergleichbar effizientem x86 Design".

So ist das übrigens zu 100% auch heute noch nicht (sehe Idle-Werte bei Desktops)…
Aber egal. Erzähl mal einen vom Pferd. Macht nichts.
Stimmt, Pentium 4 und Athlon XP (geschweige denn Athlon 64) waren tastächlich nicht vergleichbar effizient :wink:

Kein Programmierer (den ich kenne) tut sich freiwillig komplexes Gefrickel an. Die Gründe für schlechten Code sind Vielfältig, aber ich gehe da mit Gipsel und wage zu behaupten, dass gerade Faulheit nun nicht der Ausschlag gebende Faktor ist, sonder Zeit. ;)

Na gut, sagen wir durch Zeitdruck induzierte Schlampigkeit :smile:

Badesalz

2020-08-11, 19:47:36

Zum Thema:Ah sowas machst du auch? =)

Auch abseits von Fertigung und extra Instruktinen gab es durchaus Fortschritte, auch wenn tatsächlich mehr Augenmerk auf die Effizienz gelegt wurdeDie Fortschritte in der Effizienz ergeben sich quasi automatisch durch die Prozesse. Es gibt da keinen besonderen Augenmerk von Intel/AMD für den Desktop. Das fällt mal für Mal vom Himmel. Man muss eben nur entsprechend dem Prozess designen. Also, seine basic Hausaufgaben machen.

Sauberer ordentlicher Kode, der nicht optimiert ist - also wo nur der Compiler mal drübergeschaut hat - hat nichts mit Schlampigkeit zu tun.Das Wasser mit dem du hier kochst ist echt kristallklar...

Opprobrium

2020-08-11, 19:53:09

Ah sowas machst du auch? =)

Die fortschritte in der Effizienz ergeben sich quasi automatisch durch die Prozesse. Es gibt da keinen besonderen Augenmerk von Intel/AMD für den Desktop.

Bisweilen ;)

Da aber Desktop/Mobile CPUs meist identisch sind profitieren die Intel/AMD CPUs da durchaus auch jenseits des Fertigungsprozesses von deutlich mehr Effizienz.

Gerade da gab es doch, z.B. durch immer besseres Power Gating, die größten Fortschritte in der Nehalem -> Sandy Bridge -> Ivy Bridge -> Haswell -> Broadwell -> Skylake Zeit.

Mal ganz davon abgesehen, daß, wie jemand weiter oben schon bemerkte, sich in diesem Zeitraum auch eine deutlich IPC Steigerung kumuliert hat.

Badesalz

2020-08-11, 20:36:49

Die Berechnungen der IPC geben Benches wie Fritz oder 7-zip, mit nur einem Thread, öftersmal nicht wirklich her. Es gibt zwar Steigerungen, klar, aber öfters eben NICHT die Fabelwerte die mit jeder neuen Generation in den Forenblasen rumschwüren.

Opprobrium

2020-08-11, 20:49:47

Und wiederum andere Benchmarks reagieren anders auf diverse Architekturverbesserungen.

Wieviel bei x86 noch möglich ist wird man wohl in den kommenden Jahren sehen, denn es ist ja spätestens seit Zen 2 wieder richtig Leben in der Bude, und irgendwann wird sich wohl auch Intel wieder berappeln. Unter diesem Aspekt ist es eigentlich ganz amüsant, daß dieser Thread überhaupt existiert, ist das doch eine Thematik die im vergangenen Jahrzehnt sehr viel aktueller war :smile:

mboeller

2020-08-11, 20:54:21

https://www.7-cpu.com/

Badesalz

2020-08-11, 21:46:51

Und wiederum andere Benchmarks reagieren anders auf diverse Architekturverbesserungen.Ja. Je spezialisierter desto besser. Allerdings ist 90% der Soft nicht "spezialisiert".

@mboeller
Link = cool. Thx.

Zephyroth

2020-08-11, 22:59:59

Letztendlich ist es dem Endanwender egal, wie die Leistung zustande kommt, Hauptsache sie ist da. Wenn mein zukünftiger Ryzen um gut 50% schneller encodiert und dabei statt 95W nur 15W braucht, sind mir die corebezogenen IPC's egal. Von mir aus können da 32 Kerne zu je nur 300MHz drinnen sein oder einer mit 15GHz. Was für mich zählt (und für andere) Geschwindigkeit und Energieverbrauch.

Badesalz

2020-08-12, 00:37:09

Hier im Thread waren die Mediarecoder aber nicht der Schwerpunkt. Die gingen und gehen immer bestens mit core-flood. Überhaupt kein Thema. Hab ich dir auch in dem anderen Thread direkt zu vermitteln versucht. Nicht weiter fragen, direkt machen ;)

Was die vielgeprisene Effizienz angeht (@all): Gibt es etwas technisches - außer Microsofts Scheduler?? =) - auf dem x86 mehrfach SMT?
Wir fahren bisher 2fach. Es gibt aber schon quasi ewig CPUs auch mit 4fach oder gar 8fach (!) SMT. Sprich 4 Kerne machen dann z.B. 16 Threads.

Opprobrium

2020-08-12, 00:56:39

Was die vielgeprisene Effizienz angeht (@all): Gibt es etwas technisches - außer Microsofts Scheduler?? =) - auf dem x86 mehrfach SMT?
Wir fahren bisher 2fach. Es gibt aber schon quasi ewig CPUs auch mit 4fach oder gar 8fach (!) SMT. Sprich 4 Kerne machen dann z.B. 16 Threads.
Gibt ja immer wieder Gerüchte dazu, zuletzt für Zen2 Epycs. Da die Leistung aber nicht aus dem Nichts kommt, sondern schlicht durch ungenutzte Resourcen auf der CPU, wird der Ertrag/die Effizienz jeweil abnehmen. Genauso wie ein SMT Thread nicht den gleichen Performancevorteil bringt wie ein vollwertiger Kern wird eine 4xSMT Thread nicht den gleichen Vorteil bringen wie ein 2xSMT Thread usw.

Obendrein ist das dann natürlich ebenfalls sehr Softwareabhängig, und da hinkt man ja schon jetzt der Hardwareentwicklung hinterher. Bevor also nicht die Software was Parallelisierung angeht große Fortschritte macht wird sich auch 4/8x SMT nicht durchsetzen. Zumindest nicht im Konsumentenbereich.

Badesalz

2020-08-12, 01:29:03

Natürlich muss man noch bisschen mehr Hardware für 4fach SMT hinkleistern als für 2fach SMT, aber eben nicht gleich in der Komplexität ganzer Kerne.

Ja das hab ich mir schon gedacht, daß es keinen großen Markt dafür gibt, weil die Softwareentwicklung ewig hinterher hinkt.
Das war mein ich aber auch der Ausgangspunkt für das was dann zu diesem Thread führte :wink:

=Floi=

2020-08-12, 01:30:44

Alleine aus sicherheitsgründen ist das mittlerweile überholt. 50$ pro core sind auch kein drama mehr.

Badesalz

2020-08-12, 01:53:43

Opprobrium

2020-08-12, 07:30:00

Ja das hab ich mir schon gedacht, daß es keinen großen Markt dafür gibt, weil die Softwareentwicklung ewig hinterher hinkt.
Das war mein ich aber auch der Ausgangspunkt für das was dann zu diesem Thread führte :wink:

Liest sich für mich eher so, als wäre das genau das Gegenteil von dem was zu diesem Thread führte :wink:

Was für eine Drecksseite. Erstmal 3min. lang Cookie-Massaker wegklicken. Dann feststellen, daß die Stümper die Tabelle im uralten IE6 richtig malen können, im 10 Jahre jüngeren Firefox (testweise einen älteren rausgeholt) nicht.

Dafür, daß es einfach doppelt so viele Threads sind tat sich da imho sonst nicht soviel. Spätestens wenn man den deblockten 2600k, also 3770k nehmen würde, den auch wenigstens bis 4.2Ghz ziehen lässt und auch am brauchbaren Speicher ranhängt.
Dann bleibt es fast nur noch eben an der Threadanzahl hängen und den kleinen Architekturverbesserungen.

So wundert es echt nicht, daß Apple am Ende und zukünftig weder mit Intel noch mit AMD was zu tun haben will und entnervt nun lieber mit ARM selbst weitermacht :frown:

Gipsel

2020-08-12, 08:11:04

Liest sich für mich eher so, als wäre das genau das Gegenteil von dem was zu diesem Thread führte :wink:Richtig. Ausgangspunkt (des nun rausgesplitteten Threads) war Zephyroths Frage (https://www.forum-3dcenter.org/vbulletin/showthread.php?p=12387499#post12387499), ob die Mediaencodingperformance eines mobilen Ryzen4x00 die seiner alten Sandybridge-Desktop-CPU erreicht bzw. übertreffen kann. :lol:

Zephyroth

2020-08-12, 09:13:39

Jo, für den ganzen Rest ist mein X230 mit Dualcore noch locker schnell genug...

Grüße,
Zeph

Badesalz

2020-08-12, 09:49:29

Richtig.Das ist natürlich nicht richtig. Das ist unbeholfene Verdreherei.
Die "Drecksseite" folgte viel später und führt Programme die sich sowieso bestens parallelisieren lassen. Im zitierten selbst ging um den Fortschritt und daß ihn quasi nur die core-flood buckeln muss. Ihr versucht jetzt billigst den Kontext auf den Kopf zu stellen. Das ist aber eigentlich sehr gut, weil euch außer so Gauklertricks wohl sonst nichts mehr einzufallen scheint :wink:

Das hat die gleiche Absicht wie die Leuchte die beim Trennen der Beiträge und Erzeugen dieses Threads sich diesen super glasklaren Threadtitel ausgedacht hat :uup:

Der_Korken

2020-08-12, 10:09:01

@Badesalz: Könntest du mal irgendwie auf den Punkt kommen? Du eierst hier von einem Thema zum anderen und keiner versteht mehr, was du eigentlich willst.

Dafür, daß es einfach doppelt so viele Threads sind tat sich da imho sonst nicht soviel. Spätestens wenn man den deblockten 2600k, also 3770k nehmen würde, den auch wenigstens bis 4.2Ghz ziehen lässt und auch am brauchbaren Speicher ranhängt.
Dann bleibt es fast nur noch eben an der Threadanzahl hängen und den kleinen Architekturverbesserungen.

Erst sagst du, es gibt abseits der Threadanzahl keine Verbesserung bei x86 ...

Ich meinte die Entwicklung von x86. Nicht die Entwicklung bei TSMC :wink:
(einfach nur kurz nachdenken...)

... und scheibst jegliche Verbesserung, die es ja doch zu geben scheint, fast ausschließlich auf Verbesserungen in der Fertigung ...

J
Wenn irgendeiner der sonst PR-Reviewer wirklich EINMAL die Eier hätte, hätte er einen 3770k auch mal fairerweise auf 4.3 gedreht (was ja jetzt nicht eine besondere Leistung wäre) und es gegen den 3300x stock vergliechen. (auch fairerweise ohne AVX2).

[...]

Könnte man wenigstens einmal sehen was die letzten ~7.5 Jahre x86 Entwicklung und ~3.8 Milliarden Transistoren gegen ~1.4 Milliarden Transistoren hervorgebracht haben.

... zählst dann AVX2 als Fortschritt auf, um direkt im nächsten Post zu sagen, dass das nicht zählt (kostet ja schließlich keine der 3,8 Milliarden Transistoren, genauso wenig wie der doppelt so große Cache, die ganzen Hardwarebeschleunigungen für AES und co und die Tatsache, dass AMD mit den HD libs und dem automatisierten Layout schon immer mehr Transitoren verbraucht hat als Intel, was aber egal ist weil am Ende der Verbrauch und die Die Size zählen ...)

AMDs "großartige Leistung" ist außer einem um 2018 rum endlich zu Intel allgemein vergleichbar effizientem x86 Design - Gründung von Intel 1968, von AMD 1969... - die Entscheidung über Chiplets in die Breite (core-flood) zu gehen. Chiplets ist eine Idee die Älter ist als ein 3770k.

Jetzt geht es wieder darum wie sinnlos core flood ist ...

Nein du findest den Bezug/Kontext zum Thema nicht. Wir reden über die Entwicklung und Weiterentwicklung von x86.

"I've said this before, and I'll say it again: in the heyday of x86, when Intel was laughing all the way to the bank and killing all their competition, absolutely everybody else did better than Intel on FP loads. Intel's FP performance sucked (relatively speaking), and it matter not one iota.

Because absolutely nobody cares outside of benchmarks."

"Stop with the special-case garbage, and make all the core common stuff that everybody cares about run as well as you humanly can. Then do a FPU that is barely good enough on the side, and people will be happy."

usw. Einfach nur lesen...

... garniert mit einem Zitat von Linus Torvalds, der unnütze Features in Kernen kritisiert ...

Natürlich muss man noch bisschen mehr Hardware für 4fach SMT hinkleistern als für 2fach SMT, aber eben nicht gleich in der Komplexität ganzer Kerne.

Ja das hab ich mir schon gedacht, daß es keinen großen Markt dafür gibt, weil die Softwareentwicklung ewig hinterher hinkt.
Das war mein ich aber auch der Ausgangspunkt für das was dann zu diesem Thread führte :wink:

... um dann aber sowas wie 4fach SMT zu fordern, was wahrscheinlich bei den gängigen Architekturen kaum was bringt weil sie zu schmal sind (und was auch im Widerspruch zu deiner Kritik steht, dass sich außer mehr Threads nichts getan hätte bei x86 CPUs ...

1. Was? Mir wäre es jedenfalls neu, daß z.B. T und M Sparcs das Problem haben. Oder IBMs Power. Es ist schon eine ganze Menge, aber halt nicht gleich die ganze Welt dreht sich um die Stümper die am x86 rumpfuschen.

... und schließlich noch auf Sicherheitsproblemen rumzuhacken, die a) hauptsächlich Intel betreffen und b) überhaupt auf Features zurückzuführen sind, die wirklich die IPC verbessern (spekulative Ausführung) und die du doch gerne haben willst.

Und das ganze mit einem Tonfall, bei dem man eigentlich gar keinen Bock mehr hat zu antworten.

Also: Was ist dein Problem?

Tobalt

2020-08-12, 10:09:52

AMD und Intel haben total verkackt in den letzten 30 Jahren, die IPC für strikt unparallelisierbare Aufgaben zu erhöhen. Sie haben damals festegestellt, dass der kürzeste Weg von A nach B eine Linie ist und leben heute immernoch unter diesen naiven Annahme [/Ironie]

Sie haben nicht verkackt, weil es für klassisches Computing keinen kürzeren Weg gibt. Die Rechenaufgaben, die in Computern ausgeführt werden, sind so fundamental und trivial, dass es da nicht viel Spielraum gibt irgendwelche effizienteren Algorithmen für bspw. eine Addition oder Multiplikation zu entwickeln. Diese Operationen sind schon atomar. Die einzigen Möglichkeiten, dies weiter zu beschleunigen haben beide schon früh entdeckt: höherer Takt.

Seit dem Ende des GHz Races scheitert nun auch das und jetzt wird selbst die Single Thread Leistung durch Parallelisierung erhöht (Vektorisierung, AVX usw.). Der strikt unparallelisierbare Code wird aber auch dadurch nicht beschleunigt.

Wirklicher Speed Fortschritt kann also heute nur noch erfolgen, wenn *SOFTWARE* besser wird. Die Programmierer (bzw. wenigstens die Compiler) müssen unparallelisierbare Aufgaben durch weniger logikeffiziente aber dafür parallele Aufgaben ersetzen. Auch diese wurde schon lange realisiert. Die allerallermeisten Apps laufen auf heutigen CPUs massiv schneller als auf den ersten 4-5 GHz CPUs (P4, Bulldozer)

Ich linke auch nochmal auf meinen Post dazu aus dem Zen3 Thread (https://www.forum-3dcenter.org/vbulletin/showthread.php?p=12387513#post12387513).

Badesalz

2020-08-12, 10:41:12

... und schließlich noch auf Sicherheitsproblemen rumzuhacken, die a) hauptsächlich Intel betreffen und b) überhaupt auf Features zurückzuführen sind, die wirklich die IPC verbessern (spekulative Ausführung) und die du doch gerne haben willst.
[...]
Also: Was ist dein Problem?Ja... Das Problem. Denke Leute wie du. Du zitierst da jetzt, versuchst mir dabei was in die Schuhe zu schieben und tust damit so, als wenn ich das gemeint hätte was eigentlich =Floi= wohl gemeint hat. Während REAL ich dem nur entgegnet habe und sein pauschales macht man aber nicht mehr, weil Sicherheitsproblem mit anderen beispielen verneinte. Was ist denn also dein Problem? :|

@Tobalt
Wirklicher Speed Fortschritt kann also heute nur noch erfolgen, wenn *SOFTWARE* besser wird. Die Programmierer (bzw. wenigstens die Compiler) müssen unparallelisierbare Aufgaben durch weniger logikeffiziente aber dafür parallele Aufgaben ersetzen. Auch diese wurde schon lange realisiert. Die allerallermeisten Apps laufen auf heutigen CPUs massiv schneller als auf den ersten 4-5 GHz CPUs (P4, Bulldozer)
Das ist interessant, aber die Beispiele leider kaum tauglich für einen fairen Vergleich.
Netburst hat gegenüber P3 schlechter skaliert was bei der Programmierung wie auch vom Compiler bedacht werden musste, um seine kleinen Vorteile auszuspielen. Das mochte keiner so wirklich. Der Takt war die Brechstange.
AMD drehte sich dagegen zu der Zeit bei der Abarbeitung (nicht dem Takt) im Teufelskreis der eigenen Hilfslosigkeit. Da gabs paar kleine Höhen und viele größere Tiefen.
Das Problem damit ist, daß man die heute "massiv schnelleren" (als damals?) Programme dadurch nicht vernünftig auf P4 gegentesten kann. Weil P4 eben eine ganz andere Geschichte ist. Vielleicht aber auf dem P3 oder Yonah Solo, wenn man sich die Mühe macht den Takt realistisch zu normieren?

Ich selbst schrieb daher weitgehend NUR über Intel und den letzten ~7.5 Jahren (und halt AMDs core-flood). Die Rhetorik mit "30 Jahren" folgt also dem hier gewohnten Muster. Wenn einem nichts einfällt, kaspert man halt bisschen rum. Nicht schlimm...

Wenn alles so gut wäre wie ihr das herbeifantasieren wollt, würde Apple nicht so vom x86 abspringen wie sie das damals beim PowerPC taten. Da gab es auch keine sonstige Not, außer eben er hats einfach nicht mehr gebracht.

Opprobrium

2020-08-12, 10:58:19

Wenn alles so gut wäre wie ihr das herbeifantasieren wollt, würde Apple nicht so vom x86 abspringen wie sie das damals beim PowerPC taten. Da gab es auch keine sonstige Not, außer eben er hats einfach nicht mehr gebracht.
An Deinem Diskussionsstil kannst Du noch ein wenig feilen :smile:

Könnte auch dran liegen, daß Apple sich von einem Arbeits-PC Hersteller (das war auch damals der Grund für den Wechsel zu Intel: Die PowerPC CPUs wurden schlicht zu langsam für derlei Arbeiten) für Video- und Grafikdesigner zu einem, salopp gesagt, Modeaccessoir Hersteller gewandelt hat. Und dafür reichen eben kleine, stromsparende CPUs aus. Da Apple dann auch noch in der Lage ist seine Software komplett an die Hardware anzupassen und umgekehrt gibt es da natürlich, neben den wirtschaftlichen, auch weitere Effizienzvorteile.

Wäre eigentlich mal interessant zu sehen, wie x86 sich entwickeln würde, wenn man da die Lízenzen ähnlich handhaben würde wie bei ARM.

Durch das Duopol AMD/Intel (OK, Via gibt es auch noch), das dann auch noch für einen längeren Zeitraum durch das AMD KO dank Intels Geschäftspraktiken ein quasi-Monopol war wurd da nunmal einiges an Entwicklungspotential verschlafen im letzten Jahrzehnt.

Tobalt

2020-08-12, 11:00:21

Die Rhetorik mit "30 Jahren" folgt also dem hier gewohnten Muster. Wenn einem nichts einfällt, kaspert man halt bisschen rum. Nicht schlimm ;)
Ich meinte aber tatsächlich 30 Jahre. Alle CPUs, die eine simple boolsche Operation pro Takt oder auch eine Addition pro Takt ausführen konnten, sind in solchen unparallesierbaren Aufgaben nicht langsamer pro Takt als heutige.
Wenn man unparallele Divisionsaufgaben, sieht es wieder anders aus, aber Divisionen sind ja in schnellem Code eher rar.

Ansonsten kommt der komplette Speedup über Takt, und die vielen unzulässigen Instruktionserweiterung, die für viele Aufgaben (aber eben nicht alle) mittels Cheaten schnellere Ergebnisse generieren.

Wenn alles so gut wäre wie ihr das herbeifantasieren wollt, würde Apple nicht so vom x86 abspringen wie sie das damals beim PowerPC taten. Da gab es auch keine sonstige Not, außer eben er hats einfach nicht mehr gebracht.
Dann warte mal auf die Apple Wunder-CPU, die unparallelisierbaren Code beschleunigt ;) Die kehren x86 deshalb den Rücken, weil sie die ganzen Legacy Sachen nicht benötigen, weil sie die Hand über ihr komplettes Software-portfolio haben. Du erinnerst dich, was ich weiter oben bzgl Software geschrieben habe ?

Badesalz

2020-08-12, 11:04:25

@Opprobrium
Da hast du vielleicht Recht. Deswegen kann halt ein ipad z.B. auch ein hochauflösendes h.265 Video ruckelfrei abspielen, für welches man beim WinPC zigfache Leistung braucht...

Durch das Duopol AMD/Intel (OK, Via gibt es auch noch), das dann auch noch für einen längeren Zeitraum durch das AMD KO dank Intels Geschäftspraktiken ein quasi-Monopol war wurd da nunmal einiges an Entwicklungspotential verschlafen im letzten Jahrzehnt.Ah doch noch?! =)

Der_Korken

2020-08-12, 11:10:33

Ja... Das Problem. Denke Leute wie du. Du zitierst da jetzt, versuchst mir dabei was in die Schuhe zu schieben und tust damit so, als wenn ich das gemeint hätte was eigentlich =Floi= wohl gemeint hat. Während REAL ich dem nur entgegnet habe und sein pauschales macht man aber nicht mehr, weil Sicherheitsproblem mit anderen beispielen verneinte. Was ist denn also dein Problem? :|

Du beschwerst dich, dass dir angeblich keiner auf deine Fragen antwortet und dich keiner versteht bzw. dich bewusst missverstehen wollen. Auf die Idee, dass das an deinen eigenen Beiträgen liegen könnte, bist du noch nicht gekommen? Anstatt mal klar schiff zu machen, verweist du jetzt wieder auf "ihr legt mir Sachen in den Mund", "ihr lest meine Beiträge nicht richtig", usw. Ich habe sie gelesen und sehe wie in meinem letzten Post dargelegt Widersprüche und Gedankengänge, die ich nicht nachvollziehen kann.

Opprobrium

2020-08-12, 11:19:59

Ah doch noch?! =)
Hab nie was anderes behauptet. Du warst nur derjenige, der behauptet hat, daß AMD zwischen 1969 und 2018 nie konkurrenzfähig war ;)

Zu den ruckelfreien Videos: Das geht eben durch dedizierte Einheiten auf den CPUs. Das Problem dabei ist dann halt, daß das erstens Transistoren kostet und zweitens eben nur für bestimmte Codecs funktioniert. Wenn Du dann auf dem iPad mal versuchst ein Video abzuspielen, dessen Codec nicht in Hardware unterstützt wird fängts halt an zu ruckeln. Mit der richtigen Hardware kostet das übrigens auch am PC nicht soviel Leistung. Oft sind dafür heutzutage - übrigens auch bei ARM - die GPUs zuständig.

Gipsel

2020-08-12, 11:24:30

Badesalz

2020-08-12, 11:25:28

@Der_Korken
Ist doch nicht gleich total schlimm. Da fragt man ggf. EINMAL genauer nach und konstruiert sich nicht sofort etwas was die Gegenseite direkt im möglichst schlechtesten Licht stellt. Der Geist ist unwillig, das Fleisch ist schwach :wink:

@Tobalt
Super :) Das sind Sachen nach welchen ich schon ewig fragen wollte:

Die kehren x86 deshalb den Rücken, weil sie die ganzen Legacy Sachen nicht benötigen
1. Was sind diese sagenumwobenen Legacy Sachen, die auch an ganz anderen Stellen in anderen Threads immer wieder mal auftauchen?
2. Inwiefern stören sie, wenn man sich die CPU nicht selbst baut und weder das OS noch die Anwendung diese Sachen nutzt/benötigt (?)

weil sie die Hand über ihr komplettes Software-portfolio habenWas bedeutet "ihr"? Wenn man Handbrake, Chrome, XnView MP oder Phiewer oder Lyn, LibreOffice, Unarchiver und VLC installiert, inwiefern installiert man eine Software über die Apple die Hand drüber hat?

@Gipsel
Ist der Decoder außerhalb der CPU/des SOCs?

(du lachst sehr viel, wirkt irgendwie nervös ;))

Gipsel

2020-08-12, 11:31:41

Ist der Decoder außerhalb der CPU?Offensichtlich verstehst Du entweder die Problematik nicht oder Du willst es nicht.
Eine moderne CPU enthält auch 24+ PCIe 4.0 Lanes und kann mit 'ner Größenordnung mehr externer Bandbreite irgendwas hin und her schaufeln als irgendein Smartphone ARM, der auf möglichst geringen Verbrauch getrimmt ist. Oder man nimmt so einen 64 Core-Server-ARM-Chip mit ewig viel externer Bandbreite (hat der eigentlich dann noch die fixed function Decoder on die?). Tut das irgendwas zur Sache?
Wenn es nach Deiner Argumentation geht, dann mach doch mal einen IO-Bandbreiten Benchmark mit einem NVMe-Raid mit so 'nem Smartphone-Chip! Geht nicht so wirklich? Na dann hat ARM ja wohl sowas von verkackt!
=> Macht Beides nicht so recht Sinn, oder? ;)

Opprobrium

2020-08-12, 11:33:41

(du lachst sehr viel, wirkt irgendwie nervös ;))
Vermutlich findet er, ähnlich wie ich, schlicht Deine Art zu "argumentieren" sehr amüsant :cool:

Badesalz

2020-08-12, 11:34:25

@Gipsel
Können wir die Nebelkerzen bitte weglassen?

Hab nie was anderes behauptet. Du warst nur derjenige, der behauptet hat, daß AMD zwischen 1969 und 2018 nie konkurrenzfähig war ;)Nochmal? Nein, DAS hab ich nicht gesagt. Ich sagte, daß sie allgemein, also in Gänze, nie so wirklich gut dabei waren. Schon der K6 war bei Integer zeitweise besser. Ja, an die Zeit ab August 1999 bis Januar 2002 erinner ich mich aber auch noch ;)

Gipsel

2020-08-12, 11:37:43

@Gipsel
Können wir die Nebelkerzen bitte weglassen?Fragt der, der ständig welche wirft und (wie von Der_Korken demonstriert) keine vernünftige Argumentation auf die Reihe bekommt. Aus meiner Sicht gerne!

Badesalz

2020-08-12, 11:44:36

(wie von Der_Korken demonstriert)
Ja. Einfach gegenseitig liebevoll auf die Schulter klopfen und ab und zu auch umarmen. Bringts...

Momentan wäre imho das interessanteste die Antworten auf #59. Bis dahin bitte die Seite nicht zumüllen. Thx.

Zephyroth

2020-08-12, 11:57:43

Hat eigentlich irgendwer schon bemerkt, das es Badesalz nie um den Inhalt einer Diskussion geht, sondern immer nur um die Diskussion selbst? Frei nach dem Motto: "The show must go on!"

Sinnlos. Links liegen lassen. Ich kenn' das Spielchen schon vom E-Auto-Thread.

Grüße,
Zeph

Opprobrium

2020-08-12, 11:58:38

Was bedeutet "ihr"? Wenn man Handbrake, Chrome, XnView MP oder Phiewer oder Lyn, LibreOffice, Unarchiver und VLC installiert, inwiefern installiert man eine Software über die Apple die Hand drüber hat?
Hast Du schonmal LibreOffice oder Chrome auf einem MacBook mit ARM CPU installiert? Selbst auf aktuellen x86er iMacs wirft der Computer da erstmal eine Warnung auf, so daß man in den Systemeinstellung überhaupt erstmal das installieren von so böser offener Software erlauben muss. Glaub kaum, daß das besser wird wenn das OS dann auf eine eigenen CPU Architektur angepasst wurde ;)

Und soweit ich weiß gibt es fürs iPhone und iPad neben Safari keine Browser, nur Browserskins für Safari? Kann mich aber auch irren, eventuell hat sich das ja inzwischen geändert...

Hat eigentlich irgendwer schon bemerkt, das es Badesalz nie um den Inhalt einer Diskussion geht, sondern immer nur um die Diskussion selbst? Frei nach dem Motto: "The show must go on!"

Jo, ich hab auch das Gefühl er will nur ein wenig trollen, aber die Diskussion um sein gestänkere herum ist ganz interessant :smile:

Badesalz

2020-08-12, 12:08:22

@Zephyroth
Im Thread zur E-Kabine ging es mir selbst zu allermeist um die (Lade)Infrastruktur. Das ist eine Sache die auch heute noch so glasklar ist, daß ich den Thread irgendwann wegen ausufernden Fanboyismus quasi aufgegeben habe. Du hast da deine Ziele also auch ohne links liegen lassen erreicht. Was stört dich das also? Du hast mehr als nur einmal bewiesen, daß du derartiges super drauf hast.

@Opprobrium
Warum sollte ich das plötzlich auf einem ARM Apple installieren? In #59 und zitiertem geht es nicht um ARM.
Daß sich das OS erstmal ggf. wegen irgendwelchen Certs sperrt gilt zwar, aber ich erkenne grad noch keinen Kontext zu dem Tobalt den Umschwung von x86 auf Arm beschrieben hat. Du? (kopfkratz) Sie können sich das erlauben, weil sie erstmal rumstänkern, wenn man LibreOffice installieren will und beim Browser man nichts eigenes darf, sondern nur GUIs für Webkit? Und das eben auf x86 wie Arm? Und dann? Sorry verstehe ich grad nicht.

Opprobrium

2020-08-12, 12:15:51

ich erkenne grad noch keinen Kontext in welchen Tobalt den Umschwung von x86 auf Arm beschrieben hat. Du?
Jupp.

Hier:
Die kehren x86 deshalb den Rücken, weil sie die ganzen Legacy Sachen nicht benötigen, weil sie die Hand über ihr komplettes Software-portfolio haben. Du erinnerst dich, was ich weiter oben bzgl Software geschrieben habe ?
Und sogar hier:
So wundert es echt nicht, daß Apple am Ende und zukünftig weder mit Intel noch mit AMD was zu tun haben will und entnervt nun lieber mit ARM selbst weitermacht :frown:

;D

Ex3cut3r

2020-08-12, 12:16:31

Also ich bin von einem 4770k, 16GB DDR3 2400mhz, SATA SSD auf einen 3700X mit 32GB DDR4 3200 CL14 @ 3733 CL14 und NVME PCIe 4.0 NVME geswitcht. Der Unterschied ist doch größer als vorher gedacht. In Spielen läuft einfach alles runder. Und in meinen Anwendungen auch alles etwas ruckelfreier. Klar, 16 Threads werden bisher kaum von Games auch wirklich genutzt. Das könnte sich aber mit den neuen Konsolen schon bald wieder ändern. Plane aber eh auf einen Zen 3 im laufe des nächsten Jahres zu switchen.

Zephyroth

2020-08-12, 12:25:04

@Zephyroth
Was stört dich das also? Du hast mehr als nur einmal bewiesen, daß du derartiges super drauf hast.

Das du jeden Thread vergiftest in dem du auftauchst. Du bist ein klassischer Troll. Ein intelligenter, redegewandter, keine Frage, aber dennoch ein Troll. Wenn du so willst ein Troll im Frack.

Grüße,
Zeph

Tobalt

2020-08-12, 12:33:06

Das Argument mit den nicht benötigen x86 Legacy-Sachen habe ich nur weitergegeben weil ich es extrem oft schon gehört habe, auch von Leuten, die ich für kompetent erachte und auf deren Ansichten ich daher was gebe.

Ich würde mich aber auch freuen, wenn jemand das genauer ausführen könnte, also was diese Legacy-Sachen überhaupt sind und warum diese auch bei Nichtnutzung noch stören.

Ich vermute es handelt sich um alte Instruktionen, die in aktueller Software und Hardware obsolet sind, weil vielleicht noch aus MSDOS Zeiten oder so. Damit die CPUs das aber immernoch ausführen könnten, müssen bestimmte Teile so flexibel (und somit kompliziert) gebaut werden, dass es zusätzlich Platz/Takt/Power kostet.

Zephyroth

2020-08-12, 12:59:13

Lehdro

2020-08-12, 13:41:35

Badesalz meckert an der fehlenden Steigerung der IPC's rum. Gut, insofern hat er recht. Ich meine allerdings, das das Ende der Fahnenstange für X86 erreicht ist, will man den gesamten Befehlssatz beibehalten (eben auch die Legacy-Sachen, wie 16bit-Befehle etc.).
Da hake ich jetzt mal ein: Das hat man schon zu Ivy Bridge Zeiten geäußert und heute sind wir schon wieder einen Schritt weiter und Zen 3 bzw Tiger Lake werden zeigen was hier noch möglich ist, WENN die Hersteller da auch mal wirklich Wert drauflegen.
Das mussten sie bisher (Zeitraum ~2011-2017) aber nicht wirklich, da sie anders an das Thema herangegangen sind. Intel hat den Fokus primär auf die Effizienz gelegt (Server > Laptop > Desktop, von der Priorität (https://datacenterfrontier.com/data-center-first-intels-vision-for-a-data-driven-world/)) und nur "rudimentäre" Verbesserungen am Design an sich vorgenommen. Aber keinesfalls eine komplett neue Architektur oder quasi gigantische Überarbeitungen im Sinne von heutigen CPUs mit explodierenden Transistorzahlen/Flächen (ab Ice Lake). Den Rest der Steigerungen hat sich Intel von den Fertigungstechniken und den dadurch besseren Taktraten bezogen, ebenso wurde immer mehr an das technische Limit gebinned. Das sieht man auch gut an den durchschnittlichen OC Spielräumen, so bot SB noch weit über 1 GHz Spielraum, so ist heute bei CML schon bei knapp 100 MHz über dem Single Core Turbo die Luft raus - damals wäre eine solche CPU nicht nur als OC Krücke verschrien, sondern gleich als "kein OC möglich" gebrandmarkt worden (ähnlich wie Zen 2 heute). Nur als Vergleich: Ein Phenom X4 9950 galt damals als absolute OC Krücke und machte immerhin beachtliche 3 GHz mit - ausgehend von 2,6 GHz. Heutzutage muss Intel aber über die Architektur kommen, denn die Fertigung ist ausgereizt was den Takt angeht und den Spielraum hat man seit knapp 8 Jahren auch kontinuierlich aufgefressen - was bleibt Intel also übrig? Vorhang auf für ICL und kommende Generationen bei denen die IPC im Vordergrund steht, auch wenn durch die zurückhängende Fertigung der Takt vorerst noch leiden muss, aber nur so kann Intel überhaupt vorwärts kommen.

AMD hingegen hat versucht mit der Innovation gegen Intels Dominanz der Fertigung anzutreten und ist quasi gleich zwei mal auf die Nase gefallen, weil der Markt nichts frisst was nicht deutlich attraktiver ist als die Konkurrenz (Phenom I / II) oder deutlich anders ist als die Norm (Bulldozer). Mal ganz abgesehen von den Fertigungsrückständen ist AMD hier auch gleich auf die Breite gegangen (vgl. Coreflood) und hat dabei aber so viele Kompromisse eingehen müssen, dass die ganze Aktion von vorne bis hinten vollkommen zum Scheitern verurteilt war. Nach dem sie dann mit Zen/+ IPC-technisch eine Bombe Platzen lassen und nebenbei bewiesen haben, dass IPC sich sehr wohl massiv steigern lässt ohne zwangsweise iterativ vorgehen zu müssen, ist wohl klar wo der Pfad hinführt den AMD da beschreitet. Zen 2 ist ein gutes Indiz und alle Anzeichen für Zen 3 zeigen auf eine weitere deutliche IPC Steigerungen ohne massive Pferdefüße hin - womit das Argument dass x86 "am Ende ist" wahrscheinlich einfach nur solange eine self fullfilling prophecy war, wie keinerlei harter Wettbewerb in dem Segment herrschte. Intel und AMD beweisen uns gerade das x86 so lebendig ist wie nie. Ungeahnte Chipdesigns (CCX), Chiplets, komplette neue Fabrics (IF; MESH), Fertigungstechniken wie FOVEROS oder Intels Lakefield Testballon sind Innovationen die es in dieser Masse seit Jahrzehnten einfach nicht gab (vgl. integrierter Speicherkontroller). Und auch die berüchtigte "Coreflood" ist auch nur ein argumentatives Feigenblatt für den oberflächlichen Betrachter des Marktes: AMD muss mittlerweile (Zen 2 / 3) nahezu keine Abstriche mehr bei der Single Core Leistung machen und bietet trotzdem Kerne ohne Ende - während Intels Vorsprung in dem Single Core Bereich schneller schmilzt als ein Eis in der sommerlichen Hitze heutzutage.

Opprobrium

2020-08-12, 13:46:59

+1

Hatte ich ja etwas weniger ausführlich (https://www.forum-3dcenter.org/vbulletin/showthread.php?p=12389164#post12389164) auch schon geschrieben.

Tobalt

2020-08-12, 14:05:39

Sehe ich nicht so. Die neuerlichen IPC steigerungen schlagen ja auch nur bei ausreichend parallelisierbaren Sachen durch, die die Kernbreite nutzen können. Mit Software, die diese Parallelisierungen nicht nutzt, fällt ein guter Teil der IPC schon weg.

Anderes kommt durch größere Caches, die in 22 nm oä. einfach noch zu groß und teuer gewesen wären.

Sprungvorausrechnung ist auch Parallelisierung.

Das sind alles "Cheats" um die Nichtsteigerbarkeit der seriellen Ausführung zu kaschieren.

Bessere Sprungvorhersage kann man als kontinuierliche Entwicklung sehen.. Allerdings ließt man das auch bei jeder Generation."Worse branch prediction" würde sich auf dem Spec Sheet auch schlecht machen. Schwer zu sagen, wieviel die Verbesserungen daran heute noch bringen. Offensichtlich ist auch die Sprungvorhersage aber ein Cheat, da sie die eigentliche Rechnung nicht beschleunigt und IPC nicht erhöht.

mboeller

2020-08-12, 16:15:34

Dann warte mal auf die Apple Wunder-CPU, die unparallelisierbaren Code beschleunigt ;)

reverse Hyperthreading :)

Soft-Machines ... :biggrin:

=Floi=

2020-08-12, 16:38:49

1. Was? Mir wäre es jedenfalls neu, daß z.B. T und M Sparcs das Problem haben. Oder IBMs Power. Es ist schon eine ganze Menge, aber halt nicht gleich die ganze Welt dreht sich um die Stümper die am x86 rumpfuschen.

2. Was? Bei damals noch brauchbarer Verfügbarkeit hat der 3300x doch keine 200$ gekostet. Der 3600 auch heute keine 300$ oder?

weil bei den ibm prozessoren keiner sucht. Haben die überhaupt 1% marktanteil? Bei intel prozessoren ist SMT tot. Damit schiesst du dir ggf. die ganze firma ab, wenn deswegen wichtige daten geleakt werden. Es gab genung seriöse empfehlungen es auszuschalten.

die 50$ waren pi mal daumen. Auch die server prozessoren waren nicht so viel extrem teurer...
Nebenbei skaliert ein weiterer core im idealfall mit 100% und SMT eher mit 25%.

Badesalz

2020-08-12, 17:23:03

@Tobalt
Ja das ist auch richtig (IPC). Man kann die IPC pero Kern rechnen, bei einem Thread, und bei einer Aufgabe auf merehren Threads, pro Thread.
Das sind auch wieder 2 verschiedene Baustellen.

@Lehrdo
Gilt. Wäre zwar mit weniger Finten auch ausgekommen, aber trotzdem schönes Ding =)
Nur während das Fußvolk aber nur in der Lage war sich wieder nur gegenseitig zuzujubeln, hab ich eine leicht ketzerische These in den Raum gehangen und schlug einen 3770k - 3300x Vergleich vor. Möglichst mit Minimierung des technischen Fortschritts außerhalb der CPU selbst.

So könnte man sich das direkt anschauen ohne sich einfach nur viel Zeug erzählen lassen zu müssen...

Wenn du auf deine Ankündigungen nur auch mal Taten folgen lassen würdest... :biggrin:Wenn du nur einmal an einem Thread teilnehmen würdest wo du nur zum Thema etwas beitragen würdest ohne rumzukaspern...

@Opprobrium
Ehrlich gesagt man erfährt schon mehr durch meine Fragem als durch deine Antworten. Ich weiß immernoch nicht warum du an dem Thread teilnimmst. Deine Gegenmeinung-Blase ist Universen davon weg was ein Lehrdo drauf entgegnen kann. Findst du dich schlau genug das hier als eine Spielwiese und Zeitvertreib zu benutzen? Dafür reichts auch nicht ;)

Opprobrium

2020-08-12, 17:31:55

Ehrlich gesagt man erfährt schon mehr durch meine Fragem als durch deine Antworten.

Eine der Sachen die ich an diesem heißen, faulen Sommertage erfahren habe ist, daß Du so klug bist, daß es mich wundert, daß Du hier im Forum unterwegs bist anstatt einfach mit deinen Kumpels die Hard- und Softwarewelt zu revolutionieren und nebenbei die Welt zu retten. Vermutlich ist das einzige, was Dich davon abhält Deine Verachtung gegenüber uns simplen Sterblichen :comfort2:

Ex3cut3r

2020-08-12, 17:57:48

Es gibt doch genug Benches mit 7700k vs 3300X. Der Ryzen schlägt ihn eigentlich immer. Mit 5GHZ OC sieht die Sache wohl anders aus. Aber solche Test gibt im Mainstream nicht.

Benutzername

2020-08-12, 18:10:53

Es gibt doch genug Benches mit 7700k vs 3300X. Der Ryzen schlägt ihn eigentlich immer. Mit 5GHZ OC sieht die Sache wohl anders aus. Aber solche Test gibt im Mainstream nicht.

Wozu auch im Mainstream. Die allermeisten Leute betreiben ihre Rechner in der Standardeinstellung. Falls XMP geladen wird ist das schon viel.

Zossel

2020-08-12, 18:16:27

Ich meine allerdings, das das Ende der Fahnenstange für X86 erreicht ist, will man den gesamten Befehlssatz beibehalten (eben auch die Legacy-Sachen, wie 16bit-Befehle etc.).

Meinst du das oder kannst du das an konkreten Beispielen belegen?

A20 ist IMHO Geschichte.
Der BCD-Kram läuft bestimmt per µ-code und bremst wohl kaum X64
Die 80-Bit Register für X87 könnten lustig sein, die waren aber schon immer eklig.

Zossel

2020-08-12, 18:27:35

1. Was? Mir wäre es jedenfalls neu, daß z.B. T und M Sparcs das Problem haben. Oder IBMs Power. Es ist schon eine ganze Menge, aber halt nicht gleich die ganze Welt dreht sich um die Stümper die am x86 rumpfuschen.

Seitenkanäle durch Nebenläufigkeit ist ein generelles Problem, scheißegal welches Logo auf den Dingern klebt. Oder hast du das Problem nicht verstanden?

Nightspider

2020-08-12, 18:45:43

Es gibt doch genug Benches mit 7700k vs 3300X. Der Ryzen schlägt ihn eigentlich immer. Mit 5GHZ OC sieht die Sache wohl anders aus. Aber solche Test gibt im Mainstream nicht.

Also bei dem Test hier ist es eher ein knappes Kopf an Kopf Rennen mit leichtem Vorteil bei 7700K.

https://www.youtube.com/watch?v=GByRUWHO-8I

Ist natürlich dennoch ein netter Prozessor für 130 Euro aber sobald die neuen Konsolenports kommen werden die QuadCores zerschmettert.

Ex3cut3r

2020-08-12, 19:34:16

Ist natürlich dennoch ein netter Prozessor für 130 Euro aber sobald die neuen Konsolenports kommen werden die QuadCores zerschmettert.
Meinst du wirklich, dass das so schnell gehen wird? Solange PS4 und XboxOne weiter bedient werden, wohl eher nicht. Wenn man die alten fallen lässt für AAA Titeln nach 2-3 Jahren....ja....dann denke ich, ist es soweit. Nur haben wir dann wahrscheinlich schon Zen 5 mit DDR5 und für 120€ gibt es dann wohl 6/12 CPUs wenn nicht sogar 8/16.

4/8 sind dann irgendwo für 30€ zu haben mit iGPU. Und die Next Gen Konsolen sind dann auch schon wieder kalter Kaffee. Weil eine 200€ GPU mit 16GB VRAM von Nvidia/AMD den Boden mit denen aufwischt. ^^

In 2-3 Jahren wird wohl jeder mittlerer Oberklasse PC so aussehnen:
8C/16T CPU Zen 3 oder 4 / Intel 11th oder 12th Gen
32GB RAM DDR4 oder DDR5
Raytracingfähige GPU mit 16GB VRAM min.
PCIe 4.0/5.0 NVME

High End wohl so:
12/24 oder 16C/32T CPU Zen 5 / Intel 13th Gen
64GB (2x32) DDR5
Raytracingfähige GPU mit 20GB+
PCIe 5.0 NVME

----------------------------------------------------------------------------------------------------------------------------

(2030) Next Next Gen Open World AAA Games sehen dann wohl so aus: Riesige Städte indem man jedes Gebäude betreten kann und es Millionen von NPCs gibt. Und das natürlich alles ohne Ladezeiten. :eek:

Ich hätte da einige Ideen, schade das ich zu dumm bin zum Programmieren. ;D
Naja, vlt. im nächsten Leben.

Badesalz

2020-08-12, 19:53:40

Seitenkanäle durch Nebenläufigkeit ist ein generelles Problem, scheißegal welches Logo auf den Dingern klebt. Oder hast du das Problem nicht verstanden?Ah so. Ah so... Die proofs of concept kenn ich zugegeben nur von x86 und auch da ist nicht alles so generell. Sonst wäre AMD 1 zu 1 genauso betroffen wie Intel.
Der Einwurf ist also wie schon davor ok, Aufklärung ist aber anders.

@Ex3cut3r
Er sagte nicht es wird schnell gehen, sondern wenn sie kommen. Horizon kam 2017, der Port kam 2020. Bis zu solchen PS5 Ports hat also jeder der richtig zockt DDR5 :wink:

edit: Sorry. Sehe jetzt erst, dein Gedankengang war fast der gleiche :tongue:

Ex3cut3r

2020-08-12, 19:55:25

Achso. Dann mein Fehler.

=Floi=

2020-08-12, 20:05:48

Auch egal.
Gibst du 60€ für ein spiel aus und spielst es dann nicht? Das ist doch auch nonsens.
Sobald 2-3 aktuelle spiele nicht mehr laufen und das tun sie mittlerweile auf 4 kernen nicht mehr, taugt der rechner nicht mehr für aktuelle titel.

grundsätzlich wäre SMT eine super idee, aber mittlerweile dürfte sehr viel davon hinfällig sein und man investiert einfach in mehr hardware und ist dafür einfach von der seite save.

Ex3cut3r

2020-08-12, 20:09:20

und das tun sie mittlerweile auf 4 kernen nicht mehr, taugt der rechner nicht mehr für aktuelle titel.

Nenn mir diese Spiele mal bitte...bin gespannt....:smile:

Badesalz

2020-08-12, 20:10:35

@=Floi=
Welche Spiele laufen denn nicht mehr wegen nur 8 Threads?
Wobei: Das wäre eh OT ;) Um core-flood ging es eben nicht.

Meinst du Zen3 wird kein SMT mehr haben? :| Oder wie meinst du das?

@Ex3cut3r
Wahrscheinlich irgendwas mit Frametimes bei 8k oder so.

Zephyroth

2020-08-13, 08:47:55

Lehdro

2020-08-13, 11:17:31

Wie ist das zu bewerten? Egal wie man es dreht, bei der IPC muss sich deutlich was getan haben, selbst wenn der Ryzen mit 4GHz läuft und der i5 nur bei 3.3GHz erklärt das nicht einen Rückstand von fast 50%.

Natürlich hat sich etwas getan. Neue Instruktionen (AVX2), schnellere/größere Caches, bessere FPUs - das summiert sich. Vielleicht nicht bei jeder Wald und Wiesen Software, aber bei Software die wirklich auf massive Power angewiesen ist, kommt dann schon deutlich etwas bei rum. Sprich: Renderer, Encoder etc

][immy

2020-08-13, 12:15:28

Nachdem ich mich inzwischen einen Laptop mit Ryzen 5 4500U bestellt habe, sehe ich mir gerade Benchmarks gegen meinen i5-2500k an. Ich bin ja schon lange weg vom Fenster, aber irgendwie scheint sich Cinebench etabliert zu haben. Interessant finde ich den Singlecore-Test. Hier schlägt der Ryzen meinen i5 mit 448 zu 262. Dabei liegen die Takte gar nicht so weit auseinander. Der Ryzen hat einen Basistakt von 2.3GHz mit Turbo auf 4GHz, der i5 liegt bei 3.3GHz und 3.7GHz Turbo.

Wie ist das zu bewerten? Egal wie man es dreht, bei der IPC muss sich deutlich was getan haben, selbst wenn der Ryzen mit 4GHz läuft und der i5 nur bei 3.3GHz erklärt das nicht einen Rückstand von fast 50%.

Grüße,
Zeph

Naja, kommt halt auch drauf an was du vergleichst. Klar ist, Zen 2 hat schon einiges an Single-Thread Leistung gebracht. Und wie der R5 4500U unter anderem zeigt, nicht nur durch den großen Cache. Neben neuen Instruktionssets ist es aber vor allem der Boost-Modus der sich verändert hat. Hier kann Zen2 dank 7nm richtig punkten und auch im Laptop noch gut durchsprinten.
Intel werkelt ja seit x "Generationen" nur noch am Boost-Modus. Zwar sind neue Cores dazu gekommen, aber immer auch mit mehr Verbrauch, wenn diese dann auch tatsächlich genutzt werden. Denen Fehlt hier einfach der Fertigungsschritt extrem im mobilen Sektor.

Anno 1800 ist hier ein ganz guter Benchmark wenn es um die Single-Thread Leistung geht. Bin immer wieder darüber erstaunt wie ein heutiges Spiel noch so seriell ablaufen kann, aber daran lässt sich ganz gut bei AMD erkennen wie gut die IPC gestiegen ist über die AMD CPU Generationen.

Badesalz

2020-08-13, 12:30:21

@Zephyroth
Cinebench haben PR-Reviewer durchgesetzt. Nimm 7-zip. Einmal mit einem Thread und einmal mit allen, dividiert durch die Threadanzahl.

Da hat sich natürlich auch was getan, kommt aber meist nicht so verzerrt wie in all den PR-Reviews.

Brillus

2020-08-13, 12:30:40

Brillus

2020-08-13, 12:41:11

Ah so. Ah so... Die proofs of concept kenn ich zugegeben nur von x86 und auch da ist nicht alles so generell. Sonst wäre AMD 1 zu 1 genauso betroffen wie Intel.
Der Einwurf ist also wie schon davor ok, Aufklärung ist aber anders.

@Ex3cut3r
Er sagte nicht es wird schnell gehen, sondern wenn sie kommen. Horizon kam 2017, der Port kam 2020. Bis zu solchen PS5 Ports hat also jeder der richtig zockt DDR5 :wink:

edit: Sorry. Sehe jetzt erst, dein Gedankengang war fast der gleiche :tongue:

Meltdown gabs auch für ARM und IBM. Eigentlich war von den großen Herdtellern nur AMD nicht betroffen.

Badesalz

2020-08-13, 12:41:46

16-bit instruktionen, A20 Gate x87-FPU. Kämen mir da spontan in den Sinn. Für ganz neues System sogar 32-Bit.Es ging nicht um die Namen, sondern ob und wie es heute stören sollte, wenn man die CPU nicht selbst baut und wenn weder das OS noch die Anwendungen das nicht nutzen.

(vernünftig lesen)

Brillus

2020-08-13, 12:46:05

Es ging nicht um die Namen, sondern ob und wie es heute stören sollte, wenn man die CPU nicht selbst baut und wenn weder das OS noch die Anwendungen das nicht nutzen.

(vernünftig lesen)

Weniger kompöexe Decoder. Beim A20 Gate weglassen von seltsamen unnötigen Hacks. X87 unnötige Register. Alles unnötige Transitoren die Platz und Strom fressen und im Fall von Decoder gar die Instruktionslatenz erhöhen können. Sollte eugentlich klar sein das weniger komplex = einfacher.

Zephyroth

2020-08-13, 12:46:28

@Zephyroth
Cinebench haben PR-Reviewer. Nimm 7-zip. Einmal mit einem Thread und einmal mit allen, dividiert durch die Threadanzahl.

Da hat sich natürlich auch was getan, kommt aber meist nicht so verzerrt wie in all den PR-Reviews.

Gute Idee.

Was meinst du mit PR-Review? Ich weis net in wie weit die Seite www.cpu-monkey.com in irgendeine Richtung gefärbt ist. Reviews machen die scheinbar nicht. Die fahren ihre Benchmarks und veröffentlichen die Ergebnisse. Da hab' ich diese Werte her.

AMD Ryzen 5 4500U vs. Intel Core i5-2500k (https://www.cpu-monkey.com/de/compare_cpu-amd_ryzen_5_4500u-1144-vs-intel_core_i5_2500k-5)

Grüße,
Zeph

Badesalz

2020-08-13, 12:52:22

Weniger kompöexe Decoder. Beim A20 Gate weglassen von seltsamen unnötigen Hacks. X87 unnötige Register. Alles unnötige Transitoren die Platz und Strom fressen und im Fall von Decoder gar die Instruktionslatenz erhöhen können. Sollte eugentlich klar sein das weniger komplex = einfacher.Nochmal. Es ging nicht um die, welche die CPU bauen müssen.
Und auch nicht darum zu theorisieren, sondern auch was aufzeigen ;)

Tobalt

2020-08-13, 13:29:52

Nochmal. Es ging nicht um die, welche die CPU bauen müssen.
Und auch nicht darum zu theorisieren, sondern auch was aufzeigen ;)

Er schreibt doch das zB die Instruktionslatenz erhöht wird, weil die Decoder komplizierter als heute nötig sind. Würde man das entschlacken, kann man also die Rechenwerke besser auslasten mit durchschnittlichen ST Tasks. Dadurch würde der Speed in ST Tasks auch steigen.

Aufzeigen ist jetzt wieder so ein Ding. Das kannst du kaum als Maßstab für die Akzeptanz der Argumentation ansetzen. Dafür müsste man ja einen Zen2 zB hernehmen und nochmal neu designen ohne x86 Legacy Kompatibilität. Das dann im gleichen Prozess fertigen und benchen.

Was man machen kann, ist es simulieren oder evtl. in einem FPGA implementieren, was mehr oder weniger aufs selbe kommt. Wenn sich dabei zeigt, dass der Codedurchsatz pro Takt steigt, dann wird das in einem realen Prozessor auch so sein.

Zossel

2020-08-13, 14:08:20

Weniger kompöexe Decoder. Beim A20 Gate weglassen von seltsamen unnötigen Hacks. X87 unnötige Register. Alles unnötige Transitoren die Platz und Strom fressen und im Fall von Decoder gar die Instruktionslatenz erhöhen können. Sollte eugentlich klar sein das weniger komplex = einfacher.

Kannst du das quantifizieren?

Ein LKW wird auch langsamer wenn eine Fliege während der Fahrt auf die Windschutzscheibe knallt.

Der_Korken

2020-08-13, 14:25:41

Kannst du das quantifizieren?

Das dürfte schwer werden, weil logischerweise weder Intel noch AMD eine x86-CPU gebaut haben, wo ein Teil des Befehlssatzes einfach fehlt. Und tieferes Wissen wie die Architektur auf Layout- oder Transistorebene aufgebaut ist, werden auch die wenigsten haben. Man kann vermuten, dass sowohl Intel als auch AMD wissen, welche Instruktionen quasi obsolet sind und ihre Dekoder so designeed haben, dass die wirklich relevanten Instruktionen da schnell durchkommen, während man irgendwelchen legacy Kram auch über langsame und lange Pfade schieben kann.

Brillus

2020-08-13, 14:32:17

Kannst du das quantifizieren?

Ein LKW wird auch langsamer wenn eine Fliege während der Fahrt auf die Windschutzscheibe knallt.

Das kann nur AMD/Intel/Via.

Lehdro

2020-08-13, 14:38:25

@Zephyroth
Nimm 7-zip. Einmal mit einem Thread und einmal mit allen, dividiert durch die Threadanzahl.
Fühl dich jetzt bitte nicht angegriffen, aber das klingt sowas von vermessen, weil es ein komplett theoretisches Szenario ist. Was bringt dir die Division durch den Threads bei einem Programm was komplett darauf basiert Multithreaded zu sein? Niemand nutzt sowas singlethreaded. Der Punkt des Fortschrittes ist es doch dass du heute 6 Kerne+ in 15W kriegst und damals nur 4 Kerne in 95W (4500U vs 2500K). Zumal die Packprogramme dafür bekannt sind mehr oder weniger stumpf mit Kernen, Cache und Bandbreite/IO zu skalieren. Wie willst du da deine IPC noch nachvollziehbar rausfiltern? Dazu müsstest du sämtliche Limits kennen und dann sicherstellen das keine der beiden CPUs in diese läuft (zb RAM Bandbreite etc) um zumindest den maximal möglichen Durchsatz vergleichen zu können. Außerdem, was willst du da vergleichen? Compression, Decompression? Gibt da durchaus große Unterschiede?
Aber versuchen wir es mal:
Wenn ich nach dem hier (https://www.7-cpu.com/) gehe, haben wir 3800/3400 MIPS vs 5930/8390 MIPS (wobei das nur Zen 2 ist, Renoir gibt es da noch nicht). Das sind mal schlappe 56% beim Komprimieren und gigantische 146% beim entpacken! Damit liegt die Steigerung teilweise sogar noch höher als bei deinem verschmähten Cinebench "PR" mit 71%. Und das alles Singlethreaded, ungeachtet der höheren Anzahl an möglichen Threads!
Anmerkungen:
Compression speed strongly depends from memory (RAM) latency, Data Cache size/speed and TLB. Out-of-Order execution feature of CPU is also important for that test.

Decompression speed strongly depends on CPU integer operations. The most important things for that test are: branch misprediction penalty (the length of pipeline) and the latencies of 32-bit instructions ("multiply", "shift", "add" and other). The decompression test has very high number of unpredictable branches. Note that some CPU architectures (for example, 32-bit ARM) support instructions that can be conditionally executed. So such CPUs can work without branches (and without pipeline flushing) in many cases in LZMA decompression code. And such CPUs can have some speed advantages over other architectures that don't support complex conditionally execution. Out-of-Order execution capability is not so important for LZMA Decompression.

Cinebench haben PR-Reviewer durchgesetzt.[...]
Da hat sich natürlich auch was getan, kommt aber meist nicht so verzerrt wie in all den PR-Reviews.
Was denn immer für "PR Reviews"? Was meinst du damit? Führe das mal bitte aus...

Zephyroth

2020-08-13, 15:39:44

Fühl dich jetzt bitte nicht angegriffen, aber das klingt sowas von vermessen, weil es ein komplett theoretisches Szenario ist.

Stimmt schon, aber Badesalz will ja was zeigen. Das sich bei den IPC nichts getan hat. Mag sein. Interessiert es jemanden? Vielleicht. Wenn ich nicht alles verlernt habe, wenn's ums Interpretieren von Benchmarks geht, dann rechne ich damit das der Ryzen 5 4500U meine Filme mit meinen Einstellungen statt bisher mit 24fps mit etwa 40fps rechnen wird.

Der Ryzen braucht dabei 15W, der i5-2500k etwa 100W (@4.3GHz). Für einen 2h Film rechnet der alte genau 2h, braucht also 200Wh, der Ryzen braucht nur 1:12h und kommt auf 18Wh. Das ist, was mich als Endverbraucher interessiert. Neben einer niedrigen Stromrechnung, wird das Haus im Sommer damit auch nicht geheizt, was wiederum heisst, die Klimaanlage braucht weniger Strom. Das sich die IPC kaum geändert haben und somit die Architektur keinen Fortschritt erzielt hat, ist mir in Anbetracht dessen ziemlich egal. Das vorgegebene Arbeitspensum wird gut 40% schneller erledigt und das mit nur 8% des ursprünglichen Energieverbrauchs.

Und das soll kein Fortschritt sein?

Der Fortschritt mag nicht in der IPC liegen, aber in der jetzt möglichen hohen Anzahl der Kerne und der daraufhin optimierten Software. Also wieso soll Core-Flood etwas schlechtes sein? Schon vor 20 Jahren bestanden Supercomputer aus deutlich mehr Prozessoren (wir reden da von mehreren Zehntausend). Sicher eine gewisse Single-Thread-Leistung ist ein muss, damit eben auch schlecht parallelisierbare Anwendungen noch passabel laufen. Aber dafür unterstelle ich mal, hat jeder heutige Rechenkern ab 2GHz mehr als ausreichend Power.

Für die Betreiber von Rechenzentren oder auch den einfachen Heimanwender sind die GFLOP/W deutlich interessanter. Und hier hat sich deutlich was getan.

Grüße,
Zeph

Dino-Fossil

2020-08-13, 15:51:25

Lehdro

2020-08-13, 16:03:03

Naja, was ist denn dann auch als IPC akzeptiert (jeweils allgemein und von Badesalz)?

Wenn ich einen Chip habe, der auch bei gleicher Frequenz bestimmte Aufgaben schneller abarbeitet, würde ich das ja in meiner naiven Vorstellung als höhere IPC (für diese Aufgabe) auffassen. Ob das jetzt daduch kommt, das der Cache vergrößert, Sprungvorhersagen verbessert oder neuere Befehlssätze implementiert wurden, ist da für das Endergebniss erstmal zweitrangig.
Da würde ich auch so mitgehen, vielleicht noch als Einschränkung dass das im Alltag auch so ankommen sollte. Extremfall: Wo ich dann mal sinnvoll die AVX 512 Karte ziehen kann mit der Intel regelmäßig hausieren gegangen ist, ist mir im Alltag auch noch nicht so wirklich klar. Da geht dann dieser Befehlssatz für mich völlig an der Praxis vorbei, weil seine Nützlichkeit (noch?) extrem eingeschränkt ist. Solche Spezialfälle gehen aber im Normalfall in den gemittelten IPC Steigerungen über eine große Bandbreite an Anwendungen in der Regel unter.

Zephyroth

2020-08-13, 16:07:24

Wenn ich einen Chip habe, der auch bei gleicher Frequenz bestimmte Aufgaben schneller abarbeitet, würde ich das ja in meiner naiven Vorstellung als höhere IPC (für diese Aufgabe) auffassen.

Ne, eben nicht. Er hat eine größere Rechenleistung. Wenn der Chip mehr Cores hat, dann wird er seine Aufgabe schneller erledigen können, obwohl er nicht effizienter ist.

Ein gutes Beispiel für die IPC waren damals die Pentium 4 gegen die Athlon 64, beides SingleCore-Prozessoren. Während man den P4 auf bis zu 3.8Ghz prügeln musste, erreichte der Athlon FX mit 2.4GHz schon ähnliche Leistungen. Die nachfolgende Core 2 - Architektur von Intel erreichte dann ähnliches, aufeinmal reichten da ebenfalls um die 2.5GHz aus.

Ich bin selbst weder blau (Intel) noch grün (AMD) gefärbt. Ich verwende den mir passenden Prozessor, was typischerweise auf hohe Anwendungsleistung, aber auch energetischer Effizienz abzielt. So bin ich eben von den P3 zu den Athlon XP geschwenkt. Weil Intel mit dem P4 nicht aus dem Quark kam, folgten dann noch Athlon 64 und Athlon X2, bis Intel mit dem Core 2 Duo wieder nach vorne zog. Bis Ryzen war Intel vorne, vorallem im Mobile-Bereich. Heute ist es so, das der Ryzen für mich die bessere Wahl ist. Deswegen ist es jetzt AMD. Kommt in fünf Jahren Intel wieder mit einem guten Prozessor kommt eben der wieder. Ähnlich war's auch bei meinen Grafikkarten, wo ich auch zwischen AMD und nVidia herumhüpfe wie es mir gefällt.

Grüße,
Zeph

Dino-Fossil

2020-08-13, 16:11:05

Ne, eben nicht. Er hat eine größere Rechenleistung. Wenn der Chip mehr Cores hat, dann wird er seine Aufgabe schneller erledigen können, obwohl er nicht effizienter ist.

Wobei ich noch vergessen habe: auch pro-Kern, denn die gestiegene Leistung ist ja durchaus oft nicht nur bei gut parallelisierten Aufgaben auf CPUs mit mehr Kernen vorhanden.
Beispiel: Auch mit nur einem Kern würde ein aktueller Ryzen einen alten Bulldozer locker abhängen.

Extremfall: Wo ich dann mal sinnvoll die AVX 512 Karte ziehen kann mit der Intel regelmäßig hausieren gegangen ist, ist mir im Alltag auch noch nicht so wirklich klar.

Weswegen ich eben auch ein Stück weit nach der jeweiligen Aufgabe unterscheiden würde. Denn es ist wohl in der Tat Unsinn, pauschal zu behaupten CPU 1 hat eine höhere IPC als CPU 2 weil 1 AVX512 beherscht und damit in entsprechenden Aufgaben schneller ist (aber eben nur da), CPU2 aber nicht.
Muss man halt auch sehen, was man selbst üblicherweise so mit der CPU anstellen möchte, bzw. wie praxisrelevant die jeweiligen Befehssätze sind.

Brillus

2020-08-13, 16:22:41

Tobalt

2020-08-13, 17:11:45

Man kann den landläufig "IPC" genannten Wert auf zwei Arten sehen:

1) Der Peak-Wert, den eine CPU unter optimalen Aufgaben bei maximal befüllten Rechenwerken erreicht. Dies ist idR gut dokumentiert und objektiv vergleichbar. Dieser Wert steigt auch aktuell noch stark durch Vektorisierung, wenn man eine Vektor-OP als mehrere skalare OPs zählt.

2) Ich nenne es mal "Takteffizienz": Wieviele Taktzyklen eine CPU für eine bestimmte reale Aufgabe braucht. Auch CPUs mit identischer IPC gemäß (1) können sich hier unterscheiden, weil ihre Einheiten anders aufgeteilt sind und die Auslastung deshalb unterschiedlich ist. Dieser Wert hängt somit tatsächlich von der Aufgabe ab. Von zwei CPUs mit gleichen GFLOPS kann mal die eine, mal die andere, eine bestimmte reale Aufgabe in weniger Takten berechnen, je nach Aufgabe.

Der für Anwender oft relevante Wert ist nicht die IPC (1), sondern die Takteffizienz (2) gemittelt über "alle Apps". Da aber (2) vom Mix der Apps abhängt, kann sich die Takteffizienz auch mit der Zeit ändern - die IPC (1) hingegen nicht. Moderne Apps erzielen auf modernen CPUs eine höhere Takteffizienz als alte Apps. Umgekehrt schneiden alte CPUs in alten Apps nicht ganz so schlecht ab, wie in neuen Apps.

Man sieht hieran auch, dass die Takteffizienz nur dann stark weiter steigen kann, wenn die SOFTWARE mitzieht. Da können sich ARM oder auch Intel/AMD noch so verbiegen. Wenn die SOFTWARE nicht die breiten Rechenwerke nutzt und andere moderne Gegebenheiten, dann steigt die Takteffizienz kaum, obwohl die IPC deutlich höher ist als früher. Die Software zieht mit heißt: Parallelisierung, und zwar nicht im Sinne von Multithreading sondern innerhalb eines Threads.

Zephyroth

2020-08-13, 18:14:44

Schöne Erklärung!

Th3o

2020-08-13, 19:59:10

Software war schon immer hinter der Hardware. Das liegt daran, dass die Software auch auf älteren CPUs laufen muss und deshalb die neuesten Erweiterungen oft nicht einsetzt, weil sie eben nur bei einem kleinem Teil der CPUs vorhanden sind. Das ging bei MMX los und dann immer weiter.

Naitsabes

2020-08-13, 20:02:47

Je nach Definitionen (betrachtet man x86 Instruktionen oder interne risc-Instruktionen hinterm Decoder) müsste man auch µcode betrachten.

CPU1 kann einen Befehl in Hardware in einem Takt erledigen -> IPC = 1
CPU2 kann den Befehl nicht in einem Rutsch berechnen, sondern benötigt dafür zehn Instruktionen, die aber zum Teil auf mehreren Alus parallel laufen können. Für das Abarbeiten der Instruktionen braucht CPU2 5 Takte -> IPC = 2, bei gleichem Takt aber langsamer als CPU1

Umgekehrter Fall wäre das ganze OP-Fusion-Gedöns.

Badesalz

2020-08-13, 21:26:33

Und IPC über mehrere Kerne macht keinen Sinn sobald die unterschiedlich Takten.Da derartiges aber der Realität entspricht könnte man auch genauso aufhören der ausgedachten IPC-Anganben Beachtung zu schenken. Ich hab den O-Ton hier im Thread so verstanden, daß Programmen die sich nicht brauchbar parallelisieren lassen sowieso keine Beachtung geschenkt werden sollte, weil die laufen schon seit Core2Duo schnell genug. Wozu also mit IPC beschäftigen? Richtig?

Er schreibt doch das zB die Instruktionslatenz erhöht wird, weil die Decoder komplizierter als heute nötig sind.Für mich schreibt er da, daß es sein könnte. Eine These. Thesen sind wie Theorien. Irgendwann muss man entweder aufstehen und zusehen, daß man den Beweis findet oder man sollte aufhören darüber zu reden.
Wie liest ihr denn überhaupt immer und warum ist das sofort alles 100% richtig, nur weil es eine These ist die euch grad gut in den Kram passt. Ich verstehe sowas nicht.
Aufzeigen ist jetzt wieder so ein Ding.in der Situation wo es ein Problem gibt den man nicht zum Vorschein bringen kann, verliert die Sache den Status "Problem". Fertig.

Fühl dich jetzt bitte nicht angegriffen, aber das klingt sowas von vermessen, weil es ein komplett theoretisches Szenario ist. Was bringt dir die Division durch den Threads bei einem Programm was komplett darauf basiert Multithreaded zu sein?Nö. Andersrum. Die Entgegnung ist vermessen. Nach dem Urteil ;) wird erst gefragt was das soll. Das ist überheblicher Mist, wenn man sowas schon raushaut noch bevor man eine Antwort auf die Frage bekommt.
Man könnte auch ungeduldig sagen, aber das macht es nicht wirklich besser, weil dann sieht es so aus als wenn jemand ganz heiß wäre mit sowas um sich zu werfen und garnicht mehr abwarten kann bis er es endlich könnte. Daher hab ich erstmal die erste Option als wahrscheinlicher gewählt :up:

Zur der Sache: Man kann auch nur 1 Thread fahren und sich realere IPCs zusammenreimen. Ok. Ich hab dazu ja beide Vorschläge gemacht :) Das zweite finde ich aus technischer Sicht einfach interessant, weil beide ja nicht deckungsgleich sind und dan kann man sich mal anschauen was sich so allgemein tut mit Scheduling im Kernel, mit der Domänenerkennung von AMD (ab welchem Win10 Update nochmal?) usw. usw.
Grad das hätte eigentlich ins Bild passen müssen, weil sich auch da immer mal was tut und besser wird. Nenne es eine kleine Finte von mir um zu schauen, ob die Leute wirklich über alles nachdenken was sie quoten oder sich immer nur umgehend in ihren Beißreflexen festfahren.

Der_Korken

2020-08-13, 21:50:43

Für mich schreibt er da, daß es sein könnte. Eine These. Thesen sind wie Theorien. Irgendwann muss man entweder aufstehen und zusehen, daß man den Beweis findet oder man sollte aufhören darüber zu reden.
Wie liest ihr denn überhaupt immer und warum ist das sofort alles 100% richtig, nur weil es eine These ist die euch grad gut in den Kram passt. Ich verstehe sowas nicht.

in der Situation wo es ein Problem gibt den man nicht zum Vorschein bringen kann, verliert die Sache den Status "Problem". Fertig.

Um das zu beweisen oder widerlegen, müsste eine ganze Menge Menschen aufstehen, ein paar Milliarden Dollar und ein Paar Jahre Zeit in die Hand nehmen, ein eigenes CPU-Design entwickeln und es dann benchen. Dass das Dekodieren von Befehlen potenziell einfacher wird, wenn den Befehlssatz verkleinert, ist vollkommen logisch. Schlimmstenfalls ist es genauso schwer wie vorher, schwerer wird es auf keinen Fall. Dass ein simplerer Dekoder potenziell weniger tief (im Sinne von Schaltkreis) ist, ist auch trivial. Auch hier bleibt es schlimmstenfalls genauso wie vorher. Ob diese Sachen auch tatsächlich eintreffen, kann aber niemand beantworten, der so ein Design nicht schonmal detailliert von innen gesehen hat.

Was ich aber nicht verstehe ist, warum man darüber nicht diskutieren soll. Was heißt "These die euch gut in den Kram passt"? Welche These denn genau? Dass die Dekoder-Latenz sinkt, wenn man das Instruktion set entschlackt? Und was soll uns da gut in den Kram passen? Ich finde sie logisch begründet und ich habe weder Intel- noch AMD- noch ARM-Aktien, d.h. ich habe keine Interessenskonflikte mit irgendwelchen Thesen, falls das damit gemeint ist.

Badesalz

2020-08-13, 22:20:58

@Der_Korken
Was ich aber nicht verstehe ist, warum man darüber nicht diskutieren soll. Was heißt "These die euch gut in den Kram passt"? Welche These denn genau? Dass die Dekoder-Latenz sinkt, wenn man das Instruktion set entschlackt?Von "nicht soll" war nicht die Rede. Es war die Rede von Thesen de auf nächtlichen Fantasien basieren:
Ich wäre da erstmal nicht DERMASSEN überheblich. Du weißt noch garnicht, ob die s.g. Altlasten nicht über µcode erledigt werden und es garkeine negativen Effekte auf Dekoder-Latenzen gibt. Oder eben umgekehrt (ich verneine wie so oft nichts)

Ok wenn du es weißt dann natürlich her damit. Das wäre echt mal was klar ergibiges hier.

DAS sollte wenigstens also klar sein, wie primeval-legacy überhaupt abgearbeitet wird, BEVOR man darüber redet. Das gibt dem erstmal überhaupt eine Grundlage zum Thema zu werden. Sonst ist das so sinnvoll wie die Unterhaltung darüber wie schnell RT auf RTX denn hätte sein können, wenn keine DX9-Spiele mehr auf den RTX lauffähig wären :uup: Oder USB3 Controller, wenn sie kein USB1 mehr könnten...

(und alle jetzt am googeln wegen RTX und DX9 :D)

Lehdro

2020-08-13, 22:27:24

Nö. Andersrum. Die Entgegnung ist vermessen.
Ansichtssache, ich sehe da die Praxis als deutlich wichtiger an als die Theorie. Theorie interessiert den Anwender (Bringt CPU A mehr als CPU B?) nur insoweit wie das real in der Praxis auch ankommt. Und da ist IPC nur ein Puzzleteil von vielen.

Außerdem habe ich dir dein Beispiel 7zip mit Werten unterlegt, was aber von dir mit keinem Wort gewürdigt wurde. Vielleicht ist CB doch nicht so "PR" wie du meinst, sondern bildet für einen so schnellen Test doch die Grundperformance recht grob, aber zuverlässig ab?

Zossel

2020-08-13, 22:38:24

CPU1 kann einen Befehl in Hardware in einem Takt erledigen -> IPC = 1
CPU2 kann den Befehl nicht in einem Rutsch berechnen, sondern benötigt dafür zehn Instruktionen, die aber zum Teil auf mehreren Alus parallel laufen können. Für das Abarbeiten der Instruktionen braucht CPU2 5 Takte -> IPC = 2, bei gleichem Takt aber langsamer als CPU1

Beachte auch Latenz und Throughput einer Instruktion. Eine Instruktion kann 10 Takte brauchen aber in jedem Takt können 2 neue gestartet werden.

IPC ist auch nur Kaffesatzleserei, ich schlage daher den Begriff "Rumms" vor, da kommt man weniger auf die Idee das das irgentwas präzises sein könnte.

Badesalz

2020-08-13, 22:45:35

@Lehdro
Außerdem habe ich dir dein Beispiel 7zip mit Werten unterlegt, was aber von dir mit keinem Wort gewürdigt wurde. Vielleicht ist CB doch nicht so "PR" wie du meinst, sondern bildet für einen so schnellen Test doch die Grundperformance recht grob, aber zuverlässig ab?
Du hast nach CB verlinkt? :|
Brauchst du immer jemanden der dich an die Hand nimmt bzw. eine genaz vermeintliche VIP-Kolone mit der du deine Thesen untermauerrn könntest? Ich halte von unserem (3DC) Benchthreads mit Screenshots und HW-Angaben, um Universen mehr als von Tests irgendwlecher wildfremden Gestalten.

Theorie interessiert den Anwender (Bringt CPU A mehr als CPU B?) nur insoweit wie das real in der Praxis auch ankommt.Aha :tongue: Das, worüber wir hier philosophieren und plötzlich zaubert einer den 0815 Anwender aus dem Hut :freak: Wenn dich nur die Sorgen des 0815 Anwenders interessieren, bist du im falschen Thread. Und bevor du überhaupt aufklärst was denn alles für den vom Interesse ist, hat der sich einen Ipad bestellt...

IPC ist auch nur Kaffesatzleserei, ich schlage daher den Begriff "Rumms" vor, da kommt man weniger auf die Idee das das irgentwas präzises sein könnte.Ist doch genau meine Meinung =)
Du brauchst aber was greifbares um sich dran aufzugeilen. Da hat die PR-Branche samt PR-Portalen irgendwann eben noch zusätzlich IPC entdeckt. Man kann Steigerungen in % herbeifantasieren und die Leute aufheizen, mit welchen ich mich dann auf 3DC rumplagen muss :wink:

Bis moin.

Naitsabes

2020-08-13, 23:01:04

Beachte auch Latenz und Throughput einer Instruktion. Eine Instruktion kann 10 Takte brauchen aber in jedem Takt können 2 neue gestartet werden.

IPC ist auch nur Kaffesatzleserei, ich schlage daher den Begriff "Rumms" vor, da kommt man weniger auf die Idee das das irgentwas präzises sein könnte.

Stimmt natürlich, ich wollte mit einem einfachen Beispiel zeigen, dass ohne genaue Definition worüber man überhaupt diskutieren möchte, eine Diskussion eigentlich unnötig ist :ubeer:

Aber ja. wenn man alle Eventualitäten betrachten möchte, dann kann man sich ja einfach die Compiler/Assembly-Optimierungsguides von Agnar Fog durchlesen. Dürften paar hundert, eher tausend Seiten sein.

Badesalz

2020-08-13, 23:06:32

p.s.:
Agnar wäre jetzt mit Atombomben auf Spatzen. Soweit sind wir wenn ab jetzt alles rund laufen sollte vielleicht in 4 Wochen...

Brillus

2020-08-13, 23:34:15

Da derartiges aber der Realität entspricht könnte man auch genauso aufhören der ausgedachten IPC-Anganben Beachtung zu schenken. Ich hab den O-Ton hier im Thread so verstanden, daß Programmen die sich nicht brauchbar parallelisieren lassen sowieso keine Beachtung geschenkt werden sollte, weil die laufen schon seit Core2Duo schnell genug. Wozu also mit IPC beschäftigen? Richtig?

Du machst den selben Fehler wie Dino-Fossil du verwechselst IPC und Performance.

Und dann kommen sonst ganz seltsame Sachen hin wie das du auf der einen Seite Befehlserweiterungen (AVX) ignorieren willst aber dann auf der anderen Seite kommst mit IPad kann aber H.264 flüssig, was da aber fixed Functions sind also Befehlserweiterungen auf Steroide.

Dino-Fossil

2020-08-13, 23:56:11

Du verwechselst IPC und Performance. Anderer Befehlssatz ändert nicht an der IPC direkt. Es veringert die Instruktion die man benötig.

Und IPC über mehrere Kerne macht keinen Sinn sobald die unterschiedlich Takten.

Was wäre denn dann die korrekte Definition von IPC?

Der_Korken

2020-08-14, 00:22:07

Von "nicht soll" war nicht die Rede.

Da du hier jedes Wort auf die Goldwaage legst, halte ich dir mal deinen eigenen Post unter die Nase. Zitat: "Irgendwann muss man entweder aufstehen und zusehen, daß man den Beweis findet oder man sollte aufhören darüber zu reden."

Es war die Rede von Thesen de auf nächtlichen Fantasien basieren:
Ich wäre da erstmal nicht DERMASSEN überheblich.

Sorry, aber schau erstmal selbst in den Spiegel. Wo ist konkret die Sache mit der Dekoder-Latenz eine nächtliche Phantasie? Was ist daran so unplausibel?

Du weißt noch garnicht, ob die s.g. Altlasten nicht über µcode erledigt werden und es garkeine negativen Effekte auf Dekoder-Latenzen gibt. Oder eben umgekehrt (ich verneine wie so oft nichts)

Ok wenn du es weißt dann natürlich her damit. Das wäre echt mal was klar ergibiges hier.

Ich habe das Wort "potenziell" zweimal unterstrichen in meinem Post. Aber hauptsache anderen ständig im Thread vorwerfen, sie würden nicht richtig lesen. Abgesehen davon war vom Dekodieren die Rede, da gibt es noch gar keine µ-Ops (ich nehme an dass du das mit "µcode" meinst, denn Mikro-Code passt hier im Kontext nicht). Die Latenz steigt möglicherweise dadurch, dass mehr Fallunterscheidungen gemacht werden müssen, wenn der Prozessor mehr Instruktionen verarbeiten können muss. Ich weiß nicht wie die Logik innerhalb moderner Architekturen aussieht, vielleicht nimmt die max. Tiefe der Schaltung gar nicht ab, wenn man ein paar alte Instruktionen weglässt. Dann hat man nichts gewonnen, aber verlieren tut man in keinem Fall was. Wieviel hier zu holen ist, wird aber niemand hier im Forum beantworten können, sofern wir hier nicht zufällig Intel- oder AMD-Mitarbeiter haben.

@Lehdro

Du hast nach CB verlinkt? :|
Brauchst du immer jemanden der dich an die Hand nimmt bzw. eine genaz vermeintliche VIP-Kolone mit der du deine Thesen untermauerrn könntest?

Nein, hat er nicht, hier: https://www.forum-3dcenter.org/vbulletin/showthread.php?p=12390805#post12390805

Vielleicht "brauchst du immer jemanden der dich an die Hand nimmt"?

Du brauchst aber was greifbares um sich dran aufzugeilen. Da hat die PR-Branche samt PR-Portalen irgendwann eben noch zusätzlich IPC entdeckt. Man kann Steigerungen in % herbeifantasieren und die Leute aufheizen, mit welchen ich mich dann auf 3DC rumplagen muss :wink:

Sorry, da fällt einem wirklich nichts mehr zu ein. IPC wurde nicht durch ein PR-Portal entdeckt, sondern das ist ein allgemeiner Begriff aus dem Bereich der Mikroarchitektur. Und natürlich kannst du es auch in diesem Post nicht unterlassen, andere Leute zu beleidigen. Was für eine Shitshow.

Was wäre denn dann die korrekte Definition von IPC?

Ich glaube der Begriff ist sehr dehnbar und auch schwer zu greifen. Umgangssprachlich meint man damit schon sowas wie "bumms pro Takt", zumindest gehe ich immer davon aus, dass Leute das meinen. Vom Wortlaut her sind es Instruktionen pro Taktzyklus, die Frage ist nur, was man als Instruktion bezeichnet. Der Einwand von Brillus ist natürlich berechtigt, dass wenn man Instruktionen durch AVX zusammenfasst, man dadurch weniger Instruktionen hat und somit die IPC nicht gestiegen sind. Wenn man aber bei Vektoroperationen jedes 64-bit-Teilwort als eigene Instruktion zählt, dann wäre die IPC sehr wohl gestiegen.

Tobalt

2020-08-14, 00:29:22

Gemäß dem Wortlaut: Wieviele Instruktionen kann der Decoder pro Takt laden (und an die Rechenwerke weitergeben)

Mein letzter Post ist vor dem Hintergrund auch falsch. Ich meine in meinem ersten Absatz nicht Instruktionen pro Takt, sondern Operationen pro Takt.

Ist letzlich aber auch egal, weil der landläufige Diskussionsgegenstand "IPC" weder die Instruktionen pro Takt, noch die Operationen pro Takt meint, sondern das, was ich in meinem letzten Post "Takteffizienz" genannt habe und was Zossel vermutlich mit "Rumms" meint. Edit: und Der_Korken mit "bumms pro Takt"

Hier eine Übersicht an Instruktionen pro Sekunde: https://en.wikipedia.org/wiki/Instructions_per_second
Man sieht tendenziell schon, dass neuere CPUs mehr dekodieren können pro Takt. Wenn man aber mal zwischen den einzelnen Generationen direkt vergleicht, dann wird schnell klar, dass zwischen Instruktionen pro Takt und der taktnormierten Performance keine gute Korrelation mehr herrscht seit mehreren Jahrzehnten.

=Floi=

2020-08-14, 03:54:34

Ich hab den O-Ton hier im Thread so verstanden, daß Programmen die sich nicht brauchbar parallelisieren lassen sowieso keine Beachtung geschenkt werden sollte,

Es gibt im gaming bereich ein paar gute beispiele, wo ein neuer renderer wunder vollbrachte. Weil er effizienter war, oder weil er MT war.
Gothic 2 korins. Outcast. Bei minecraft boostet optifine auch extrem gut die engine. Ogl sachen werden mit dem vulkan renderer richtig gut beschleunigt.

Hier brachte ein optimieren der software performance und am ende vom tag wird vieles auf MT hinauslaufen.

Badesalz

2020-08-14, 08:14:34

Da du hier jedes Wort auf die Goldwaage legst, halte ich dir mal deinen eigenen Post unter die Nase.Aha. Wie unbeholfen...

Ich habe das Wort "potenziell" zweimal unterstrichen in meinem Post.Das gilt. Das befähigt aber nicht die Diskussion darüber so aufziehen zu wollen, als wenn das eine längst bewiesene Binseweisheit wäre :|

Nein, hat er nicht, hier:Das hab ich gesehen. Der Kontext zu CB ist mir damit nicht klar. Überschlag dich mal nicht.

Sorry, da fällt einem wirklich nichts mehr zu ein. IPC wurde nicht durch ein PR-Portal entdeckt, sondern das ist ein allgemeiner Begriff aus dem Bereich der Mikroarchitektur.Du kriegst das nicht verarbeitet oder? Mit "entdeckt" ist natürlich nicht ausgedacht und das erste mal verwendet.. Ich rede von Begriffsmissbrauch. Überschlag dich nicht...

...Und natürlich kannst du es auch in diesem Post nicht unterlassen, andere Leute zu beleidigen. Was für eine Shitshow....auch mit deiner gespielten Überempfindlichkeit nicht.

Zephyroth

2020-08-14, 08:33:00

Aber ja. wenn man alle Eventualitäten betrachten möchte, dann kann man sich ja einfach die Compiler/Assembly-Optimierungsguides von Agnar Fog durchlesen. Dürften paar hundert, eher tausend Seiten sein.

Softwareoptimierung. Ist imho unglaublich wichig.

Das heftigste was ich je gesehen habe, war der Vergleich von Lame und Gogo, beides MP3-Encoder, wobei Gogo eine händisch assembler optimierte Variante war, sprich der Algorithmus dahinter war derselbe.

Mein damaliger Rechner konnte ein 4min Lied mit Lame in etwa 1min encodieren (ich glaub' es war mein Athlon XP 1800+). Dann hab' ich Gogo ausprobiert und siehe da, das gleiche Lied, war in selber Qualität in 10sec (!) encodiert. Das ist ein Faktor 6. Gemessen daran konnte selbst der damals schnellste Prozessor (P4 3.4GHz Northwood) nichts dagegen ausrichten, solange er selbst nur mit Lame encodiert.

Genauso läuft's heute auch. Die Software muss den Prozessor so gut wie möglich ausnutzen, sonst geht nix weiter. Wenn ich 10 Arbeiter habe, aber der Vorarbeiter (die Software) nur in der Lage ist einen zu befehligen, dann kommt man eben nicht weiter.

IPC ist beim Prozessor in etwa das Äquivalent zum effektiven Mitteldruck beim Verbrennungsmotor. Interessant für Leute die sich mit Motorenbau beschäftigen, für den Endanwender, der schlicht und einfach Endgeschwindigkeit und Beschleunigung haben will unbedeutend. Leistung kann man mit wenig Mitteldruck und Drehzahl (=Takt) erzeugen, man erhöht den Hubraum (=Busbreite) oder verbaut mehr Zylindereinheiten (=Cores). Alles führt zum gewünschten Ergebnis. Wo der Sweetspot liegt, hängt von den umwelttechnischnen Auflagen (Verbrauch, Emissionen) ab, kurz dem Anwendungsfall um wieder beim Prozessor zu landen.

Sich eine Größe (IPC) rauszupicken und daran den Forschritt zu messen, ist das gleiche wie wenn ich sage die Motoren haben sich kaum weiterentwickelt, weil ein Benziner nach wie vor seit über 30 Jahren maximal zwischen 6000-7000U/min dreht. Oder um auf das Äquivalent IPC zurückzukommen (das ist Badesalz' Methode): Man nehme einem modernen 2l-Turbo-R4, nimmt ihm seinen Turbo, die Direkteinspritzung und baut einen Vergaser ran (sprich nimmt der CPU die Befehlsextensions), schaltet 3 Zylinder (3 Cores) ab und stellt fest, das der verbleibende Zylinder immer noch nicht mehr als 70Nm/l liefert, so wie auch schon vor 40 Jahren.

Grüße,
Zeph

Brillus

2020-08-14, 10:26:50

Was wäre denn dann die korrekte Definition von IPC?

IPC = Instructions per clock. Und dabei geht um die Durchschnittliche Menge damit auch so Sachen wie Missperdiction Penalty und Pipelinestalls z.b. wegen Warten auf Memory betrachtet werden kann.

Wie schon gesagt Befehlssätze reduzieren die Anzahl der Instruktionen die eine Aufgabe benötigt.

Schnäppchenjäger

2020-08-14, 10:31:51

Tja, die Software muss sich halt weiterentwickeln damit man mehr Ertrag aus deren Performance ziehen kann.
Immer wieder die Hardware zu verbessern während die Software hinterherhinkt ist auch nicht unbedingt der Weisheit letzter Schluss :redface:

Lehdro

2020-08-14, 14:16:22

Du hast nach CB verlinkt? :|
Wurde ja Gott sei dank schon geklärt, echt peinlich. Aber immerhin weiß ich dass du nur bellst und nicht beißt, sonst wäre dir der Link aufgefallen und du hättest den Vergleich zwischen der Verbesserung der Leistung im ST CB und den Fortschritten in 7zip ST erkannt. Ist ja nicht so als wäre das nicht ausformuliert (https://www.forum-3dcenter.org/vbulletin/showpost.php?p=12390805&postcount=105) gewesen.

Aha :tongue: Das, worüber wir hier philosophieren und plötzlich zaubert einer den 0815 Anwender aus dem Hut :freak: Wenn dich nur die Sorgen des 0815 Anwenders interessieren, bist du im falschen Thread.
Du solltest im Kontext lesen, immerhin ging dieser ganze Thread aus genau dieser speziellen Frage heraus hervor. Also durchaus relevant. Es ging hier schon immer explizit um CPU A vs CPU B. :redface:

Sogar ein Post (https://www.forum-3dcenter.org/vbulletin/showpost.php?p=12390461&postcount=91) vor meinem behandelte die Steigerung eines 4500u vs 2500k im CB, was du als "PR" abgetan hast und damit die Diskussion erneut derailt hast. Keine Ahnung worauf du hier eigentlich hinauswolltest, aber anhand deines eigenen 7zip Beispieles habe ich dir den Fehler deiner Argumentation deutlich aufgezeigt, da jenes von "ähnlich gut" bis "nochmals deutlich besser" skaliert - Singlethreaded und ungeachtet des Kernvorsprungs. Alles was danach von dir noch kam erinnert mehr an Dampfplauderei als an Argumentation - du scheinst dir selbst nicht schlüssig zu sein was du hier eigentlich sagen willst: Mal sind neue Instruktionen toll, mal darf man sie nicht berücksichtigen. Dann ist Fortschritt toll, dann aber bitte nur isoliert auf Single Thread aber ohne Fertigung und Taktraten. Was ist denn nun dein Punkt? :confused:
Ich sehe das so: Natürlich bringen neue CPUs auch mehr Leistung, sogar trotz deiner argumentativ hingeworfenen Einschränkungen!

Nightspider

2020-08-14, 14:19:36

Gipsel

2020-08-14, 14:30:56

Ich finde den Thread irgendwie dämlich.Oder um die Frage im Threadtitel einfach zu beantworten:
Ja.

Geächteter

2020-08-14, 15:44:28

Troy: A Total War Saga im Test: Extremes Gras lässt selbst 16 Kerne schwitzen

https://www.computerbase.de/2020-08/troy-a-total-war-saga-benchmark-test/

Von solchen Spielen wird es immer mehr geben.

Ich finde den Thread irgendwie dämlich.

Wäre so ein Grashalm-Rendering nicht besser auf der GPU aufgehoben?
Dass schon lange die CPUs nicht mehr wirklich schneller werden, merkt man bei beispielsweise der AI und der gamerelevanten Physik. Da tut sich schon lange gar nix mehr und wenn paar Simulationen dies mehr reizen, bekommt man auch mit zig Kernen schnell tiefe fps.

Zossel

2020-08-14, 19:42:33

Das heftigste was ich je gesehen habe, war der Vergleich von Lame und Gogo, beides MP3-Encoder, wobei Gogo eine händisch assembler optimierte Variante war, sprich der Algorithmus dahinter war derselbe.

Und die Ausgabe beider Tools war identisch? Nachgeprüft?

Zephyroth

2020-08-14, 19:47:19

Bittechnisch habe ich es nicht überprüft. Das ganze oft gut 20 Jahre her, damals haben mich solche Feinheiten wenig interessiert. Soundtechnisch war kein Unterschied zu hören.

Benutzername

2020-08-14, 19:47:21

Wäre so ein Grashalm-Rendering nicht besser auf der GPU aufgehoben?
Dass schon lange die CPUs nicht mehr wirklich schneller werden, merkt man bei beispielsweise der AI und der gamerelevanten Physik. Da tut sich schon lange gar nix mehr und wenn paar Simulationen dies mehr reizen, bekommt man auch mit zig Kernen schnell tiefe fps.

Je mehr Objekte physikalisch simuliert interagieren, desto mehr Rechenaufwand ist nötig. Leider nicht linear, sondern exponentiell. sprich pack ein paar mehr Physikobjekte ins spiel und der Rechenbedarf explodiert.

Geächteter

2020-08-14, 20:43:34

Je mehr Objekte physikalisch simuliert interagieren, desto mehr Rechenaufwand ist nötig. Leider nicht linear, sondern exponentiell. sprich pack ein paar mehr Physikobjekte ins spiel und der Rechenbedarf explodiert.
Und wenn viel oder alles miteinander agieren kann, dann ist auch wohl Multithreads nicht oder nur stark eingeschränkt möglich. Oder kurz, für bessere/realitätsnähere Games braucht es deutlich schnellere Single-Core-Leistung. Crysis 1 ist ja bis heute der Höhepunkt der Physik gewesen. Noch nicht mal wurde von dort an das Level gehalten.
Einzig was jetzt bald realitätsnäher wird, ist die Beleuchtung, weil wohl schön parallelisierbar.
Und die Vielkern-CPU-Fraktion kann sich dann aufgeilen, wenn "Next-Gen-Konsolenportemulationen" die Kerne "sinnvoll" nutzen werden oder die Altmetall-Engine bei Troy die Schatten berechnet.

Zossel

2020-08-14, 20:58:21

Bittechnisch habe ich es nicht überprüft. Das ganze oft gut 20 Jahre her, damals haben mich solche Feinheiten wenig interessiert. Soundtechnisch war kein Unterschied zu hören.

Dann ist das eine Nullaussage.

Tobalt

2020-08-14, 23:02:15

Und wenn viel oder alles miteinander agieren kann, dann ist auch wohl Multithreads nicht oder nur stark eingeschränkt möglich. Oder kurz, für bessere/realitätsnähere Games braucht es deutlich schnellere Single-Core-Leistung.

Kannst du das irgendwie belegen ?

In wissenschaftlichen physikalischen Simulationen kann und soll ja auch alles mit allem interagieren. Solche Rechnungen sind derart gut parallelisierbar, dass sie auf Server Clustern durchgeführt werden.

Opprobrium

2020-08-14, 23:15:44

Und wenn viel oder alles miteinander agieren kann, dann ist auch wohl Multithreads nicht oder nur stark eingeschränkt möglich.
Ich glaube hier liegt eine Fehlkonzeption der Geschwindigkeit, mit der Dinge wie wir sei wahrnehmen können miteinander interagieren, und den Zeitspannen, die in der parallelen Berechnung dieser Ereignissen bei multiplen multi-GHz Dies möglich sind ;) Gerade bei Interaktionen ist es doch sinnvoll, wenn nicht immer erst gewartet werden muss bis die nächste Berechnung ansteht.

RaumKraehe

2020-08-14, 23:39:55

Wäre so ein Grashalm-Rendering nicht besser auf der GPU aufgehoben?
Dass schon lange die CPUs nicht mehr wirklich schneller werden, merkt man bei beispielsweise der AI und der gamerelevanten Physik. Da tut sich schon lange gar nix mehr und wenn paar Simulationen dies mehr reizen, bekommt man auch mit zig Kernen schnell tiefe fps.

Die Realität zeigt eigentlich ziemlich eindeutig das deine Aussage nicht korrekt ist.

Gipsel

2020-08-15, 13:31:22

Im Sandybridge-Thread wurde ein netter Test verlinkt (https://www.forum-3dcenter.org/vbulletin/showthread.php?p=12392494#post12392494), der auch hier eine gewisse Relevanz zeigt. Dort wird (unter Anderem) ein Sandybridge i7-2600K (4C/8T, 3,4-3,8GHz) mit einem Ryzen3 3300X (4C/8T, 3,8-4,3Ghz) mit verschiedenen GPUs und Spielen verglichen. Die möglichen Performancesteigerungen sind wenig überraschend dann doch oft ganz erheblich (das Extrem ist dabei wohl SotTR mit fast Performanceverdopplung).

https://abload.de/img/whyamdneededryzentowoa3jc9.png

Cc5mchDdNdg

Windi

2020-08-15, 15:46:52

Der wichtigste Grund, weshalb sich die Leistung der einzlnen Kerne nur langsam weiter entwickelt, wird wohl der deutlich gesenkte Stromverbrauch sein.

Vor langer, langer Zeit, zu Zeiten von AthlonXP und Pentium3 bestanden die CPUs nur aus einem einzigen Kern und haben am Ende über 100W benötigt.
Aber dann kam halt die Erkenntnis auf, das man im Mobilen- und Serverbereich viel mehr Geld machen kann und dafür musste der Stromverbrauch massiv gesenkt werden.

Ein Renoir mit 15W hat pro Kern im Durchschnitt nur etwas über 1W zur Verfügung. Die GPU, IF, Speicherkontroller, PCIe Lanes, USB Anschlüsse brauchen halt auch Strom.
Bei Epyc mit 200W sieht es ähnlich aus. Wenn man dort 8 Speicherkontroller und 128 PCIe Lanes mit Strom versorgen will, dann bleiben für die 64 Kerne kaum mehr als 2W pro Kern übrig.
Im Desktop hat man eh den Eindruck, das man Kerne, die für den Betrieb bei 2W optimiert wurden, stark übertaktet betreibt. Im Vergleich zu einem Renoir verbrauchen die Ryzen deutlich mehr Strom bei nur leicht erhöhter Rechenleistung.

Leistung benötigt halt Leistung!
Und dafür müssen die Kerne dann auch wieder ausgelegt werden!
Solange aber der Mobile-, Workstation- und Servermarkt den Ton angibt, wird sich daran nicht viel ändern.
Etwas Hoffnug keimt bei mir in der Erkenntnis, das der Stromverbrauch pro Kern in Zukunft nicht mehr großartig sinken muss. Beim Akkuverbrauch der Notebooks hapert es immer seltener an der CPU und bei der Kernanzahl muss erst einmal die Software hinterher kommen.
Eine andere Lösung wäre Big.Little.
Müsste man zusätzlich zu den normalen Kernen nur 2 weitere extreme Turbokerne mit Strom versorgen, dann könnte man diese natürlich auch viel größer auslegen. Zehn mal so viel Stromverbrauch und zehn mal so viel Transistorenverbrauch ist halt nicht so schlimm, wenn die Anzahl begrenzt ist und man sie deaktivieren kann, wenn man sie nicht benötigt.
Aber diese neuen dicken Kerne müssen auch erst einmal entwicket werden. Und das nebenbei zu den normalen Kernen (Und vieleicht zukünftige Stromsparkernen). Das kostet ein Vermögen.

Natürlich sind die heutien CPUs deutlich schneller als die Alten, das steht ausser Frage.
Es könnte halt noch mehr sein, wenn man im Desktop richtig große Kerne hätte und keine kleinen Energiesparwunder, die für den Dektop ab Werk bis zur Kotzgrenze übertaktet werden.

Opprobrium

2020-08-15, 16:13:01

Der wichtigste Grund, weshalb sich die Leistung der einzlnen Kerne nur langsam weiter entwickelt, wird wohl der deutlich gesenkte Stromverbrauch sein.
Hier ist aber ein großer Faktor, daß die CPUs schlicht besser geregelt werden: Der Takt wird im Idle sehr weit gedrosselt, Teilbereiche der CPU werden komplett abgeschaltet etc.

Natürlich gab es auch abseits davon deutlich Effizienzgewinne, aber (um mal wieder zum Autovergleich zurückzukommen), die neuen CPUs schalten sich an einer Ampel einfach weiter ab, während die alten CPUs oftmals den Motor laufen ließen oder gar mit durchgedrückter Kupplung aufs Gaspedal gedrückt haben um den Fahrer nebenan zu beeindrucken.

Windi

2020-08-15, 16:30:51

Hier ist aber ein großer Faktor, daß die CPUs schlicht besser geregelt werden: Der Takt wird im Idle sehr weit gedrosselt, Teilbereiche der CPU werden komplett abgeschaltet etc.
Natürlich gab es in dem Bereich sehr große Fortschritte.

Aber ich denke einmal, das es auch einen sehr großen Unterschied macht, wenn die Kerne um 90% schrumpfen.
Der AthlonXP "Palomino" war 120mm² groß.
Der AthlonXP "Thoroughbred " war 80mm² groß.
Der AthlonXP "Barton" war 100mm² groß.

Ein Zen2 Kern hat nur noch ein zehntel dieser Fläche zur Verfügung. Das muss Auswirkungen beim Stromverbrauch und bei der Leistung haben.

woodsdog

2020-08-15, 16:31:33

Hier ist aber ein großer Faktor, daß die CPUs schlicht besser geregelt werden: Der Takt wird im Idle sehr weit gedrosselt, Teilbereiche der CPU werden komplett abgeschaltet etc.

Natürlich gab es auch abseits davon deutlich Effizienzgewinne, aber (um mal wieder zum Autovergleich zurückzukommen), die neuen CPUs schalten sich an einer Ampel einfach weiter ab, während die alten CPUs oftmals den Motor laufen ließen oder gar mit durchgedrückter Kupplung aufs Gaspedal gedrückt haben um den Fahrer nebenan zu beeindrucken.

Hier gehts IMO schon irgendwie um Verbrauch bei Last, wenn die Kerne etwas tun müssen. Und da hat Windi mit seinem klasse Post den Nagel auf den Kopf getroffen.

Opprobrium

2020-08-15, 17:06:05

Hier gehts IMO schon irgendwie um Verbrauch bei Last, wenn die Kerne etwas tun müssen. Und da hat Windi mit seinem klasse Post den Nagel auf den Kopf getroffen.
Ich wollte ihm auch überhaupt nicht widersprechen :smile: Hätte vielleicht ein "auch" in den Post einfügen sollen.

mboeller

2020-08-15, 17:33:11

Eine andere Lösung wäre Big.Little.

Bei AMD wäre aber ein ZEN3-Kern wie im kommenden Cezanne der "big" Core und so was wie ein Jaguar der "little" Core.

Breiter als ZEN3 oder wie die großen Intel-Core lohnt sich eigentlich nicht.

edit:
ein ZEN2 Core hat in 7nm 3,64mm² ohne L3, 8 ZEN2 im Renoir also <30mm² bei einem 156mm² Die. Man spart sich durch die "little" Cores also nur sehr wenig Die-Area. Und wenn die Kerne nicht benötigt werden verbrauchen sie auch nix. Was big-little bringen wird ... mal sehen.

Windi

2020-08-15, 19:05:04

Bei AMD wäre aber ein ZEN3-Kern wie im kommenden Cezanne der "big" Core und so was wie ein Jaguar der "little" Core.

Breiter als ZEN3 oder wie die großen Intel-Core lohnt sich eigentlich nicht.

Ich bin natürlich kein Experte auf dem Gebiet, aber wenn man schafft einen Kern zu bauen, der 50% mehr Leistung hat, dann wäre das ein enormer Fortschritt. Selbst wenn dieser Kern dann 5 Mal so groß wäre und 5 Mal so viel Strom bräuchte.
Wie gesagt, ich bin kein Experte, aber man hört schon davon, das es noch einige Möglichkeiten zur Leistungssteigerung gibt.

Ein oder zwei solcher Kerne könnten eine CPU schon deutlich beschleunigen, vor allem wenn die meiste Software einen kritischen Thread hat, der die meiste Leistung benötigt und nicht parallelisiert werden kann.

Langlay

2020-08-15, 19:20:05

Ich bin natürlich kein Experte auf dem Gebiet, aber wenn man schafft einen Kern zu bauen, der 50% mehr Leistung hat, dann wäre das ein enormer Fortschritt. Selbst wenn dieser Kern dann 5 Mal so groß wäre und 5 Mal so viel Strom bräuchte.
Wie gesagt, ich bin kein Experte, aber man hört schon davon, das es noch einige Möglichkeiten zur Leistungssteigerung gibt.

Ein oder zwei solcher Kerne könnten eine CPU schon deutlich beschleunigen, vor allem wenn die meiste Software einen kritischen Thread hat, der die meiste Leistung benötigt und nicht parallelisiert werden kann.

Bei 5x der Leistungsaufnahme würde so ein Kern ~60W verbrauchen mit 2 solcher Kerne wäre dann auf das Powerbudget von 142W fast erreicht ( 120W für die 2 Kerne +15-20W für das IO Die).

Windi

2020-08-15, 21:46:21

Bei 5x der Leistungsaufnahme würde so ein Kern ~60W verbrauchen mit 2 solcher Kerne wäre dann auf das Powerbudget von 142W fast erreicht ( 120W für die 2 Kerne +15-20W für das IO Die).
Ja, wenn man von einem Ryzen 3800X mit 105W ausgeht, hört sich das katastrophal an.
Aber es gibt halt noch andere Zen2 Modelle. Seien es die 65W Modelle oder Epyc und Threadripper mit vier mal so vielen Kernen.
Am deutlichsten sieht man es aber an Renoir, den gibt es mit 65W, 45W, 35W, 25W und 15W.

https://www.computerbase.de/2020-08/amd-ryzen-5-4650g-4750g-test/2/#diagramm-test-performancerating-fuer-anwendungen-multi-core
An den eigenen großen Acht-Kern-Prozessor Ryzen 7 3800X/XT kommt das Modell nicht ganz heran, die TDP-Einstufung und weniger aggressivere Taktraten verhindern dies. Das Ergebnis ist dennoch beachtlich. Schon der Ryzen 7 3700X mit gleicher TDP von 65 Watt liegt in Reichweite, die wenigen Prozent Unterschied sind im Alltag nicht von Relevanz. Das gilt auch in die andere Richtung: Der identisch konfigurierte Ryzen 9 4900HS mit 45 Watt im Asus ROG Zephyrus G14 ist nur minimal langsamer.
Der 3800X profitiert im Vergleich zum 4900HS von seiner deutlich höheren TDP nur wenig.

https://www.computerbase.de/2020-03/amd-renoir-cpu-gpu-apu-technik/2/
Das Aushängeschild sind die neuen CPUs der U-Serie mit 15 Watt TDP. Noch nie gab es hier 8 Kerne und 16 Threads, es ist ein großer Sprung nach vorn.

Das Thema configTDP besteht auch bei der U-Serie. Lassen es das Gehäuse und die Kühlung zu, darf die CPU höher takten. Die dann zur Verfügung stehenden 25 statt 15 Watt bringen je nach Einsatzgebiet 0 bis 17 Prozent mehr Leistung, wenn beispielsweise ein Ryzen 7 4800U verwendet wird.
Hier erhöht eine fast Verdoppellung der TDP die Leistung nur um 0 bis 17%.

Die Zen2 Kerne scheinen extrem auf einen niedrigen Stromverbrauch optimiert zu sein, sonst wäre Renoir(8C) mit 15W und Epyc(64C) mit 200W gar nicht möglich.
Man kann die Kerne anscheinend in einem Bereich von 1W bis 10W einsetzen. Nur effizient ist das zum Schluss nicht mehr. Wie viel schneller ist eigentlich der 3800X(105W) im Vergleich zum 4800U(15W), das es eine TDP-Erhöhung um den Faktor 7 rechtfertigt? Die Desktop Prozessoren sind einfach ab Werk völig übertaktet.

Ok, zurück zu meinen Turbokernen.
Wenn ich jetzt von (recht hohen) 5W für die normalen Kerne ausgehe, dann hätte der Turbokern auch "nur" 25W. Würde ich nun bei einem 8 Kerner einen Kern durch den Turbokern austauschen, würde ich nun von 65W auf 85W hoch rutschen. Hätte dafür aber im Singelthreadbereich 50% mehr Leistung. Würde ich nun die Taktraten minimal senken, käme die CPU wohl wieder in den 65W Bereich. Hätte allerdings in sehr vielen Anwendungen große Vorteile.

PS: Alle Angaben zum Turbokern sind frei erfunden.
+50% mehr Leistung
5 mal so hoher Stromverbrauch
5 mal so viele Transistoren

Badesalz

2020-08-28, 18:04:09

Ich glaube hier liegt eine Fehlkonzeption der Geschwindigkeit, mit der Dinge wie wir sei wahrnehmen können miteinander interagieren, und den Zeitspannen, die in der parallelen Berechnung dieser Ereignissen bei multiplen multi-GHz Dies möglich sind ;) Gerade bei Interaktionen ist es doch sinnvoll, wenn nicht immer erst gewartet werden muss bis die nächste Berechnung ansteht.Diese Entwicklung muss recht langsam vonstatten gegangen sein. Mir sind die Wows bezüglich dieses Aspektes irgendwie nie aufgekommen. Dafür Sachen die 2020 noch beeinducken können, wie TloU2, die auf einer PS4 laufen...
Wo man auch mehr als nur oft durch die Botanik rumkraxelt. Wobei da wohl mehr Blätter als Gras dargestellt wird. Sonst würde die PS4 wohl zusammenbrechen :freak:

Gras. Für die Shader waren das die Haare früher. Das Killerfeature. Das neue Killerfeature für die core-flood ist Gras. Top Idee :up: