chithanh schrieb:
Das hat mit AMDs Unternehmenskultur zu tun.
Auch die Unternehmenskultur vom AMD ist nicht die der Wohlfahrt! AMD ist in erster Linie darauf aus einen maximalen Gewinn zu machen und dies erreichen sie nicht automatisch mit den höchsten Preisen, sondern mti Marktgerechten Preisen, also denen bei denen sie genug Stückzahlen machen und zugleich eine auskömmliche Marge. Solange sie Intel nicht in allen Bereichen schlagen, müssen sie auch unter deren Preise bleiben, wenn sie Intel in allen Bereichen schlagen, werden sie sich die CPUs auch entsprechend vergüten lassen und dann trotzdem genug Käufer finden.
Taxxor schrieb:
20% speed improvement, und zwar verglichen mit dem vorherigen Prozess, nicht bezogen auf spezielle Produkte.
Unter welchen Bedingungen? Dies ist sicher nicht als eine 20% bessere maximale Taktfrequenz zu verstehen.
Auch die EUV Version des 7nm Prozesses bringt vor allem eine Flächenreduzierung:
Die Fabs können die maximalen Taktraten auch schlecht ohne das Design eines konkreten Chips zu kennen.
Taxxor schrieb:
Wenn man sagt, 20% mehr Transistor Performance und dann zeigt, dass das bei den GPUs auch so hin kommt, dann kommst du an und sagst, dass man das nicht auf CPUs anwenden kann, nur weil es bei GPUs so ist.
Ein, trolle nicht rum, ich haben genau erklärt es das nicht daran liegt das es GPUs sind, sondern daran das die GPUs bei viel geringeren Frequenzen als Desktop CPUs arbeiten.
Taxxor schrieb:
Wenn du aber belegen willst, dass die CPUs nicht so hoch takten können, ist dein einziges Argument, dass TSMC bisher nur GPUs mit 1800MHz als höchst taktende Produkte mit dem Prozess hat
Auch dies kann man eigentlich nur falsch verstehen wenn man Brend das Brot ist oder trollt.
usb2_2 schrieb:
Schön und gut aber ich rechne noch immer mit 3 zu 3,4 GHz oder 3 zu 3,6 GHz. Das wird der 7nm Prozess schaffen. ARM Chips auf dem Prozess schaffen ja schon 2,8GHz.
Das halte ich durchaus für realistischer als die Werte aus den Gerüchten, dann würden aber 10% mehr IPC nicht reichen um pro Kern die gleiche Performance (und damit auch nicht die gleiche Singlethreadperformance) zu bekommen wie bei den Vorgängern. Ein Zen2 würde also die Vorgänger mit der gleichen Anzahl an Kernen nicht schlagen, ein RYZEN3 3000er wäre also 4 Kerner sinnlos und daher wird es ein 6 Kerner, ebenso muss dann ein R5 mehr als die bisherigen 6 Kerne bekommen und der R7 ebnen 12 statt bisher 8 um jeweils mehr Multithreadperformance als die Vorgänger zu haben. Dann machen die Anzahl der Kerne und die Preise in der Tabelle auch Sinn, denn dann sind die realistisch, der Preis wäre weniger Singlethreadperformance und AMD hat für die nächste Generation über mehr Takt eine Steigerung für die sie selbst wenig tun müssen, da die durch die Verbesserung beim Fertigungsprozess kommt.
usb2_2 schrieb:
Da wurden keine gebaut, die auf Takt ausgelegt waren. Höchstens GPUs, die auf Takt ausgelegt waren, wobei die immer niedriger takten, als CPUs.
In 16nm und 10nm (was eigentlich wie bei GFs 12nm nur der optimierte 16nm / bei GF 14nm Prozess ist), wurden meines Wissens nach auch keine CPUs, sondern nur GPUs, ASICs und ARM SoCs gefertigt, mithin nur Chips die moderaten Taktraten.
usb2_2 schrieb:
Die TDP ist vor allem für den Basistakt relevant und das eDRAM wurde denen nur spendiert um wenigstens bei einigen Anwendungen / Benchmark vor den Vorgängern zu liegen, da man dies eben nichts über den Takt und die IPC Verbesserungen erreicht hat. Man hätte auch mehr Kerne nehmen können, hat Intel damals aber nicht.
Hayda Ministral schrieb:
Willst Du mich verarschen oder nur tollen?
Hayda Ministral schrieb:
Intel, IBM, Sun,.... verbauen mehr Kerne weil sie es können und dadurch einen Mehrwert schaffen.
Die beiden Server CPU und nur bei Intel haben die Server CPUs schon länger von Generation zu Generation immer mehr Kerne bekommen, während bei den Mainstream CPUs lange bei 4 Kerne Schluss war. Serveranwendungen lasten typischerweise die viele Kerne auch und der Wechsel von einer 20 Kern CPU mit 2GHz zu einer 24 Kernen bei 1,8GHz ist dann bei den meisten Anwendungen immer noch von Vorteil, obwohl der Takt und damit die Performance pro Kerne 10% geringer ist.
JNS-K schrieb:
So unrealistisch wäre das gar nicht, denn Prozessoren werden für einen bestimmten Taktbereich entwickelt.
Sagen wir mal, die Architekturen waren für den Betrieb bei einem bestimmten Taktbereich optimiert. Welcher das ist, hängt neben dem geplanten Anwendungsbereich auch von den Möglichkeiten der Fertigung ab. Daher macht es auch durchaus Sinn warum Intel und früher auch AMD zwei unterschiedliche Architekturen haben/hatten, nämlich Intel die Atom (aktuell Goldmont) und Core i, AMD die Katzen und Bulldozer.
JNS-K schrieb:
Daher ist Holts Annahme nicht so von der Hand zu weisen, AMD könnte manche "Pferdefüße" in Kauf genommen haben um bei der gewünschten Frequenz die Leistung ausspielen zu können. Erreicht man aber diese Frequenzen aus irgend einem Grund nicht, dann könnte das ein sogenantes Eigentor werden.
Eigentor würde ich es nicht nennen, eher Tradeoff. Die neuen Chiplets scheinen ja primär für die Server (Rome) entwickelt worden zu sein, dort wurden sie anderes als die Zeppelin auch zu gezeigt. Deren Fertigung war ja auch von Anfang an bei TSMC geplant, während eben die für die Desktops bei GF hätten gefertigt werden sollen, nur wurden deren 7nm Prozess eben auf Eis gelegt. Die Fertigung bei einer anderen Fab hätte sowieso andere Masken und auch ein anderes Design des Chips erfordert, die man sich nun sparen kann. Da hat AMD dann wohl aus Not eine Tugend gemacht und wenn man nun eben nicht die Taktraten hinbekommt, wirft man halt CPUs mit mehr Kernen ins Rennen, nimmt die gleichen Chiplets und baut nur einen passenden neuen I/O Chip. Ich würde wetten dass die Zen2 aus der Fertigung von GF wohl nur aus einen Die mit Kernen und I/O darauf bestanden hätten.
JNS-K schrieb:
Meine Vermutung ist, dass genau daran der Intel 10nm Prozess krankt ... denn welcher Kunde kauft einen neuen Prozessor, wenn der neue nicht schneller ist als der alte, auch wenn dieser in einem neuen Fertigungsverfahren gebaut wird. Meine Vermutung ist, dass sie entweder die Spannung nicht weit genug senken können um die Abwärme in den Griff zu bekommen oder die gewünschten Taktfrequenzen können nicht erreicht werden.
Die Abwärme in den Griff zu bekommen, ist bei den kleinen Strukturen wegen der Hotspots ein Problem, eines welches auch nicht für so hohe Taktraten der Zen2 spricht, aber ich denken das Hauptproblem ist wohl der Takt den man nicht erreicht. Es könnte man an der Ausbeute liegen, der Wechsel von Kupfer auf Kobalt erleichtert die Sache sicher nicht, könnte aber der Schlüssel sein um überhaupt noch so hohe Taktraten bei immer kleiner werdenden Strukturen zu erzielen, denn wie TSMC auch schon sagt:
Es ist bezeichnend das Intel beim 14nm++ den transistor gate pitch von 70nm auf 84nm erhöht hat, nahe an die 90nm bei 22nm Prozess, die Chips also wieder größer werden um höher getaktet werden zu können. Denkt mal darüber nach wieso hier nicht kleiner sondern größer schneller ist.
JNS-K schrieb:
Effektiv programmieren kann kaum noch einer heute ...
Ja und nein, können ist das eine, die Anforderungen sind das andere. Anwendungen sollen heute plattformunabhängig sein, Assembler fällt damit schon mal ganz weg und Hochsprachen die auf Interpretern laufen wie DotNet, Java, JS, Python etc. sind denen die kompiliert werden müssen, daher überlegen, weil man sie einfach für alle Plattformen gleich ausliefern kann, statt für extra compilieren zu müssen. Auch muss man sich nicht mit unterschiedlichen APIs der einzelnen Umgebungen rumschlagen, der übernimmt der Anbieter des Frameworks. Das geht zwar auf die Performance zur Laufzeit, aber die Entwicklung der SW geht schneller und erreicht ein größeres Publikum, die Entwicklung müssen sich nicht so tief in Details der APIs einarbeiten die sind alle Nase lang ändern und sowieso systemspezifisch sind.
JNS-K schrieb:
Allerdings löst auch die Programmierung in Maschinencode nicht die Problematik das sich nur sehr wenige Probleme vernünftig parallisieren lassen.
Dazu kommt der Trend zu Webprogrammierung und die dort verwendeten Techniken auch anderswo einzusetzen. Statt Probleme mit mehreren Threads in einem Programm zu lösen, nehmen Entwickler dann einzelnen Module und lassen die über Rest miteinander kommunizieren, auch wenn da Megabytes an Binärdaten hin und her gehen die jeweils json serialisiert und deserialisiert werden müssen, was wie das seriell in den Worten schon andeutet, eben nur Singlethreaded geht und Bitshiftung ist nicht die billigste Operation einer CPU. Das ist nicht wirklich effizient, aber dann kommen die Argumente das man diese Lösung besser skalieren können, weil man damit die Module einfach auf unterschiedlichen Rechner verteilen kann und dagegen lässt sich dann auch wieder nichts sagen und schon gar wenn eine Lösung von auf einem Rechner bis auf einer drei- und noch mehrstelligen Anzahl an Blades ausgerollt werden können soll. Es ist eben immer ein Mix aus Anforderungen die die verwendete Technologie bestimmen, auch bei der Softwareentwicklung.
Taxxor schrieb:
Die Annahme Ryzen 3000 bräuchte mehr Takt für mehr Leistung ist ja auch schon falsch.
Die Leistung bei gleichem Takt wird durch die IPC Verbesserung sowieso steigen, also kann die Singlecoreleistung gar nicht schlechter ausfallen.
Es hat ja auch niemand behauptet das es nicht reicht wenn der gleiche Takt wieder erreicht wird, was aber am wenigsten wahrscheinlich ist. Wahrscheinlicher ist doch, dass es entweder höher oder wie ich vermute eben tiefer ausfällt. Daher habe ich doch auch immer geschrieben, wenn der Takt und die IPC Verbesserungen nicht reichen, wieso wird das wieder unterschlagen? Die IPC Verbesserungen können einen schlechteren Takt aber eben auch nur bis zu einem bestimmten Punkt kompensieren und wenn man realistisch von 10% mehr IPC overall und nicht bei speziellen Befehlserweiterungen wie AVX2 ausgeht, dann wäre Leistung pro Kern bei 10% weniger Takt etwa gleich, was aber eben nicht reicht um einen Nachfolger attraktiv zu machen und selbst wenn man den Preis senkt, würde keiner der den Vorgänger hat deswegen aufrüsten wollen. Also muss man irgendwie mehr Leistung bieten, wie Intel damals bei den Broadwell für den S. 1150 und statt auf ein teurer eDRAM oder noch teureres HBM als L4 Cache zu setzen, nimmt AMD dann einfach mehr Kerne, denn die billiger zu haben sein.
Wenn also der Takt mal der IPC Steigerung etwa die gleiche Leistung pro Kern ergibt, dann bekommt man den Gerüchten nach ja etwa 50% mehr Kerne und damit bestenfalls auch 50% mehr Multithreadperformance bei den R3 und R7 und immer noch 33% bei den R5 und das zu etwa den gleichen Preise wie bei den jeweiligen Vorgängern. Das ist nicht die Massenvernichtungswaffe die Intel vom Platz fegt und für die letzten fps muss man weiter den Intel Aufpreis zahlen, aber das wäre doch keineswegs ein schlechtes Angebot.
Die Tabelle ist einfach zu gut um wahr zu sein, sondern dürfte die feuchten Träume der Leute widerspiegeln die
jetzt für wenig Geld eine CPU kaufen wollen der Leistung die nächsten 10 Jahre ausreicht, sich wünschen das AMD Intel plattmacht oder einfach den Aktienkurs von AMD pushen wollen, wer kann das schon sagen. Wer fest daran glaubt, braucht hier nicht mitzudiskutieren, Traumtänzer gibt es immer wieder und die Realität holt sie irgendwann ein, vorher verschließen sie sowieso immer die Augen davor. Wenn man also mal versucht realistisch zu bleiben, dann kann man nur überlegen was in den Tabelle wohl nicht stimmt und da gibt es entweder die Anzahl der Kerne, die Taktraten oder die Preise. AMD hat nämlich auch immer versucht entsprechende Preis zu verlangen wenn diese am Markt durchsetzbar waren, wie der
FX9590 zeigt, der mal zu 750€ gestartet ist und dann massiv im Preis gefallen, denn die OEMs haben die Dinger von Anfang an weitaus billiger als die Endkunden bekommen:
Aber erstmal hat man versucht Endkunden einen utopischen Preis abzuknöpfen. Oder schau Dir die Priese der ersten TR ab, der
TR1920X gibt von über 800€ schrittweise auf jetzt 350€ runter, deutlich mehr als der
i9 7900X. Zu den ursprünglichen Preisen haben sich offenbar nicht genug Käufer gefunden als AMD gedacht hat, die Lager dürften daher noch voll sein und entsprechend muss man sie nun über den Preis loswerden, was letztlich auch nichts anderes bedeutet als das die Preise vorher einfach überzogen und am Mark nicht durchzusetzen waren. Dies bedeutet eben auch, dass man versucht hat die Preise eben so hoch wie möglich anzusetzen und nicht die Wohlfahrt zu spielen um sozial schwachen den Kauf von CPUs mit vielen Kernen zu ermöglichen.
Wenn also der Takt und die Anzahl der Kerne stimmen, dürfte der Preis nicht stimmen, dann dann mehr rauszuholen wäre und AMD dies auch weiß und versuchen wird.
Könnte es sein das die Anzahl der Kerne nicht stimmt? Ja, könnte es, denn müsste aber der Takt zumindest ungefähr hinkommen, damit genug Mehrleistung gegenüber den Vorgängern vorhanden ist um die CPUs bei der Anzahl an Kernen gegenüber den Nachfolgern mit einer attraktiven Mehrleistung zu versehen, nur was soll dann ein R9 im Programm? Und von den EYPC wissen wir, dass die Zahl der Kerne sich deutlich erhöht, nämlich auf bis zu 64 sogar verdoppelt, der Takt liegt aber schon heute bei 2,xGHz in der Basis und maximal 3,2GHz Turotakt, bei dem
Hochfrequenz EPYC 7371 bis 3,8GHz und Rome passt mit 2,35GHz in diesen Bereich;
Das aktuelle Flaggschiff Epyc 7601 hat 2,2 GHz Basistakt, also etwas mehr Takt hat man, aber 2,35GHz sind noch unendlich weit von 4,x oder gar 5,1GHz, von denn die Gerüchte berichten. Daher sind die Taktraten für eben der unglaubwürdigste Teil in der Tabelle. Ihr könnt es anderes sehen, ist mir egal, dies soll mein letzter Post hier sein, da es nichts mehr zu sagen gibt.
foofoobar schrieb:
Das ist eine 20nm CPU, die wohl keinen Nachfolger mehr bekommen wird:
Im übrigen sind die SPARC RISC CPUs und deren Design war immer auch extrem hoch Taktraten optimiert, dafür mussten aber auch mehr Instruktionen abgearbeitet werden um die gleichen Dinge wie bei CISC CPUs wie den x86er erledigen zu können. Die Designs sind also nicht vergleichbar.
Interessant ist hier übrigens auch der Hinweis auf die Bedeutung der "per core performance", also Takt mal IPC:
Die Taktraten sind bei RISC Prozessoren sehr wichtig, da sie zwar viele Befehle abarbeiten können, aber deren Befehle nicht sehr mächtig sind. Wenn die neue Fertigungsprozesse nicht mehr solche Taktraten erlauben, dann macht es Sinn die RISC CPUs schon deswegen einzustampfen und obendrein sollte man sich mal ansehen wie stark Oracle bei den letzten Versionen (12 und 18) seiner Datenbank die Parallelisierung gegenüber den Vorgängern vorangetrieben hat.
Unnu schrieb:
Jedoch gehe ich jede Wette, dass vernünftig geschriebene Software - muss nicht mal Maschinencode sein - auf moderner HW abgehen würde wie Schmids Katze mit brennendem Hintern.
Nicht unbedingt, denn die Singlethreadperformance ist schon noch sehr wichtig und in den letzten Jahren eben kaum noch gestiegen und es lässt sich eben nicht alle parallelisieren. Die wirklich zeitkritischen Routinen waren auch heute noch oft in C/C++ geschrieben und mit gut optimierenden Compilern übersetzt.
usb2_2 schrieb:
Wenn AMD einen Z490 gebracht hätte dann wäre für mich natürlich der X470 kein Vergleich zum Z390.
Wenn, aber den haben sie nie gebracht und der X470 ist mit gerade mal 8 PCIe 2.0 Lanes (plus 2 PCIe 3.0 Lanes die nur wenige Boards für fest verlötete Controller nutzen) nun wirklich kaum mit dem Z390 zu vergleichen, da helfen auch die 3 PCIe 3.0 Lanes des internen Chipsatzes der CPU nichts, da muss AMD aufholen.
v_ossi schrieb:
Wir (als Gesellschaft, aber auch als Individuen) haben noch nie so viel Rechenleistung so günstig zur Verfügung gehabt
Was aber vor allem im Serversegment der Fall ist, Big Data lässt grüßen und solange die Leute gerade in den sogenannten sozialen Medien massiv Daten produzieren und die Firmen diese auswerten wollen um richtig Geld daran zu verdienen, wird dies auch so bleiben, obwohl der Mining Boom jetzt wohl beendet ist.
v_ossi schrieb:
der "0815 Max Mustermann" schießt, was seine Hardware angeht, schon heute mit Kanonen auf Spatzen.
Nein, dies würde ich nicht sagen, bei AMD kaufen die meisten die R5 mit 6 Kernen, eben um nicht mit Kanonen auf Spatzen zu schießen. Die Forenuser sind als besonders Interessierte hier sicher nicht repräsentativ. Außerdem weißt Du nie ob die fette CPU und Graka in der Signatur auch wirklich im Rechner stecken.
Unnu schrieb:
Man muss ja C nicht unbedingt in VI / Emacs coden nur um shiny geekiness zu beweisen.
C++ auf dem Emacs coden habe ich vor 20 Jahren gemacht, mit den passenden Erweiterungen war das geil, da konnte man im Debugger einen Breakpoint setzen und dann einfach mal eine Funktion aufrufen und der z.B. die Datenstruktur zu Analyse übergeben und die Ausgabe dann direkt sehen.
usb2_2 schrieb:
Aber ich will doch die Gesamtleistung der einen CPU, also Volllast bei vollem Takt, mit der einer anderen vergleichen. Warum dann nur auf einem Kern?
Weil die Gesamtleistung einer CPU eben nicht nur aus der Multthreadperformance besteht, sondern auch aus der Singlethreadperformance bzw. der per core performance. Wenn diese nicht von Interesse sind, lasse halt nur den Multithread Test laufen, aber bei den meisten Anwendungen von Heimanwendern der der eben nicht wirklich relevant. Letztlich muss man immer mit den Programmen benchen die man auch wirklich nutzt oder sich die Benchmarks in Reviews ansehen, mit denen die eigenen Programme am besten korrelieren.
usb2_2 schrieb:
Die Programme, die mehr als einen Kern auslasten zählen ja eh nicht.
Auch das ist so ja nicht richtig.
usb2_2 schrieb:
Wenn Cinebench Multicore nicht zählt kann Cinebench Singlecore niemals relevant sein. Das sagt dann ja noch weniger über die Leistung einer CPU aus.
Schwarz - Weiß Denken hilft hier gar nichts. Wäre es einfach, bräuchten die Reviewer nicht so viele Benchmarks und Programme durchzutesten. Wie gut ein Programm auf einer CPU performt hängt von vielen Faktoren ab, auch davon wie viele Kerne es wie gut auslasten kann.
Zero_Point schrieb:
Was habe ich von theoretischer Leistung, wenn ich sie in der Praxis nicht abrufen kann?
Eben, das ist wie bei den schnellen NVMe SSDs, theoretisch sind sie sie vielfach schneller, in der Praxis kommt davon nur bei einigen Anwendungen wirklich etwas an, einfach weil die Geschwindigkeit mit der Daten geladen oder Programme gestartet werden, eben nicht nur von der Zeit abhängt die es dauert bis die SSD die Daten liefert, sondern eben z.B. auch der Zeit die die CPU braucht diese zu verarbeiten und dies ist oft auch nur singlethreaded (möglich).
Ist das jetzt die Pipi Langstrumpf Logik? Ich mach' mir die Welt
