PDA

Archiv verlassen und diese Seite im Standarddesign anzeigen : Intel Polaris: 80 Kerne, 1 Teraflop bei 62 Watt


crux2005
2007-02-12, 13:04:41
Intel Polaris: 80 Kerne, 1 Teraflop bei 62 Watt

Intels Forschungsabteilung hat mit dem Ziel die Rechenleistung eines Supercomputers auf einen Chip zu packen einen Prozessor mit insgesamt 80 Rechenkernen mit dem Codenamen Polaris entwickelt. Er erreicht eine Rechenleistung von einer Billion Fließkommaoperationen pro Sekunde (Teraflops).

http://www.computerbase.de/news/hardware/prozessoren/intel/2007/februar/intel_polaris_80_kerne_1_teraflop_62_watt/

Tigerchen
2007-02-12, 15:11:43
Reine Fließkommakerne. Einfachster Aufbau. Wird niemals ein reales Produkt. Interessante Kühlung. Ist was zum angeben.

Für Technikfreaks sicher interessant um zu sehen was so machbar ist. Für mich hört sich das so nach dem guten, alten Aal-Jupp vom Hamburger Fischmarkt an.;D

Stone2001
2007-02-12, 15:42:50
Vgl. MIT RAW!

Des beste am ganzen Chip ist doch die Tatsache, das die Cores keine x86-Cores sind. :D

Coda
2007-02-12, 16:22:34
Des beste am ganzen Chip ist doch die Tatsache, das die Cores keine x86-Cores sind. :D
Aha. Und wieso?

Mastermind
2007-02-12, 17:56:13
IIRC gibbet dazu schon nen Fred :|

Stone2001
2007-02-12, 22:47:47
Aha. Und wieso?
Kann man sich doch denken, oder?

Die Schlussfolgerung aus der Tatsache, das Intel ein Nicht-x86-Kern als Basis für ihre Tera-Scale-Architektur verwendet, kann jeder selber ziehen.

Ich persönlich hoffe, dass sie auch bei der Nicht-x86-Architektur bleiben, dann gibt es vielleicht in naher Zukunft auch wieder Computerarchitektur-Projekte, die als Basis einen Mainstream-Prozessor haben. Bisher musste man auf MIPS, bestenfalls PowerPC zurückgreifen.
Allerdings wird es sehr schwer werden, x86 als Basis-Architektur abzulösen, dafür ist die Code-Basis schlich und einfach zu groß.

Gast
2007-02-12, 23:22:11
Die Schlussfolgerung aus der Tatsache, das Intel ein Nicht-x86-Kern als Basis für ihre Tera-Scale-Architektur verwendet, kann jeder selber ziehen.

Ja. Für einen möglichst primitiven Kern, der nur 10 Befehle zum Testen kennen muss, macht x86 keinen Sinn.

Stone2001
2007-02-13, 10:09:44
Ja. Für einen möglichst primitiven Kern, der nur 10 Befehle zum Testen kennen muss, macht x86 keinen Sinn.
Ich gehe mal davon, das etwas mehr als 10 Befehle integriert worden sind. x86 wird sich wahrscheinlich durch die komplexe Dekodierung ausgeschlossen haben. Die Frage ist nun, welchen Befehlssatz nun verwendet wird? Der vom i860?

Im Hinblick auf das wahrscheinliche Einsatzgebiet ist eine Abkehr von x86 auch nicht weiter schlimm, für "Everyday Computing" dagegen schon. Dafür ist die Codebasis einfach zu groß, aber der Chip wurde wahrscheinlich dafür auch nicht entwickelt.

Magnum
2007-02-13, 10:20:43
Naja, laut heise-Newsticker (link (http://www.heise.de/newsticker/meldung/85119)) ist das nächste Ziel von Intel, diesen Chip auf einer x86-Architekur basierend zu bauen! Also da wirds wohl nix mit einer Abkehr von x86!

Spasstiger
2007-02-13, 10:50:12
Naja, laut heise-Newsticker (link (http://www.heise.de/newsticker/meldung/85119)) ist das nächste Ziel von Intel, diesen Chip auf einer x86-Architekur basierend zu bauen! Also da wirds wohl nix mit einer Abkehr von x86!
Ah, schade. Die Ingenieure haben sicher ihren Spass mit Polaris. Mal von Grund auf neu aufbauen können ohne an die x86-Diktatur gebunden zu sein. Die x86-Architektur gehört ja mit zu den hässlichsten Prozessorarchitekturen.

Stone2001
2007-02-13, 10:57:45
Naja, laut heise-Newsticker (link (http://www.heise.de/newsticker/meldung/85119)) ist das nächste Ziel von Intel, diesen Chip auf einer x86-Architekur basierend zu bauen! Also da wirds wohl nix mit einer Abkehr von x86!
Verdammt! Geht die Herrschaft von x86 im PC-Markt wohl weiter...

Mastermind
2007-02-13, 11:07:32
Hö, was habt ihr denn alle gegen x86? :|

Stone2001
2007-02-13, 11:13:02
Hö, was habt ihr denn alle gegen x86? :|
Leider nichts was hilft... :frown:
Schreib mal einen Dekodierer für eine RISC-Architektur und einen für x86, dann kennst du die Antwort.
Hinzukommen noch weitere Faktoren, wie z.B: die begrenzte Anzahl von Register, ...

Tigerchen
2007-02-13, 15:09:16
Leider nichts was hilft... :frown:
Schreib mal einen Dekodierer für eine RISC-Architektur und einen für x86, dann kennst du die Antwort.
Hinzukommen noch weitere Faktoren, wie z.B: die begrenzte Anzahl von Register, ...


AMD hat doch was bei den Registern getan im 64 Bit Modus. Nach deren Ausssage würden noch mehr direkt verfügbare Register eher wenig bringen.

Im übrigen ist es immer wieder interessant wie Technikfans nur auf die Möglichkeiten möglichst neuer Architekturen achten (auch bei Grafikchips) und die Bedürfnisse der Mehrheit der Anwender einfach ignorieren. Ja diese geradezu als bedeutungslos hinstellen.

paul.muad.dib
2007-02-13, 16:10:39
Könnt ihr euch vorstellen, dass eine Multi-Core CPU erscheint, die in Single Threaded Anwendungen, oder solchen die nur auf zwei Kerne optimiert sind, langsamer ist als aktuelle CPUs?
Das würde dann ja heiße, dass heutige Spiele darauf nicht mehr laufen würden.

Wenn ja, wie lange würde es dauern, bis sich solche CPUs durchsetzen?

Fatality
2007-02-13, 16:19:15
Im übrigen ist es immer wieder interessant wie Technikfans nur auf die Möglichkeiten möglichst neuer Architekturen achten (auch bei Grafikchips) und die Bedürfnisse der Mehrheit der Anwender einfach ignorieren. Ja diese geradezu als bedeutungslos hinstellen.



Diese Einstellung treibt den Fortschritt voran. Abgesehen davon verallgemeinerst bzw übertreibst du mal wieder maßlos :rolleyes:

Halte dich doch einfach aus solchen themen heraus, wenn dir das zu hoch ist.


Ich finde den Fortschritt gewaltig, es zeigt einen möglichen Weg den die Industrie gehen könnte.

desweiteren macht es keinen Sinn eine Anwendung auf 2 Cores zu "begrenzen", ein anständiger dev setzt gleich auf multicore.

Trap
2007-02-13, 17:15:06
Leider nichts was hilft... :frown:
Schreib mal einen Dekodierer für eine RISC-Architektur und einen für x86, dann kennst du die Antwort.
Dekoder sind nichtmal mehr 5% der Chipfläche. Für x86 braucht man außerdem weniger I-Cache und Speicherbandbreite, ob das im Endeffekt teurer ist wär ich mir nicht so sicher.

Spasstiger
2007-02-13, 17:22:25
Hö, was habt ihr denn alle gegen x86? :|
Aus Sicht des Anwenders ist x86 toll - kompatibel zu bestehender Software und sauschnell dank Fokusierung der großen Hersteller AMD und Intel auf x86.
Für einen Ingenieur ist x86 aber hässlich und aufgeblasen. Es gibt aus Ingenieurssicht deutlich schönere Architekturen (z.B. viel "RISCiger" und objektorientiert), aber der Wechsel wird halt wegen der breiten Softwarebasis für x86 nicht vollzogen.

Tigerchen
2007-02-13, 17:29:53
Diese Einstellung treibt den Fortschritt voran. Abgesehen davon verallgemeinerst bzw übertreibst du mal wieder maßlos :rolleyes:

Halte dich doch einfach aus solchen themen heraus, wenn dir das zu hoch ist.


Ich finde den Fortschritt gewaltig, es zeigt einen möglichen Weg den die Industrie gehen könnte.

desweiteren macht es keinen Sinn eine Anwendung auf 2 Cores zu "begrenzen", ein anständiger dev setzt gleich auf multicore.


Völlig falsch. Niemand schreibt was von "auf 2 Cores begrenzen". Ich seh nur schlicht nicht ein warum ich auf meine Softwareschätze verzichten soll nur weil ein paar technikverliebte Programmierer den radikalen Schritt weg von x86 haben wollen. Eine Emulation ist auch kein Ausweg wie wir bei dem supertollen , RISC Itanium gesehen haben.

Stone2001
2007-02-13, 17:35:18
Dekoder sind nichtmal mehr 5% der Chipfläche.
In welcher Implementierung verbraucht der Dekoder 5% der Chipfläche? (nur mal aus purer Neugier)
Einen Dekoder für eine RISC-Architektur zu schreiben ist einfach, einen x86-Dekoder nicht wirklich. Nicht umsonst weigern sich die meisten in akademischen Umfeld erhältlichen Simulatoren (z.B. SimpleScalar) x86 zu unterstützen (SIMICS ist da eine Ausnahme, wenn auch nur funktional).
Für x86 braucht man außerdem weniger I-Cache und Speicherbandbreite, ob das im Endeffekt teurer ist wär ich mir nicht so sicher.
hmm, ist schon eine Weile her, dass ich RISC-Assembler-Code mit x86-Assembler-Code verglichen habe, aber damals hatte der x86-Code wesentlich mehr Load und Stores im Vergleich zum RISC, gerade aufgrund der niedrigen Registeranzahl. Ob x86 also weniger Speicherbandbreite benötigt, wage ich zu bezweifeln. (aber auch hier gilt, falls du irgendwelche Quellen hast, immer her damit, ich lasse mich gerne eines besseren belehren)
Der kompakte Code ist ja ein Merkmal von CISC-Architekturen, deswegen kann es durchaus sein, dass der x86-Code im Vergleich kleiner ist.

Tigerchen
2007-02-13, 17:39:06
Aus Sicht des Anwenders ist x86 toll - kompatibel zu bestehender Software und sauschnell dank Fokusierung der großen Hersteller AMD und Intel auf x86.
Für einen Ingenieur ist x86 aber hässlich und aufgeblasen. Es gibt aus Ingenieurssicht deutlich schönere Architekturen (z.B. viel "RISCiger" und objektorientiert), aber der Wechsel wird halt wegen der breiten Softwarebasis für x86 nicht vollzogen.


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

Trap
2007-02-13, 17:59:30
Ein bisschen was an Zahlen gibt es da:
http://developer.amd.com/assets/WinHEC2005_x86_Everywhere.pdf (ist aber nicht wirklich gut das Paper)

Die gegenüber RISC zusätzlich vorhandenen loads und stores gehen vermutlich hauptsächlich auf Cachebandbreite, kaum auf Speicherbandbreite. Zahlen dazu hab ich leider nicht, ist nicht mein Fachgebiet.

transstilben
2007-02-13, 18:04:09
Dekoder sind nichtmal mehr 5% der Chipfläche. Für x86 braucht man außerdem weniger I-Cache und Speicherbandbreite, ob das im Endeffekt teurer ist wär ich mir nicht so sicher.

Und was ist mit SSE1/SSE2/SSE3/SSE4 ? Wenn's nach mir ginge: Ich könnte gut drauf verzichten, wenn ich dafür 80 einfache,
universell nutzbare Kerne bekäme. Mit anderen Worten: Ich glaube nicht, daß wir mehr als 8 echte X86 Kerne (inklusive SSE2) jemals auf einem Chip sehen werden !

Ich hoffe jetzt stößt mich niemand aus dem Fenster aus dem ich mich gerade weit herauslehne. ;)

Trap
2007-02-13, 18:26:05
Und was ist mit SSE1/SSE2/SSE3/SSE4 ? Wenn's nach mir ginge: Ich könnte gut drauf verzichten, wenn ich dafür 80 einfache,
universell nutzbare Kerne bekäme.
SSE kann man auch per Microcode implementieren :biggrin:

80 cores wie sie jetzt aussehen sind wären auch möglich, braucht man halt bei gleicher die-size 10 nm Fertigungstechnik. Hängt aber von der Entwicklung auf der Softwareseite ab ob sowas tatsächlich mal entwickelt wird.

transstilben
2007-02-13, 19:32:17
SSE kann man auch per Microcode implementieren :biggrin:

80 cores wie sie jetzt aussehen sind wären auch möglich, braucht man halt bei gleicher die-size 10 nm Fertigungstechnik. Hängt aber von der Entwicklung auf der Softwareseite ab ob sowas tatsächlich mal entwickelt wird.

Mit 80 dummen Kernen kann man EINE SSE2-Einheit auch schön nachbilden ;)
Ich bleibe dabei: Bei 8 echten X86 Kernen auf einem Chip ist Schluß.
Die Fläche kann man für andere Dinge viel sinnvoller nutzen (IMHO), als sie mit aufgeblähten, aufgebohrten (EM64T) X86 Kernen zu verschwenden.

Stone2001
2007-02-13, 21:21:59
... (ist aber nicht wirklich gut das Paper)
Da gebe ich dir recht! ;)

Die gegenüber RISC zusätzlich vorhandenen loads und stores gehen vermutlich hauptsächlich auf Cachebandbreite, kaum auf Speicherbandbreite. Zahlen dazu hab ich leider nicht, ist nicht mein Fachgebiet.
hmm, kann gut sein! Mal schaun, wenn ich nächste Woche mal Zeit habe, werde ich mich mal in die Archive von IEEE begeben und schauen ob ich was finde.
Mit 80 dummen Kernen kann man EINE SSE2-Einheit auch schön nachbilden ;)
Ich bleibe dabei: Bei 8 echten X86 Kernen auf einem Chip ist Schluß.
Die Fläche kann man für andere Dinge viel sinnvoller nutzen (IMHO), als sie mit aufgeblähten, aufgebohrten (EM64T) X86 Kernen zu verschwenden.
Es können Wetten abgeschlossen werden. Wieviele Cores wir in ein paar Jahren wirklich haben werden, wissen wahrscheinlich nur wenige innerhalb von Intel und AMD und noch weniger außerhalb.
Ich persönlich glaube kaum, dass bei 8 Cores Schluß ist, eher bei 16 oder 32. Viel hängt hier davon ab, wieviele Cores ich auf herkömliche Weise mit Daten versorgen kann. Das dürfte meiner Meinung nach der Knackpunkt sein.
Was sicherlich sein wird ist das zukünftige Cores heterogen aufgebaut werden! Zur Zeit erleben wir in der Rechnerarchitektur eine Wiederbelebung der Koprozessoren. Die Geschichte lehrt uns, dass diese letztenendes auf dem Chip integriert werden. Die Frage ist nur welcher Koprozessor hinzukommt. Einen DSP für Multimedia, einen Physikprozessor für Spiele, rekonfigurierbare Logik, FPFA, ... . Das kann heute noch keiner genau sagen. Wahrscheinlich wird das integriert werden, was den meisten nutzen verspricht (also DSPs oder rekonfigurierbare Logiken).
Weiterhin ist der Trend in Richtung Virtualisierung erkennbar, allerdings noch nicht in welchem Rahmen. Sei es nun, um meherere Betriebssysteme auf einem Chip laufen lassen zu können oder aus Gründen der Redundanz oder sogar um die Ausführung von "fremden" Code, vorher übersetzt durch eine Zwischenschicht, zu ermöglichen, weiß heute noch keiner.

Coda
2007-02-14, 03:49:04
Kann man sich doch denken, oder?
Nein kann man nicht. Register-Pressure ist mit x86-64 lange nicht mehr so schlimm mit 16 GPRs, und x86 ist eine wunderbare Code-Kompression. Die großen Decoder sind bei den heute möglichen Logikdichten scheiß egal. Der relativ dazu virtuell gewonnene Instruction-Cache ist viel schöner. AMD hat übrigens simuliert mehr als 16 GRPs in x86-64 einzubauen und hat es aufgrund der Ergebnisse bleiben lassen.

x86-Hetzenjagd ist zwar immer "in", aber es ändert trotzdem nix dran, dass es eben ganz gut funktioniert. EPIC ist ein viel viel schlimmeres Monster.

Was allerdings mal interessant wäre, ist eine "moderne" x86-Variante (also RISC mit unterschiedlich breiten Befehlen).

StefanV
2007-02-14, 04:24:27
Ah, schade. Die Ingenieure haben sicher ihren Spass mit Polaris. Mal von Grund auf neu aufbauen können ohne an die x86-Diktatur gebunden zu sein. Die x86-Architektur gehört ja mit zu den hässlichsten Prozessorarchitekturen.
Ich würd eher vermuten das x86 damals, irgendwann, zwischendurch, als es noch nativ war, nicht das gelbe vom Ei war...
Heutzutage ists aber nur noch ein Befehlssatz, der sich im Nachhinein als garnicht mal so übel erwiesen hat...
Gut, in einigen Bereichen ist x86 immer noch nicht so gut, ansonsten kann man aber eben nicht mehr sagen das X86 Müll ist, eher das gegenteil ist der Fall...


Btw, zum Topic:
Was man mit diesem Design machen kann, ist z.B. da ein paar umfangreiche Decoder davor zu packen, die die ganzen Befehle umsortieren usw.

Ähnlich wie AMD es mit dem K5 gemacht hat, der ja nicht viel mehr als ein Umgebastelter AMD29k ist (und auch garnicht soo schlecht, würd mal behaupten das der K6 eher ein Rückschritt ist, technologisch gesehen)...

x86-Hetzenjagd ist zwar immer "in", aber es ändert trotzdem nix dran, dass es eben ganz gut funktioniert. EPIC ist ein viel viel schlimmeres Monster.
Ich halte EPIC für eine Schnappsidee...
Auf dem Papier ganz nett, in der Praxis voll fürn Po...

Gast
2007-02-14, 04:44:55
hi

zu x86: i love x86. Es hat sich bewährt, das ist der beste Beweis dafür dass es gut ist. Sogar Apple ist auf x86 umgestiegen, und das aus Performancegründen. x86 ist spitze!

zu den 80cores: Also der 80Core ist 300-1000 mal so schnell wie ein Core2. Könnte man da nicht eventuell eine x86 emulation oder sowas einbauen? Es würde ja schon reichen, wenn das was dann rauskommt 4 mal so schnell ist wie ein Core2.

mfg, GAST

Gast
2007-02-14, 04:53:26
Zum Erscheinungsdatum garantiert nicht mehr....

ilPatrino@work
2007-02-14, 14:00:07
hi

zu x86: i love x86. Es hat sich bewährt, das ist der beste Beweis dafür dass es gut ist. Sogar Apple ist auf x86 umgestiegen, und das aus Performancegründen. x86 ist spitze!

zu den 80cores: Also der 80Core ist 300-1000 mal so schnell wie ein Core2. Könnte man da nicht eventuell eine x86 emulation oder sowas einbauen? Es würde ja schon reichen, wenn das was dann rauskommt 4 mal so schnell ist wie ein Core2.

mfg, GAST

ohne angepaßte software wird der prototyp garantiert nicht in geschwindigkeitsbereichen aktueller systeme kommen.

Wuge
2007-02-14, 17:17:06
Der Polaris ist doch auf FP ausgelegt und daher auch bei FP viel schneller als die INT lastigen X86 CPUs. Also ohnehin nicht direkt vergleichbar oder?

=Floi=
2007-02-15, 03:48:02
interesannt finde ich, dass der chip nur um die 100mio transistoren hat und noch in 65nm gefertigt wird
das sollte man nämlich auch nicht vergessen!
das ganze noch gepaart mit 65watt verlustleistung in der kleinsten version

ich halte auch mehr wie 8 X86 cores für (problemlos)möglich
man wird sicherlich auch 4 cores an einen 8mb chache anbingen können
und das ganze baut intel wieder 2X auf einen chip
aicherlich nicht mit 65nm aber mit 45 aber spätestens 32nm ist soetwas realistisch

AnarchX
2007-04-17, 13:28:30
Hier gibt es noch ein paar Bilder zum Polaris-Setup von der aktuellen IDF:
http://img219.imageshack.us/img219/191/s06355326at4.jpg (http://imageshack.us)
http://img219.imageshack.us/img219/6317/s05544246fb0.jpg (http://imageshack.us)
Mehr Bilder... (http://66.249.91.104/translate_c?hl=de&ie=UTF-8&oe=UTF-8&langpair=zh%7Cen&u=http://news.mydrivers.com/1/81/81673.htm&prev=/language_tools)

Ganon
2007-04-17, 13:40:21
Jo, auch bei golem zu lesen:

http://www.golem.de/0704/51720.html


Intel hat den Prozessor nur entworfen, um das Verhalten von, wie sie der Hersteller nennt, "Many-Core-Prozessoren" zu erforschen. Dabei geht es um die Kommunikation der Kerne untereinander und Verfahren, wie diese mit Strom und Daten versorgt werden können. Wie Intels Enterprise-Chef Pat Gelsinger gegenüber Golem.de klarstellte: "Daraus wird niemals ein Produkt!

...

Da Polaris kein PC-Prozessor ist, entwickelt Intel unter dem Codenamen "Larrabee" derzeit auch einen rekonfigurierbaren x86-Mehrkerner.