News AMD: 2019 dominieren kleine, sparsame x86-Kerne: Das Ende von Bulldozer?

Ich finde viel interessanter, das AMD den ARM Markt beherrschen wird :D
Du meinst eher den ARM Servermarkt. Denn nur von dem hat AMD gesprochen. Wie sie den allerdings beherrschen wollen, bleibt ihr Geheimnis. Sollte der Markt ein signifikantes Volumen erreichen (momentan ist er noch weit davon entfernt) wird AMD nicht der einzige Anbieter sein. Anders als im x86 Umfeld ist der Eintritt für Konkurrenten im ARM Bereich erheblich einfacher.

---------- Beitrag hinzugefügt um 18:16 ---------- Vorheriger Beitrag um 18:13 ----------

Kleinere & effizientere Kerne sind für AMD genau das richtige, die Chips werden sowieso zu billig Preisen angeboten, große Kerne kann man sich komplett sparen, die Entwicklungskosten von BD kann man dann in andere Gebiete sinnvoll investieren, wichtig ist das AMD in Zukunft pro Jahr zwischen 500-1000 Millionen Gewinn erzielen kann.

Ohje. Jetzt sind wir schon bei 500 Millionen bis 1Mrd. Gewinn. Ich glaube die können froh sein, wenn sie überhaupt einen Gewinn auf Jahresbasis ausweisen, Strafzahlungen an GF eingerechnet.
 
Ich bezog mich auf die Folien, auf denen klar zu lesen ist das AMD seine Zukunft in CPUs sieht. Entweder der durchgeknallte Folienassistent hat sich wieder ausgetobt oder wir erleben live und in Farbe dass AMD zurück rudert und das APU-Konzept beerdigt. Such Dir aus was wahrscheinlicher ist :-)

Im Grunde gibt es aktuell zwei Richtungen in Serverbereich, die AMD mit Nachdruck verfolgt:

--> APUs
--> ARM-basierte Prozessoren (SoCs) für Server

Im Zusammenhang mit den ARM-Opterons wurde meiner Erinnerung zu Folge bisher nichts von einer integrierten GPU gesagt. Auch bei den Embedded-Produkten steht nichts auf der Roadmap, wo ARM-CPU-Kerne mit einer GPU kombiniert werden.

Ich gehe davon aus, dass eine "ARM-APU" erst für die zweiter Generation angedacht ist - was aber natürlich reine Spekulation meinerseits ist.
 
APUs in Servern? Mir kam es eher so vor, als hätten CPUs mittlerweile nur noch Verwaltungsaufgaben zu stemmen. Die Zeiten, dass die x86 Kerne die Hauptarbeit stemmen sind in vielen Fällen vorbei. Das kommt zwar durchaus noch vor, aber scheint immer weiter an Bedeutung zu verloren. Die eigentliche Rechenarbeit wird immer häufiger von dedizierten, hochspezialisierten Co-Prozessoren auf PCIe-Karten geleistet. Das gab es schon in der Vergangenheit immer wieder einmal. Man denke nur an all die Netzwerkkarten die mit Zusatzchips für die RAS-Beschleunigung versehen sind. Nur wird das in Zeiten bei denen man großes Augenmerk auf die Energieeffizienz liefert, immer bedeutsamer. Ein ASIC ist eben kaum zu toppen in dieser Hinsicht. Das spart nicht nur Stromkosten und verbessert so die CO2-Bilanz des Unternehmens, sondern erfordert auch weniger Kühlaufwand. Für manche Zwecke mögen die Shader Units der APU den Anforderungen genügen, aber bisher werde sie von der Kundschaft gemieden. Im Grunde stellen sie auch nur eine Übergangslösung dar und werden nur eine Zukunft bei Anwendungen haben, bei denen aufgrund einer geringen Verbreitung die Entwicklung und Fertigung von ASICs zu teuer ist. Ich denke die mangelnde Nachfrage am Opteron X1250 liegt neben dem Umstellungsaufwand vor allem an der mageren Speicherbandbreite. Wegen der unverzichtbaren Fehlerkorrektur (ECC) muss man mit vergleichsweise geringen Frequenzen leben. Diese ist außerdem noch der geringen TDP geschuldet. Und dann bietet der derzeit erhältliche Opteron X1250 obendrein nur Singel-Channel DDR3. Eine Lösung ist für künftige APUs nicht in Aussicht.
 
Grosse Kerne lassen sich zB auch mit ARM designen.

Der ARM A15 Hat gezeigt das ARM bei Großen Kernen sehr Ineffizient werden, da waren dann schon ATOMs schon teilweise Effizienter.
Das AMD/Intel-Problem ist wirklich kleine Effiziente x86-Cores zu bauen, gilt umgekehrt für ARM "Highend"-Cores die besten falls Kabini & Co. Konkurrenz machen.


Bestes Beispiel sind die Spielekonsolen: Dort gibts 8 Jaguars und nicht weniger-große Kerne, z.B. 4 Steamroller.

Jo, das ginge natürlich noch, aber diese Meldung hier hat halt x86 und Bulldozer zum Thema. Wenn ein High-End ARM Kern kommt, ist BD erst recht weg vom Fenster, denn dann wäre die Opteronnische weg und nur noch das mickrige FX-Segment übrig. Definitiv zu wenig für ne eigene Architektur.

Ich gehe davon aus das die acht Jaguars vor allem aus zwei Gründen zustande kamen:
  • PS3 hatte 7 Kerne zwei Bullzodermodule wären Marketing Technisch schlecht verkaufbar gewesen und MS wollte mit Sony gleich ziehen
  • Die erste Bulldozer Inkarnation war zu Strom durstig und langsam, ein Streamroller hätte Xone/PS4 MS/Sony bestimmt akzeptiert in 20nm wäre es evtl. sogar vier Module geworden.

Kleinere Kerne und Spezialisierte Kerne, ist kurzfristig attraktiver, aber langfristig?! Der Vorteil von nicht Spezialisierten Kernen ist das auch zukünftiger Code ausgeführt werden kann, nicht so schnell und Effizient aber ausführbar. Sobald die Spezialeinheiten den Code nicht mehr ausführen können ist Schicht im Schacht und die Hardware unbrauchbar.

Bestes Beispiel Video-Codecs@ARM wenn es Unterstützt wird klasse Sache aber wehe wenn dann kommt man sich in die Steinzeit versetzt vor.

Viel kleine Kerne soll gut sein?! Bis heute gibt es kaum Software die die acht Kerne eines Bulldozers auslasten können, in meinen Augen ist Multi-Threading gescheitert. Zu Erinnerung geplant war 64 Kerne und mehr

AMD macht den gleiche Fehler wie Cyrix, VIA & Co. sich vom Highend Sektor zu verabschieden, das ist der Anfang vom Ende. Die Geschichte von Cyrix, VIA & Co. haben wir nun wirklich schon häufig genug erlebt. Das Know-How was im Highend Sektor und somit im "Grenzbereich" der F&E erlangt wird uns unabdingbar für den Erfolg auch im Low-End-Bereich.
 
Im Grunde gibt es aktuell zwei Richtungen in Serverbereich, die AMD mit Nachdruck verfolgt:

--> APUs
--> ARM-basierte Prozessoren (SoCs) für Server

Im Zusammenhang mit den ARM-Opterons wurde meiner Erinnerung zu Folge bisher nichts von einer integrierten GPU gesagt.

Das ist mir schon klar. Auf Folie 17 werden explizit auch x86 CPUs erwähnt.
Möglicherweise ist das ja wirklich der Anfang vom Ende der Hoffnung auf leistungsstarke Server-APU-Dickschiffe.
 
Während die Folie sich doch offensichtlich auf Server bezieht, steht in der Meldung - weder in der Überschrift, noch im Text - davon rein gar nichts. Der aufmerksame Leser muss das schon selbst vermuten, weil von CPUs und nicht APUs die Rede ist.
Warum nicht den Bezug zu Servern klar herausstellen? Das reißt euch doch keinen Stein aus der Krone.

Sorry, aber so ist das m.E. keine gelungene Meldung.
Mal sehen, wie die noch ihre Kreise im Netz zieht.
MfG
 
Warum nicht den Bezug zu Servern klar herausstellen? Das reißt euch doch keinen Stein aus der Krone.
Wozu? Was würde es denn ändern? Glaubt denn einer der anwesenden Leser, dass AMD exklusiv nur fürs FX-Segment:
a) Eine neue Plattform mit mehr PCIe und Speicherkanälen aus dem Boden stampft und supportet?
b) Ein extra Die für die paar verbliebenen AMD Desktop high-end Kunden entwickelt, debuggt und produzieren läßt?

Mit Abstrichen könnte man bei a) noch FM2+ weiterverwenden, 2x PCIe x8 ist zwar kein high-end, aber man könnte es sicher ertragen, aber dann bleibt immer noch Punkt b).

AMD verkauft jetzt schon nur wenig Opterons mit Bulldozerkernen und ebenfalls wenig FX. Ob es sich aktuell überhaupt noch rentiert ist schon ne Preisfrage, aber wenn ein Segment wegfällt, dann ganz sicher nicht.

AMD ist halt nicht Intel, die können sich Sonderdies wie die QuadCore-Quadchannel-CPUs für S2011 leisten, die haben selbst in dem Segment genügend Stückzahl, AMD aber nicht (mehr).

Ich kann aber gerne irgendwo ein "Server" ergänzen. Ändert so oder so nichts .. auch wenns da steht.

Edit:
Habs in der Einleitung ergänzt:
sondern auch eine Folie, die AMDs x86-Zukunft im Serverbereich erwähnte
 
Viel kleine Kerne soll gut sein?! Bis heute gibt es kaum Software die die acht Kerne eines Bulldozers auslasten können, in meinen Augen ist Multi-Threading gescheitert. Zu Erinnerung geplant war 64 Kerne und mehr

Wenn man virtualisiert kann man nicht genug Kerne haben.
Warum muss es immer "eine" Software sein die alle Kerne auslastet?
Viele Einkernsoftware-Prozesse parallel ausgeführt lastet ebenso aus.

Wir selbst in unserem RZ haben keine Probleme 2P 32 Core Server auszulasten.
Auch am Boot würden wir so etwas öfter brauchen ....
Gerade im Serverbereich sind Kerne oftmals mehr gefragt als irgendwelche Singlethread-Sieger.

Was man eher weniger braucht sind so Spezialisten wie APUs.
Deswegen verstehe ich auch diese Strategie AMDs in diesem Zusammenhang nicht.
 
Zuletzt bearbeitet:
Bestes Beispiel sind die Spielekonsolen: Dort gibts 8 Jaguars und nicht weniger-große Kerne, z.B. 4 Steamroller.
Jaguar war aber nicht gerade erste Wahl. Erste Wahl war sehr wohl was grösseres wie Steamroller. Nur war Jaguar zu dem Zeitpunkt verfügbar, Steamroller nicht. Bulldozer bzw Piledriver war vermutlich nicht gut genug. Die Fertigung mag auch eine Rolle gespielt haben. Zu Jaguar gab's bereits GCN in 28nm, zu Bulldozer bzw Piledriver gab's nur eine veraltete VLIW4 GPU in 32nm.

Ok, so könnte mans sehen, aber inklusive des ARM-Kontexts hat man ja bei der Streichung von BD immernoch 2 Linien, ARM+Jaguar und 2 sind mehr als "one"
Ich denke, die Bobcat Linie wird irgendwann von ARM Designs komplett ersetzt. Hardwaretechnisch macht es eigentlich keinen Sinn, beides fortzusetzen. Problem könnte maximal die starke x86 Softwareinfrastruktur in diversen Märkten sein. Muss mittel- bzw langfristig aber kein Hindernis sein.

Dein Wort in Gottes Ohr, für den Chip gilt das oben von mir geschriebene: Auf der Roadmap ist nix und die beste Erklärung dafür ist, dass auch nix kommt.
Welche Roadmap? Basilisk sollte frühestens was für 2016 sein. Es gibt meines Wissens noch keine Client Roadmap für 2016.


Der ARM A15 Hat gezeigt das ARM bei Großen Kernen sehr Ineffizient werden
So ineffizient ist der A-15 nun auch nicht. Aber das ist doch noch ein alter 32-bit Kern und daher belanglos. Die 64-bit Kerne wurden von Grund auf neu designed. Das ist 'ne ganz andere Geschichte.

Viel kleine Kerne soll gut sein?! Bis heute gibt es kaum Software die die acht Kerne eines Bulldozers auslasten können, in meinen Augen ist Multi-Threading gescheitert.
Wieso soll Multithreading gescheitert sein? Dass fast jeder heutzutage mindestens einen Dual-Core im Rechner hat, zeigt doch genau das Gegenteil. Multithreading beginnt doch nicht erst bei 8 Threads. Multithreading beginnt schon bei 2 Threads. Die Frage ist halt nur, wie viel man für seine Anforderungen braucht. Und das lässt sich nicht pauschal beantworten. Deswegen gibt's nicht nur FX8, sondern auch FX6 oder FX4. Mit einem Dual-Core bin ich zB schon deutlich an Grenzen gestossen. Da macht ein Quad schon wesentlich mehr her. Mittlerweile würde ich aber auch 6 Threads nicht ablehnen. Bei Multicore Prozessoren geht's ja nicht nur um Multithreading, sondern vor allem auch um Multitasking.
 
Sobald die Spezialeinheiten den Code nicht mehr ausführen können ist Schicht im Schacht und die Hardware unbrauchbar.
Das stimmt soweit; dem ist nichts hinzuzügen. Das hat man sehr schön an der Ablösung von 3DES durch AES gesehen. Danach wurde auch eine ganze Reihe von Krypto-Beschleunigern auf einen Schlag arbeitslos. Allerdings entwickeln sich das gesamte Server-Ökosystem deutlich vorhersehbarer als dies in anderen schnelllebigeren Segmenten der Fall ist. So hat man für einige Jahre eine durchaus hohe Planungssicherheit. Dabei kann sich der Kunde schon ausrechnen, ob sich die Anschaffungskosten durch das bessere "Leistung je Watt"-Verhältnis über die Monate und Jahre amortisiert oder nicht. Für viele Zwecke lohnt es sich gar nicht ASICs zu entwickeln, weil es Nischenanwendungen sind und sich ein spezieller Chip nur bei entsprechend hohen Stückzahlen rechnet. Dort könnte eine APU mit ihren vergleichsweise universell nutzbaren Shader Einheiten gefragt sein. Aber bei wiederkehrenden Standardaufgaben ist sie nicht das Mittel erster Wahl. Nichts desto trotz bin ich mir sicher, dass aus den eben genannten Gründen genug vom Kuchen für AMD abfällt. Aber ob mit APUs oder über hauseigene PCIe Steckkarten lässt sich schlecht vorhersagen. Ich würde den Ansatz mit FirePro Karten persönlich als gewinnbringender für AMD ansehen.
 
Zuletzt bearbeitet:
Wenn man virtualisiert kann man nicht genug Kerne haben.
Warum muss es immer "eine" Software sein die alle Kerne auslastet?
Viele Einkernsoftware-Prozesse parallel ausgeführt lastet ebenso aus.

Wir selbst in unserem RZ haben keine Probleme 2P 32 Core Server auszulasten.
Auch am Boot würden wir so etwas öfter brauchen ....
Gerade im Serverbereich sind Kerne oftmals mehr gefragt als irgendwelche Singlethread-Sieger.

Im Server Umfeld machte es durchaus Sinn, ABER würdest du die 2*32 Kerne gegen 2*64 oder 2*128 ARM V6/7 Tauschen wollen?! Der Schrei nach mehr Kernen ist doch sinnlos, wenn die IPC ins Bodenlose fällt. Eigentlich möchte man bei einem Stromverbrauch X bestmögliche Performance, wie viele Cores, Takt und IPC ist erst mal egal, aber eine nicht MultiCore Skalierbare Anwendung skaliert nun mal nur mit beiden letzteren und um eine Multicore Skalierbare Anwendung mit allen drei!

Virtualisierung ich auch keine Lösung für alles! Erstens hat man einen Performance Verlust und zweitens muss die Skalierung über mehrere VMs auch von der Software in mehr Performance um gesetzt werden.

Es sollte große und kliene CPUs geben. Denn die aktuelle Entwickelung das die Großen zu kleinen langsamen werden, führt dazu das wir hätten auch gleich auf den ATOM umsteigen können, davon halt eine Variante mit vielen Kernen. Es werden immer mehr Transistoren für GUP und weniger für CPU aufgewendet, aber Anwendungen die die Brachiale FPU Leistung der GPU nutzen sind bisher nur Versprechungen von denen in der Praxis wenig ankommt. Selbst bei der Video-Codierung einem Steckenpferd ist hängt man in Sachen Bildqualität noch Meilen weit hinterher.

Was bringen mir also viele (GPU) Kerne die ich nicht nutzen kann?!

Wenn ich mir aber die Software Entwicklung anschaue sind wir bei 1-4 Kernen die genutzt werden. Im Serverbereich sind es natürlich (fast) alle Anwendungen die einen Profit darausschlagen.


Ich denke, die Bobcat Linie wird irgendwann von ARM Designs komplett ersetzt. Hardwaretechnisch macht es eigentlich keinen Sinn, beides fortzusetzen. Problem könnte maximal die starke x86 Softwareinfrastruktur in diversen Märkten sein. Muss mittel- bzw langfristig aber kein Hindernis sein.

Wieso soll Multithreading gescheitert sein? Dass fast jeder heutzutage mindestens einen Dual-Core im Rechner hat, zeigt doch genau das Gegenteil. Multithreading beginnt doch nicht erst bei 8 Threads. Multithreading beginnt schon bei 2 Threads. Die Frage ist halt nur, wie viel man für seine Anforderungen braucht. Und das lässt sich nicht pauschal beantworten. Deswegen gibt's nicht nur FX8, sondern auch FX6 oder FX4. Mit einem Dual-Core bin ich zB schon deutlich an Grenzen gestossen. Da macht ein Quad schon wesentlich mehr her. Mittlerweile würde ich aber auch 6 Threads nicht ablehnen. Bei Multicore Prozessoren geht's ja nicht nur um Multithreading, sondern vor allem auch um Multitasking.

Solange Windows Fest im Sattel sitz wird Bobcat nicht durch ARM Ersetzt werden und das K. O. Kriterium für ARM ist die starke x86 Softwareinfrastruktur!

Ich meinte damit das die Multicore Gescheitert ist, da (meistens) nur 1-4 Kerne Unterstützt werden und die ursprüngliche Planungen mit 32 und Mmehr Kernen pro Die aufgrund mangelnder Software-Unterstützung fallen gelassen wurde. Das Mhz Rennen ging recht lange das Multi-Core Rennen ist bei faktisch 4 Kernen (iCore i5/7) beendet worden (wenn man Server Außen verlässt), daher sehe ich es als Gescheitert an ;-)


Nichts desto trotz bin ich mir sicher, dass aus den eben genannten Gründen genug vom Kuchen für AMD abfällt.

Das hat sich damals Cyrix, VIA & Co. auch gedacht. Im Falle VIA hat der ATOM und Bobcat wohl den Rest gegeben. Es ist also nur eine Frage der Zeit bis die Nische von Intel als Attraktiv empfunden wird und Intel diese ausfüllen wird.
Da AMD Intel den AMD64 (x86-64 bit) Schock verpasst hat und Intel dem APU Konzept ziemlich schnell gefolgt ist (immer noch vier Kerne kaum IPC-Steigerungen immer mehr Transistoren für GPU) und im teilweise dicht auf den Fersen ist (Iris Pro), seit dem Schock hat AMD die volle Aufmerksamkeit von Intel und Intel folgt in vielen Punkten AMD.
 
Solange Windows Fest im Sattel sitz wird Bobcat nicht durch ARM Ersetzt werden und das K. O. Kriterium für ARM ist die starke x86 Softwareinfrastruktur!
Das gilt aber vor allem für den Desktop und Notebook Markt. Speziell bei Desktops hat Bobcat & Co bisher eher eine untergeordnete Rolle gespielt. Bei Smartphones und Tablets ist die x86 Softwareinfrastruktur bei weitem nicht so dominant. Ganz im Gegenteil, da ist sie nur ein kleines Licht. Was spricht also dagegen, für diese Märkte ARM Prozessoren zu nutzen, und für den Rest x86 Prozessoren ala Kaveri? Ich sehe ehrlich gesagt nicht viel, was dagegen spricht. IIRC soll der mobile Kaveri runter bis auf 15W gehen. 15-45W sind völlig iO für zB Notebooks. Dafür braucht es kein Bobcat & Co mit 10W und weniger. Und im Serverumfeld wird die Softwareinfrastruktur sowieso meist recht spezifisch angepasst. Da sollte eine Umstellung von x86 auf ARM auch nicht das Problem darstellen.

Ich meinte damit das die Multicore Gescheitert ist, da (meistens) nur 1-4 Kerne Unterstützt werden und die ursprüngliche Planungen mit 32 und Mmehr Kernen pro Die aufgrund mangelnder Software-Unterstützung fallen gelassen wurde.
Wer soll sowas denn geplant haben? Mir ist zumindest im Massenmarkt nichts davon bekannt. Kannst du das mit Quellen belegen?
 
Wenn ich mir aber die Software Entwicklung anschaue sind wir bei 1-4 Kernen die genutzt werden.

Schon mal auf einem Quadcore 2 Programme laufen lassen, welche 4 Kerne nutzen. Das Anwendungsszenario ist auch ein Punkt wieso viele sagen das Modern UI Startmenü in Win8 sei unbrauchbar. "Wenn ich das Startmenü aufmache sehe ich den Stream X/Y und Browser v und das VS Fenster nicht mehr".
 
Das MS einen dazu zwingt mit windows 8 den dekstop zu verlassen um eine neue Anwendung zu öffnen ist der größte Unsinn aller Zeiten.
Das alte Startmenü klappte auf der Seite auf und ich hatte beim suchen der zu startenden Applikation immernoch die gerade geöffneten Programme im Blick.
Aber nein, nun muss man ja plötzlich den ganzen Bildschirm mit schwarz überblenden nur um Notepad++ auf zu bekommen... -.-
Sorry aber wer sich das ausgedacht hat, gehört am nächsten B-Tree aufgehängt.

Dass Multithreading geschwitert ist, kann ich aber nicht unterschreiben. Die Leute machen nur den Fehler die schnellebige Hardware-Welt als Maßstab zu nehmen und zu erwarten dass sich die Software ebenso schnell ändert.
Einer der Gründe warum nicht mehr als 4 Kerne unterstützt werden ist schlicht die Tatsache dass Intel im Mainstream nicht mehr hat. *noahnung*
Entwickler, außerhalb von High-Performance oder Spezialanwendungen, orientieren ich an dem was sie haben. Und der erste Test-PC ist meisten erstmal der des Programmierers selbst.
Gerade die Jüngsten Erweiterungen der großen Programmiersprachen deuten aber keineswegs darauf hin dass Multithreading gestorben ist, sondern eher darauf dass es jetzt erst richtig losgeht ohne dem Entwicklervolk graue Haare zu bescheren.
Ich erinnere an C++0x, an java 8, welches mit closures und der Stream-Api in diese Richtung geht, C#, mit async und await ebenso wie mit Linq und dem ganzen asynchronen Kram der letzten Versionen.
Zwar muss aynnchron nicht zwangsweise multithreaded bedeuten, aber es bietet sich oft genug an.
Hier zeigt sich aber auch mal wieder dass asynchrones Programmieren wenig bis garnicht gelehrt wird und viele Entwickler bei foreach stehenbleiben.
Ich bin auch nicht sicher ob wir Software von der Stange als indikator nehmen können.
Auf diesen Bladeservern werden spezialisierte Programme laufen. Und die werden eben genau so und genau dafür geschrieben effizient ausgeführt zu werden. (ähnlich wie bei Konsolen)
Das ist was anderes als die "Ich klöppel mal schnell einen CSV-Export in Visual Studio zusammen" - Sparte.
Dass Intel aufholt ist nicht nur schwer zu bestreiten, es ist sogar mehr als logisch. - Es wäre eher ein Trauerspiel wenn die es bei Ihrem R&D Budget nicht schaffen würden sich nach all den Jahren auf ein vernünftiges Niveau zu tasten. - Das ist aber auch der Grund warum man den Vergleich sein lassen kann.
Selbst wenn AMD einen High-Performance x86er basteln würde, könnte Intel mit der besseren Fertigung ohne Weiteres eine Konkurrenz basteln und es sich sogar leisten diese mit Verlust zu verkaufen nur um AMD wieder aus dem Markt zu drängen. Der Flugzeugträger nimmt auch keine Rücksicht auf eine Segeljolle. *noahnung*
Mehrere kleine Kerne hat zumidnest den Vorteil dass nicht soviele Kontextwechsel pro Kern erfolgen, für die immer die Pipeline geleert werden muss usw.
Dennoch, das was wir als "Kleinen kern" bezeichnen, wäre vor wenigen Jahren noch absolutes Highend gewesen. Es ist also nicht so dass man damit nichts berechnen kann.
Übrigens haben die hochspezialisierten Lösungen abgesehen von der Energieeffizienz auch noch den wirtschaftlichen Vorteil dass eben neues gekauft werden muss wenn sich die Spielregeln ändern (3DES/AES, neue videocodecs usw) oder womit glaubt ihr will die Branche zukünftig ihre Wachstumsmargen halten? - Bestimmt nicht mit der ultimativen Super-CPU die alles im Standgas berechnen kann - den verkauft man nämlich nur 1 mal.
 
Schon mal auf einem Quadcore 2 Programme laufen lassen, welche 4 Kerne nutzen. Das Anwendungsszenario ist auch ein Punkt wieso viele sagen das Modern UI Startmenü in Win8 sei unbrauchbar. "Wenn ich das Startmenü aufmache sehe ich den Stream X/Y und Browser v und das VS Fenster nicht mehr".

Ja, ich hasste auch die Win8 Retro Oberfläche, Win 1.0 will come back. Aber mal ehrlich die meisten nutzen kaum eine Anwendung die vier Kerne auslastet geschweige denn zwei davon zu selben Zeit.


@ gruffi

Intel hatte das bei der (1. gen?) i7 Präsentation, finde es gerade aber nicht. Das Problem der Skalierbarkeit wollte man mit "intelligenten" Compilern umgehen um auch eine Skalierung bei 16 und Mehr Keren bei behalten zu können.

Hier ein Beispiel: http://www.computerbase.de/news/2009-12/intel-zeigt-prozessor-mit-48-kernen-in-aktion/
 
@ gruffi

Intel hatte das bei der (1. gen?) i7 Präsentation, finde es gerade aber nicht. Das Problem der Skalierbarkeit wollte man mit "intelligenten" Compilern umgehen um auch eine Skalierung bei 16 und Mehr Keren bei behalten zu können.

Hier ein Beispiel: http://www.computerbase.de/news/2009-12/intel-zeigt-prozessor-mit-48-kernen-in-aktion/
Das ist aber was ganz anderes als ein i3/i5/i7. Das entspringt dem Intel Tera Scale Forschungsprojekt (nicht zu verwechseln mit AMDs Tera Scale Architektur), aus dem ja Larrabee hervorgehen sollte, wegen Ineffizienz aber gecancelt wurde, und aus dem letztendlich die heutigen Intel Xeon Phi Prozessoren hervorgegangen sind. Das war schon immer eine spezielle Entwicklung für den HPC Markt und hat mit normalen Client Prozessoren für den Alltag überhaupt nichts zu tun. Dafür ist und war Tera Scale nie vorgesehen.
 
@gruffi

Sorry, hatte nur den ersten Absatz gelesen und nach Larrabee gesucht und nix gefunden.
 
Zurück
Oben Unten