News Acht-Kern-CPU mit Leistung satt bei 35 Watt

[gruffi]

Die Atom CPU ist keine von Grund auf neue Architektur sondern eine beschnittene Pentium Architektur.

Naja, wenn man so argumentiert, war der K8, mit welchem AMD64 bzw x86-64 eingeführt wurde, auch keine neue Architektur, sondern lediglich eine Weiterentwickelung des K7.

Da kann man nur hoffen, dass sich CUDA durchsetzt und somit den Weg von der x86 Architektur so effizienteren Architekturen freimacht.

CUDA wäre noch schlimmer. Also wenn schon, dann bitte OpenCL.

 

[noskill]

Sicherlich ist der K8 eine Weiterentwicklung der K7, der Atom ist aber keine "Weiterentwicklung" sondern ein stinknormaler Pentium, mit im Vergleich zum Prescott halben L2 Cache, einigen wegrationalisierten Befehlssätzen und kürzerer Befehlspipline.
Der Atom schlicht eine Billig-CPU.

Der K8 dagegen hatte nicht weniger als der Vorgänger sondern mehr und unter anderem war er der erste x86 mit integrierten Speichercontroller, was erheblichen Einfluss auf die Speicherbandbreite hatte.

Zu CUDA vs. OpenCL: dito

 

[Wiesi21]

@ noskill

die Larrabee Kerne sind alles andere als leistungsschwach. Sie sollen jeweils 16fach SIMD Einheiten beinhalten, was es bisher bei keinem x86 Kern gegeben hat (bisher glaub ich 4fach max.)

und mit nem Prescott hat der Atom genauso viel gemein wie mit nem aktuellen Core i7. Befehlssätze hat er mehr als dieser und was bitte soll denn die "Befehlspipeline" sein. Der Atom ist genauso neu entwickelt wie die Core 2 Architektur oder ähnliches, es gibt immer Ähnlichkeiten zu bisherigen Designs.

 

[lizard1337]

fuer desktop pls ! , und unter 300$ auf sockel 775 gemacht

 

[noskill]

@Wiesi21

Die ersten Atom (Silverthorne) haben kein EM64T ausserdem haben alle kein SSE4 und keine out-of-order execution die es schon seit dem P1 Pro gab.

Erklär mir also was am Atom neuentwickelt wurde! Es wurde wegrationalisiert und trotzdem die Meinung verbreitet, dass der Atom eine "WunderCPU" ist.

Zum Larrabee:
Das sind alles in-order execution Kerne.
Nur ist der Larrabee eben extrem parallelisiert im Vergleich zu x86 CPUs deshalb die 16 ALUs pro Kern. Das ist nichts halbes und nichts ganzes und einfach der Versuch die Programmierer weiterhin an x86 zu binden um weiterhin dominant im Markt zu bleiben.

 

[MountWalker]

Die In-Order-Execution kann auch Vorteile haben, wenn wir mal wieder das Feld dieser News betreten ("RISC"- bzw. Prozessoren mit Load-Store-Architektur) gibts ein hervorragendes Beispiel für die sinnvolle Wiedereinführung der In-Order-Execution: IBM Power5 nutzt Out-Of-Order-Execution, Power6 ist wesentlich leistungsfähiger als Power5 und nutzt In-Order-Execution.

zu Atom:
Intel's Atom Architecture: The Journey Begins
Small wonder: inside Intel's Silverthorne ultramobile CPU
zu Larrabee:
Intel's Larrabee Architecture Disclosure: A Calculated First Move

 

[gruffi]

Sicherlich ist der K8 eine Weiterentwicklung der K7, der Atom ist aber keine "Weiterentwicklung" sondern ein stinknormaler Pentium, mit im Vergleich zum Prescott halben L2 Cache, einigen wegrationalisierten Befehlssätzen und kürzerer Befehlspipline.

Nun ja, ganz so ist es nicht. Keine Ahnung, inwiefern Atom noch mit dem Ur-Pentium vergleichbar ist. Aber gegenüber den letzten Pentiums unterschiedet er sich doch deutlich. Alleine schon aufgrund der In-Order Pipeline. Von Grund auf neu wurde er natürlich nicht entwickelt.

Die In-Order-Execution kann auch Vorteile haben, wenn wir mal wieder das Feld dieser News betreten ("RISC"- bzw. Prozessoren mit Load-Store-Architektur) gibts ein hervorragendes Beispiel für die sinnvolle Wiedereinführung der In-Order-Execution: IBM Power5 nutzt Out-Of-Order-Execution, Power6 ist wesentlich leistungsfähiger als Power5 und nutzt In-Order-Execution.

Das liegt aber nicht an In-Order selbst. Das ist hoffentlich klar? In-Order ist konzeptionell erstmal weniger performant als Out-of-Order. Der Power6 wurde ja an einigen anderen Stellen ordentlich aufgebohrt, sicherlich auch möglich durch die schlankere Pipeline, was ihn letztendlich leistungsfähiger macht.

 

[MountWalker]

Das liegt imho durchaus auch (unter anderem) an In-Order selbst, denn Out-Of-Order braucht nicht nur zusätzliche Die-Fläche, sondern auch zusätzlichen Strom. Wenn ich die Out-of-Order-Unterstützung rauskloppe, habe ich bei gleicher Frequenz deutlich weniger Stromverbrauch, was bedeutet bei gleichem Stromverbrauch kann ich die Arbeits-Frequenz des Prozessors deutlich erhöhen. (Power6 läuft mittlerweile mit 5 GHz, das packt bisher keine OoOE-Archtitektur - benutzbare Produkte wohlgemerkt, keine Overclocking-Ergebnisse, denn da ist der Power6 auch schon über 6 GHz)

Es hängt vom Anwendungsfeld ab, ob die Out-Of-order-Execution oder die höhere Frequenz mehr Leistung bringt, aber dass Out-Of-Order immer automatisch besser wäre ist ein Irrglaube aus einer Zeit, in der Stromverbrauch ein Randgruppenthema war. In einem Desktop-Rechner, auf dem zwei verschiedene Web-Browser, eine Musikbibliothekwiedergabesoftware, ein Videoplayer (bspw. im Webbrowser), eine Java-Anwendung und ein Videochatprogramm gleichzeitig laufen und ich dann noch nebenbei ein paar Sachen in Cinema4D rendern lasse oä., ist es vermutlich sinnvoll die Frequenz ("Taktrate") des Prozessors zugunsten von OoOE zu verringern, die Frage ist aber ob Atom-Rechner auch tatsächlich so benutzt werden. Und Power- oder SPARC-Rechner werden vermutlich sowieso nicht so verschiedene Aufgaben gleichzeitig zu rechnen haben (bei denen die Input-Daten so ungleichmäßig vorliegen), dass sich das Opfern von Frequenz für OoOE wirklich lohnen würde.

P.S.
Für Spiele, die für 90% aller Computeranwender wichtigste prozessorauslastende Anwendung, könnte möglicherweise Out-Of-Order auch weniger lohnend sein, als man denkt, sonst hätte IBM für die XBox360 statt eines In-Order-Tricore mit 3,2 GHz vielleicht einen Out-Of-Order-Dualcore mit 3,2 GHz gebaut.

 

[Wiesi21]

@noskill

Du hast aber gesagt im Vergleich zum Prescott. Der hat auch kein SSE4, und dass der Atom kein 64bit unterstützt ist in dieser Leistungsklasse sicher das geringste Problem.

Unter deinen Gesichtspunkten, könnte ich genauso fragen was am Core2 oder Core i7 neu entwickelt wurde, welche ja auch am Pentium M bzw. am P2, P3 aufbauen ...
natürlich greift man meist wieder auf bestehende Technologien zurück, gerade bei einer CPU wie dem Atom, welche nicht neue Leistungsspitzen erklimmen soll, sondern auf Verbrauch und niedrige Kosten hin optimiert ist. Als solche CPU "ist" er eine Neuentwicklung, und niemand hat behauptet er wäre eine Wunder CPU. Trotzdem gab es eine solche CPU wie den Atom vorher nicht --> Neuentwicklung

ich möchte echt Mal wissen, worauf du deinen Unmut beziehst, bzw. auf solche Aussagen wie "nichts halbes oder ganzes" kommst.
Wolltest auch mal auf den x86 Verachter Zug aufspringen, weil's mal wieder in aller Munde ist, obwohl der Streit sowas von sinnlos ist, da x86 bzw. die Inkarnationen von AMD, Intel keinerlei Vergleich mit irgendwelchen RISC Architekturen scheuen müssen und in vielen Bereichen durchaus große Vorteile besitzen.
Es kommt einfach immer auf das Einsatzszenario an, und bei den heutigen Monsterchips mit Riesencache, macht der x86 Wrapper einen vernachlässigbar kleinen Teil aus, sorgt aber eben für etliche Vorteile bei der Software...

und beim Larrabee ist Out-Of Order Execution sicher nicht die Mehrkosten der Implementation wert, da er ohnehin einen effizienten Sheduler benötigt, und weitere Umsortierung in den Kernen nicht nötig sein sollte. (Bei den Berechnungen, für welche Larrabee gedacht ist, ist In-Order sicher auch absolut gesehen der bessere Weg)

 

[MountWalker]

Naja, der wichtigste Unterschied zwischen RISC und CISC ist ja eigentlich etwas, das auch ein Core2, egal wie der intern aufgebaut ist, zu CISC macht und einen nachteil bildet, den noch so starke Vermehrung der Kerne hinter der Decoder-Einheit der CPU nicht schmälert: RISC versus CISC

siehe auch Instruction set size and alternative terminology

 

[Wiesi21]

tja, Hardwarenachteil (im Sinne von Chipflächenmehrverbrauch) aber Softwarevorteil....

 

[MountWalker]

Nein, es geht eben nicht nur um Chipfläche.

Separating the "LOAD" and "STORE" instructions actually reduces the amount of work that the computer must perform. After a CISC-style "MULT" command is executed, the processor automatically erases the registers. If one of the operands needs to be used for another computation, the processor must re-load the data from the memory bank into a register. In RISC, the operand will remain in the register until another value is loaded in its place.
...
The CISC approach attempts to minimize the number of instructions per program, sacrificing the number of cycles per instruction. RISC does the opposite, reducing the cycles per instruction at the cost of the number of instructions per program.

 

[Wiesi21]

intern wird doch auch bei den x86er Prozessoren mit RISC gearbeitet, um die dadurch möglichen Optimierungen mitzunehmen, moderne x86 CPUs halten Daten im Cache vor und haben extrem ausgefeilte Pre-Chaching Algorithmen um stets alle benötigten Daten zur Verfügung zu haben "lange bevor" sie bearbeitet werden. Der Hauptunterschied zwischen nem neuen x86 und z.B. nem neuen PowerPC ist der x86 Wrapper, intern hat sich vieles angeglichen, da auch die Power PC Architektur nicht mehr wirklich RISC im Sinne eines reduzierten Befehlssatzes ist (man denke an AltiVec).

Weiters merkt man im Desktop den "Nachteil" nicht wirklich, die Core2 bzw. Corei7 oder auch Barcelona Architektur als jüngste Inkarnationen von x86, sind bis auf einige Ausnahmeanwendungen der Konkurrenz überlegen, ob dies nur am technologischen Fortschritt Intels, AMDs liegt ist letztlich egal....

 

[noskill]

@noskill

Du hast aber gesagt im Vergleich zum Prescott. Der hat auch kein SSE4, und dass der Atom kein 64bit unterstützt ist in dieser Leistungsklasse sicher das geringste Problem.

Unter deinen Gesichtspunkten, könnte ich genauso fragen was am Core2 oder Core i7 neu entwickelt wurde, welche ja auch am Pentium M bzw. am P2, P3 aufbauen ...
natürlich greift man meist wieder auf bestehende Technologien zurück, gerade bei einer CPU wie dem Atom, welche nicht neue Leistungsspitzen erklimmen soll, sondern auf Verbrauch und niedrige Kosten hin optimiert ist. Als solche CPU "ist" er eine Neuentwicklung, und niemand hat behauptet er wäre eine Wunder CPU. Trotzdem gab es eine solche CPU wie den Atom vorher nicht --> Neuentwicklung

ich möchte echt Mal wissen, worauf du deinen Unmut beziehst, bzw. auf solche Aussagen wie "nichts halbes oder ganzes" kommst.
Wolltest auch mal auf den x86 Verachter Zug aufspringen, weil's mal wieder in aller Munde ist, obwohl der Streit sowas von sinnlos ist, da x86 bzw. die Inkarnationen von AMD, Intel keinerlei Vergleich mit irgendwelchen RISC Architekturen scheuen müssen und in vielen Bereichen durchaus große Vorteile besitzen.
Es kommt einfach immer auf das Einsatzszenario an, und bei den heutigen Monsterchips mit Riesencache, macht der x86 Wrapper einen vernachlässigbar kleinen Teil aus, sorgt aber eben für etliche Vorteile bei der Software...

und beim Larrabee ist Out-Of Order Execution sicher nicht die Mehrkosten der Implementation wert, da er ohnehin einen effizienten Sheduler benötigt, und weitere Umsortierung in den Kernen nicht nötig sein sollte. (Bei den Berechnungen, für welche Larrabee gedacht ist, ist In-Order sicher auch absolut gesehen der bessere Weg)

Ich beziehe meinen "Unmut" (wie du völlig abwegig schreibst) eher auf die extreme Verbreitung einer ineffizienten CISC Architektur.
x86 stammt aus einer Zeit, in der Programme sehr simpel gestrickt waren und oft aus mehreren sich wiederholenden Folgen bestanden.

Für die Anwendungen im Heimrechner, Server, etc. ist diese Architektur heutzutage völlig unbrauchbar, da man um "alle" inzwischen häufig vorkommenden Befehlsfolgen abzudecken die CPU unwahrscheinlich aufblähen müsste und wie es seit Jahren der Fall ist regelmäßig neue "Befehlssätze" entwickeln muss.
Stattdessen könnte man den Platz sparen den ein CISC braucht, mehr ALUs in die CPU bauen und so für heutige sehr unterschiedliche Anwendungen deutlich mehr Leistung bereitstellen.

Jetzt wo CUDA, OpenCL und Stream einen Weg betreten der von der x86 Architektur im Consumer-Bereich wegführt, kommt Intel und will dort mit Larrabee alles wieder zur x86 Architekur bewegen.

Um zum Topic zurück zu kommen:
Diese CPU zeigt, das Intel eben nicht das Maß der Dinge wenn es um CPUs geht sondern sich nur durch die extreme Verbreitung seiner eigenen x86 Architektur im Markt halten kann.

 

[Wiesi21]

wenn du das wirklich so glaubst, müssen wir nicht weiter diskutieren....

diese CPU zeigt gar nichts, solange nicht genau feststeht unter welchen Bedingungen sie diese Leistung erbringt, und ob sie nicht dafür an anderer Stelle einbricht.
Die neuen Befehlssätze "blähen" die CPU nur minimal auf, da sie ohnehin in RISC artige MicroOps aufgesplittet, und dann sogar zusammengefasst abgearbeitet (MicroOp Fusion) werden können.
Außerdem haben eben auch beinahe alle RISC Architekturen solche Erweiterungen, da diese Programme sehr stark beschleunigen können.
Für einen Rechner, welcher immer die gleiche Aufgabe erfüllen muss, ist ein angepasstes RISC Design sicher besser, aber bei multiplem Code, werden halt die Zusatzeinheiten, Branch Predictors, Cache Logic immer wichtiger, um die reinen Ausführungseinheiten nicht nutzlos idlen zu lassen, und hier ist Intel jedenfalls teilweise weit vorraus...

 

[gruffi]

Das liegt imho durchaus auch (unter anderem) an In-Order selbst, denn Out-Of-Order braucht nicht nur zusätzliche Die-Fläche, sondern auch zusätzlichen Strom. Wenn ich die Out-of-Order-Unterstützung rauskloppe, habe ich bei gleicher Frequenz deutlich weniger Stromverbrauch, was bedeutet bei gleichem Stromverbrauch kann ich die Arbeits-Frequenz des Prozessors deutlich erhöhen.

Das habe ich doch geschrieben. Bedingt durch die schlankere Pipeline konnte man den Power6 an diversen Stellen aufbohren, wie eben auch die Taktfrequenz, was sonst wohl nicht möglich gewesen wäre. In-Order selbst ist aber nicht für die Leistungssteigerung verantwortlich. Oder anders formuliert, ein Power6 mit Out-of-Order statt In-order Ausführung wäre sicherlich noch um einiges performanter, technisch in der aktuellen Form aber wohl nicht zu realisieren.

 

[noskill]

Außerdem haben eben auch beinahe alle RISC Architekturen solche Erweiterungen, da diese Programme sehr stark beschleunigen können.

Das stimmt (teilweise und nur bei echten CISC) aber man kann mit diesen Erweiterungen immer nur einen Bruchteil beschleunigen. Was ist also sinnvoller?
Eine RISC CPU bauen und die meisten Befehle direkt verarbeiten lassen oder eine CISC CPU bauen, die alle einkommenden komplexen Befehle durch einen Wandler schickt und dann doch über RISC verarbeitet (siehe moderne x86 CPUs).
Den Wandler kann man als Tiefpass sehen und der begrenzt die maximale Arbeitsfrequenz, erhöht den Leistungsbedarf und die benötigte Chipfläche.

wenn du das wirklich so glaubst, müssen wir nicht weiter diskutieren....

Das habe ich extra überzogen, weil vorallem für viele Heimanwender aber auch Businessanwender immer ausschließlich Intel das Maß aller Dinge ist.
Und dieses Bild bestimmt nunmal ob wir in 20 Jahren immer noch x86 haben, oder ob sich dann endlich stark parallelisierte RISC Prozessoren durchgesetzt haben.

Für einen Rechner, welcher immer die gleiche Aufgabe erfüllen muss, ist ein angepasstes RISC Design sicher besser, aber bei multiplem Code, werden halt die Zusatzeinheiten, Branch Predictors, Cache Logic immer wichtiger, um die reinen Ausführungseinheiten nicht nutzlos idlen zu lassen, und hier ist Intel jedenfalls teilweise weit vorraus...

Das ist ein veraltetes Bild von RISC, dass seit Jahrezehnten überholt sein dürfte (spätestens seit dem ARM).
Ein CISC (und nur echtes CISC) ist genauso bzw. gerade nur bei gleichartigen Anwendungen leistungsstärker (allerdings kommt der Arbeitstakt nicht so hoch), während ein RISC Rechner viel anpassungsfähiger ist (alles lässt sich auf drei Befehlstypen zurückführen) höhere Taktraten erreichen kann, weniger Leistung benötigt und stärker parallelisiert werden kann, da er kleiner baut.

dann sogar zusammengefasst abgearbeitet (MicroOp Fusion) werden können.

Darum geht es ja bei einem CISC Rechner.
Es wird also hier (x86) erst aufgesplittet dann gewandelt in RISC Befehle und anschließend einige RISC Befehle wieder von zwei Befehlen zu einem Befehl zusammengefasst.

 

[Wiesi21]

tja, dann würd ich vorschlagen du kauftst dir ne RISC CPU kompilierst dir n Linux dazu und wirst ob der überlegenen Plattform glücklich....

 

[Azi]

Wenn es wirklich eine CPU geben würde, die bei 35 Watt in allen belangen einem Core 2 Quad oder i7 überlegen wäre, würde der umstieg extremst schnell von statten gehen und auch MS ein OS dafür entwickeln.

Das ist aber schlicht nicht der Fall und hier und da hypen ein paar Fanboys oder "Pseudo - Auskenner" eine andere CPU die dann, wenn sie real existiert, von einem aktuellen x86 den erdboden gleich gemacht wird.

x86 hat inzwischen sogar supercomputer- und servermarkt in fester hand, wo auch oft alternative OS eingesetzt werden für die ein anderer Befehlssatz als x86 durchaus praktikabel ist.

 

[MountWalker]

..., da auch die Power PC Architektur nicht mehr wirklich RISC im Sinne eines reduzierten Befehlssatzes ist (man denke an AltiVec).
...

Siehe auch den sehr gut auch von sehr fachkundigen Leuten ausdiskutierten englischen Wikipedia-Artikel zu RISC, deine Annahme, was RISC wäre, ist ein weit verbreiteter Irrtum. RISC bedeutet nicht reduzierter Befehlssatz, sondern reduzierte Instructionen - es dürfen auch deutlich mehr Instruktionen sein, als bei CISC, wichtig ist einzig und allein, dass jede Instruktion nur genau eine Aufgabe hat. Das macht auch die Bedeutung von MULT versus Load+Store deutlich, den ich verknüpft habe.

... ein Power6 mit Out-of-Order statt In-order Ausführung wäre sicherlich noch um einiges performanter, technisch in der aktuellen Form aber wohl nicht zu realisieren.

Nein, denn sobald diese frequenz mit Out-Of-Order möglich wäre, wäre automatisch ohne Out-Of-Order noch deutlich mehr Frequenz möglich. Der Unterschied bleibt relativ gleich, es gleicht sich nichts an.

Wenn es wirklich eine CPU geben würde, die bei 35 Watt in allen belangen einem Core 2 Quad oder i7 überlegen wäre, würde der umstieg extremst schnell von statten gehen und auch MS ein OS dafür entwickeln. ...

Das ist größtenteils richtig, bei den großen Desktop-Prozessoren macht der aufwendige Decoder nicht so wahnsinnig viel aus und der verschwenderische Speicherzugriff durch MULT statt Load+Sore wird durch exorbitante Caches auf dem Die ganz gut in Schach gehalten. Unterm Strich mrkt man in üblichen Desktop-/Workstation-Anwendungen insbesondere wenn man nur Dual-Core-prozessoren benutzt derzeit keine Ausbremsung des Prozessors durch zu langsamen RAM. (mein Core2Duo E7200 läuft auf meinem Board nur mit "DDR2-700"-RAM-Einstellung stabil, obwohl DDR2-1066-RAM verbaut ist und ich merke keinen geschwindigkeitsunterschied zu DDR2-1066, abgesehen von den Ausfällen mit DD2-1066-Einstellung durch die dort auftretenden Abstürze)

Allerdings habe ich meine Probleme mit dem Urteil "nicht überlegen", weil es irgendwie ohne das wörtchen deutlich und mit deinem folgenden zweiten und dritten Absatz, auch mir scheint, als schliche sich da eine vorgehaltene Aussage mit hinein, es wäre nicht besser. Der Load-Store-Ansatz ist erstmal in der heutigen Software-Realität besser, dh. wenn die Masse an Investment-Kapital, die bei x86 landet, woanders landen würde, hätten wir vielleicht noch schnellere Prozessoren. Der Unterscied ist nur nicht hinreichend besser, dass sich der Umstieg wirklich lohnt. Adrian Kingsley-Hughes hat dieses "nicht-hinreichend" mal mit zahllosen Beispielen aus der Computergeschichte belegt, angefangen von der Dvorak-Tastatur bis zum Trackball. Umstieg bedeutet immer Aufwand und sowas investiert man eben nur, wenns nicht nur einen Vorteil, sondern einen sehr sehr deutlichen Vorteil gibt.

Der größte RISC-Vertreter, IBM Power, hat nur noch In-Order-Designs im Programm - eine Desktop-Konkurrenz für den starken Multitaskingeinsatz auf Single-Board-Computern existiert damit momentan nicht mal mehr theoretisch. Entwickeln müsste Microsoft aber ein OS für eine andere Architektur genauso wenig, wie Apple ein OS X für x86 neuentwickeln musste.

X86 hat Nachteile, die Codekompatibilität ist für den Markt, für die Kundschaft, nur zu wichtig und die Vorteile eines Wechsels sind eben nicht groß genug um den Nachteil aufzuwiegen. Viele Anwendungen interessieren sich gar nicht mehr primär für Leistung, und die, die im Consumermarkt noch richtig viel Leistung brauchen, werden die CPU in ein paar Jahren nur noch als Steuerchip für OpenCL benutzen, so wie der PPC im Cell auch nur noch als Steuerchip dient. Die eigentliche CPU selbst verliert damit im Desktop- und Workstation-Einsatz eh an Bedeutung und damit auch die Frage welchen Befehlssatz dieser zentrale Steuerkern benutzt. Mit den zukünftigen Prozessordesigns von intel und AMD wandern die OpenCL-Recheneinheiten sogar mit auf den Prozessor-Die, insofern finde ich den Vergleich mit Cell ganz passend.