auch ein Excavator würde da nichts reißen, genau deswegen hat man auch keine neuen Serverdesigns mehr aufgelegt, weil man chancenlos ist.
Das sehe ich auch so, den Servermarkt hat AMD sicher nicht freiwillig aufgegeben, der Kauf von SeaMicro 2012 zeigt das ja auch, aber man hatte eben wohl keine Chancen mehr für ein wettbewerbsfähiges Produkte gesehen und musste dann die Mittel effizienter einsetzen. Das AMD mit Zen nun wieder starke Server-CPU bauen will, zeugt von dem Vertrauen in die Leistungsfähigkeit der neuen Architektur.
Das hätte AMD aber auch schon bei der Entwicklung sehen müssen und das Projekt frühzeitig einstampfen, hat man leider nicht getan, immerhin hat man dann nach dem Desaster recht schnell reagiert und entwickelte ZEN.
Klar hätten man das früher merken müssen und sicher hat das auch jemand bemerkt und nach oben gemeldet, aber es wurde trotzdem mit der Entwicklung weiter gemacht, man wollte eben auch über die APU Schiene fahren und hat erwartet, dass die wirklich leistungshungrigen Routinen dann Aufgaben an die integrierte GPU abgeben. Nur hat es eben auch eine Weile gedauert, bevor das ging und auch SW Entwicklungstools dafür bereit standen und bis es nennenswerte Programme unterstützen bzw. ob das jemand passieren wird, ist auch noch offen.
Aber generell ist es schon nachvollziehbar was AMD damals geplant hatte und da waren in dem APU Konzept auch keine sehr performanten CPU-Architektur nötig und möglich, erfordern doch GPUs und CPUs sehr gegensätzliche Designs und man muss eben bei einem Kompromiss eingehen. Entweder realisiert man eine starke CPU Architektur und lebt mit einer suboptimale GPU, was Intel bisher gemacht hat oder man setzt auf eine stark iGPU und macht Abstriche bei der CPU, wie es bisher bei AMD der Fall ist. Zen scheint nun wieder voll auf eine starke CPU zu setzen, also warten wir mal ab wie die APUs auf Zen Basis sein werden, vielleicht setzt man dann dort auf getrennte Dies und verbindet diese über Interposer, dann kann man jeweils ohne Kompromisse die optimalen Designs wählen, hat aber mehr Latenz bei der Übergabe von Aufgaben zwischen beiden Welten, was ja eigentlich durch die starke Integrierung von CPU und GPU in den APUs vermieden werden sollte.
In dem Sinne hat AMD den Fehler begangen die SW Unterstützung für das APU Konzept bei dem die iGPU der CPU gewaltig und wann immer möglich unter die Arme greifen sollte, rechtzeitig zu bringen und in der Breite der SW-Entwicklung auch durchzusetzen. Hätten die erste APUs dies gleich gekonnt und wären auch entsprechende Programme verfügbar gewesen um die Vorteile davon zu zeigen und diese auch groß genug gewesen, hätte die Sache anderes ausgehen können.
Du bist also mit dem Bulldozer unzufrieden, dann kaufst du ihn eben nicht.
Das haben ja offenbar viele genauso gehandhabt, sonst wären AMDs Marktanteile ja nicht so abgestützt. Aber ich weiß schon was da als Antwort kommt: Intels böse Machenschaften! Aber das das Leben eben manchmal hart ist und gerade in der Wirtschaft mit härtesten Bandagen gekämpft wird, sollte auch AMD gewusst haben. Am Ende entscheidet der Markt darüber ob ein Produkt gut oder schlecht ist, denn wenn es sich gut verkauft, ist es gut, egal wie mies die Architektur dahinter sein mag und wenn es sich schlecht verkauft, retten auch tolle Architekturdetails das ganze nicht. Wie viele Stages eine CPU Pipeline hat, interessiert nämlich über 99% der Käufer nicht im Geringsten.
Warum man das Produkt dann noch schlecht reden muss werde ich nie verstehen.
Und ich verstehe nicht, wie man ein Produkt über den grünen Klee loben kann, welches ganz offenbar in jeder Hinsicht nicht optimal ist. Das muss wohl der Beschützerinstinkt sein, nach dem Motto: Die arme CPU ist zwar ein Versager, aber die hatte ja auch nie wirklich eine Chance und daher stelle ich sie trotzdem ein.
Ja wir diskutieren lieber ein Problem mit Firefox, anstatt über das Thema.
So unpassend ist das Thema vielleicht gar nicht, denn zumindest bis vor einigen Versionen war Firefox nur Singlethreaded, keine Ahnung wie das bei den aktuellen Versionen aussieht. Von daher können viele offene Tabs gerade bei schlechter Singlethreadperformance schnell zu Performanceproblemen führen, nur werden aber die meisten User nie merken das ihre CPU limitiert. Denn Windows zeigt nur 100% an, wenn alle Kerne/Threads voll ausgelastet sind und auch wenn man die Auslastung der einzelnen Kerne sieht, so fällt es nicht auf, weil der Scheduler die Thread ganz schnell zwischen den Kernen hin- und herschiebt. Bei 4 Kernen/Threads wird man mit einer Singlethreadanwendung dann nicht mehr als 25% CPU Last sehen und alle Kerne scheinen nur zu einem Viertel ausgelastet zu sein, in Wahrheit limitiert die Singlethread Performance der CPU aber die Ausführungsgeschwindigkeit des Programms. Linux Top ist da besser, denn es zeigt 100% pro Kern/Thread an und wenn ein Programm ständig 100% Auslastung erzeugt, so seht man sofort was los ist. Außerdem lässt der Scheduler die Thread i.d.R. viel länger auf einem Kern arbeiten, man sieht bei der Ansicht der Auslastung der Kerne dann immer schön einen auf 100% und dann wandern die 100% auf den nächsten.
