News Wird Intels Larrabee auch ein IGP?

[Tyr43l]

ich denke auch, dass der Schritt der richtige für INtel ist, da man so ein höheren Verbreitungsgrad erreicht mit der IGP.

Andernfalls könnte der Larrabee, aufgrund der speziellen Programmierung, einen schweren stand gegen nvidia und amd/ati und deren lösungfen bekommen.

 

[markox]

@Canyonero: LOL

GPU-Marktführern

Intel ist "GPU-Marktführer"! Und um "ein flopper" zu werden, müsste zumindest ein Larrabee IGP schlechter als ein aktueller Intel IGP werden (und das ist garnicht so einfach ).

 

[pezli]

So ein massiv-paralleles Array von Kleinstprozessoren stellt dann jedoch auch hohe Anforderungen an das Betriebssystem bzw. an sinnvolles und möglichst schnelles Scheduling.

Wobei jedoch das OS die Kerne nicht als solche erkennt und somit auch nichts scheduliert, das übernimmt dann höchstens der Treiber oder auch der Programmierer der Applikation die drauf läuft.

 

[Airbag]

Find den Satz hier ein bissl komisch. Vor allem wenn die Grafikeinheit mit dem Clarkdale ja vom Board verschwindet.

sondern wohl ebenso als Integrated Graphics Processor, kurz IGP, auf Mainboards sowie eventuell auch in Notebooks.

 

[yurij]

x86 architektur besteht in der aktuellen ausführung mit allen erweiterungen aus weit über 300 opcodes. das ist verdammt viel, viel mehr als jede andere architektur jemals hatte.
nicht umsonst sagte VM SEO: Intel's x86 is filled with "junk silicon"

Ich glaube es ist naiv zu glauben, dass ein many x86 core (Larrabee), die erwartungen auch nur annähernd erfüllen kann. Das x86 junk multipliziert mit 80 kernen ergibt milliarden von stromfressenden nichtsnützigen transistoren.

eine neue superskalare architektur muss auch neue wege gehen. und das tut sie mit computing sadern. intels versuch sein x86 garbage mit gewalt superscalar zu machen, kann leider nicht erfolgreich werden. ich denke larrabee wird ein sehr kurzes leben haben, wenn überhaupt.

um eine superscalare architektur und somit hochgradiges parallelism zu nutzen, müssen anwendungen oder deren teile sowie compiler komplett neu entwickelt und optimiert werden, das wird x86 architektur nur ausbremsen. aktuellen kernen stehen ~1mb cache zur verfügung, was beim manycore nicht mehr der fall sein kann. es wird mit der fähigkeit beworben, man könne x86 code einfach darauf ausführen lassen. gut, aber welche auswirkungen wird der um faktor 50 beschnittene cache haben? ohne eine vorherige grundlegende anwendungsoptimierung für derart kleine cache größen werden die threads im eigenen management overhead ersticken. ich habe mal irgendwo ein bericht über einflüss der cache größe gelesen, dort brach die anwendungsperformance um faktor 10 und mehr ein. man kann also nicht einfach cinema 4d z.b. nehmen und diese mit 80 trheads auf einem 80-manycore lauffen lassen, rendering wird wahrscheinlich langsamer gehen wie auf einem gewähnlichen 8 core prozessor.

 

[markox]

@davediehose: Deshalb ist Intel ja auch momentan Software Unternehmen die sich auf sowas spezialisiert haben.

Edit@davediehose: Ja, ich wollt den Satz erst anders schreiben und hab dann vergessen den Satzanfang auch zu ändern,... sollte eigendlich heißen:

Deshalb kauft Intel ja auch momentan Software Unternehmen die sich auf sowas spezialisiert haben.

 

[silent-efficiency]

@yurij
Na-ja, du kannst von x86 halten was du willst, die Shaderarchitektur ist auch nicht gerade was neues, der Typ hier in seiner Präsentation hällt die GPUs aktuell für viel zu unflexibel. Da ist Larabee mit wenigen Fixed-Funktion-Uninits einen Schritt weiter. Und Larabee ist nicht einfach "viele X86-Cores", sondern viele X86 Cores mit 16-wide SIMD-Einheiten. Die SIMD-Einheiten brigen die FLOPS und sind auch mit den "Streamverabeitungseinheiten" aka "Streamprozessoren" aus den GPUs vergleichbar.

aktuellen kernen stehen ~1mb cache zur verfügung, was beim manycore nicht mehr der fall sein kann. es wird mit der fähigkeit beworben, man könne x86 code einfach darauf ausführen lassen. gut, aber welche auswirkungen wird der um faktor 50 beschnittene cache haben?

Faktor 50 beschnittene Cache? Larrabee hat pro Kern 256kb L2-Cache. Propus, die neue AMD 4-Kern-CPU soll 512kb L2-Cache pro Kern haben. Also lediglich um Faktor 2 größer.

Aber mal von deiner falschen Argumentation abgesehen, muss natürlich für Larrabee die Software angepasst werden um eine gewisse Effizienz zu erreichen, nur eben nicht so stark, wie das bei GPUs der Fall ist, wo ohne Anpassung gar nichts läuft.

 

[Lübke]

@yurij:

x86 architektur besteht in der aktuellen ausführung mit allen erweiterungen aus weit über 300 opcodes. das ist verdammt viel, viel mehr als jede andere architektur jemals hatte.
nicht umsonst sagte VM SEO: Intel's x86 is filled with "junk silicon"

dir ist aber schon klar, dass die x86-kerne des larrabee keine i7-kerne sind, ja?
das sind p1-basierte, überarbeitete und geshrinkte kerne. die sind noch weit weg von den heutigen "zugemüllten" kernen...

 

[zogger CkY]

die damaliegen P1 kerne kannten noch kein SSE und den ganzen kram. Die hatten nicht mala einen ondie L2 chache. Selbst MMX kam erst mit einem refresh um genau zu sein mit dem Pentium MMX. Also technisch gesehen sind die kerne uralt. Anno 1992\1993 waren die p1 die absoluten topmodelle.

 

[Marius]

hm,.........6 Cores und 4 davon IGP?
Mit 32nm nächstes Jahr kein Problem.
Mit 22nm noch viel weniger Problem.

4 IGP auf Leistungshöhe des Clarkdale sind auch schon mind. eine 9800GT

Und das auf microATX!
Bei den Spielkonsolen gehts ja auch(Sony).

 

[Lübke]

wenn man den alten p1 von 800nm bzw 600nm auf 45nm shrinkt, dann sollte schon der eine oder andere kern mehr dransitzen

 

[zogger CkY]

und vorallem die senkung der Vcore, die brauchten damals noch je nach modell bis zu 3,3V aber selbst damals hatten die nie mehr als 16W verbraten.

 

[Lübke]

kunststück bei grade mal 3,1 mio transistoren

 

[davediehose]

Die geringere VCore ist ohnehin das Totschlägerargument für Mehrkernsysteme, spätestens seit Ende der Netburst-Zeiten. Was das betrifft wird Larrabee große Vorteile bieten.

Möglicherweise erlebt auch der Pentium1-Bug ein Revival im Larrabee Ich fänds zumindest nen Brüller.


@yurij:

Zur Begrifflichkeit: Um Superskalarität geht es hier nicht, da scheinst du zwei Begriffe zu verwechseln. Damit bezeichnet man eigentlich die interne Ausführung innerhalb eines Kerns, also die Zuteilung und Abarbeitung der Befehle in dessen Ausführungseinheiten. Damit wären wir also genaugenommen eine Stufe zu tief bzw. zu nah am einzelnen Kern. Hier gehts aber ja um die Organisation mehrer Kerne, speziell im Manycore, und ich denke das meinst du auch, da du ja dann von Cachegrößen und Overhead spricht, was dann zum Thema Multiprozessor-Scheduling gehört.

Deine Sorgen sind denke ich berechtigt, aber ich kann mich den folgenden Kommentaren nur anschließen und sagen, dass die Kerne mit Sicherheit relativ schlank sein und auch in eine vernünftige, angepasste Architektur eingebettet werden.

Und dass die derzeitige Software nicht für Multi-/Manycore-Systeme ausgelegt ist, dürfen wir uns seit den ersten Dualcores anhören. Dann wächst eben langsam aber sicher der Druck auf alle Softwareentwickler, ihren Code so nebenläufig wie nur möglich zu schreiben.

Möglicherweise bekommt Intel es auch hin, die vielen Kerne untereinander zusammenschaltbar zu gestalten, sodass dann zwischenzeitlich eine temporäre "super-superskalare" (und hier passt der Begriff) Einzel-CPU entsteht, die annähernd doppelt so schnell agiert wie zwei einzelne. Ganz abwegig ist auch das nicht.

@davediehose: Deshalb ist Intel ja auch momentan Software Unternehmen die sich auf sowas spezialisiert haben.

Versteh ich nicht

 

[batzen21]

ich denke auch das es wohl am anfang maximal fürs mittelfeld reichen wird^^
jedoch intel hat geld, vieeel geld,,,,

 

[yurij]

ok, pentium I dürfte schon mal schlanker sein, auch wenn pentium I spec immer noch bei etwas über 150 opcodes liegt. 256kb cache pro kern ist auch erfreulich. 20 mb cache für eine Die ist dann ganz schön heftig.

i7 4 kerne ~730 mio transistoren
p1 1 kern ~3mio transistoren
80x p1 = 240mio
20mb cache = 160mio

macht 400 mio transistoren [plus] paar millionen für das ganze drumherum [minus] paar mille von der optimierung.

edit: cache transistorzahl korrigiert

 

[Floletni]

Woher hast du die 80? Es gab mal einen DIE-Shot wo 32 Kerne zu sehen waren. Ich denke mal das sie bei High-End -Modellen dann zwei zusammen packen werden.

p1 optimiert = 4/5 mio
32x p1 = 128/160 mio

Die 20 moi fürn die Cache würde ich übernehmen. Keine Ahnung wieviel der frisst.

Für den ganzen Rest würde ich sogar 100mio veranschlagen. Sind ja 2 HD-Decoder und sonst noc fürn Schickie-Mickie drinne.

 

[pezli]

Ja, aber die Vektoreinheiten nicht vergessen mit über 100 Befehlen, da kommt schon noch genug Fläche dazu

 

[markox]

@davediehose: siehe Edit oben

@pezli: Genau so isses, is ja nicht so, dass sie die ollen P1 geschrinkt und mit 256kb versehen hätten, ein bisschen mehr hat sich ja schon geändert/ist dazugekommen. Und durch den Ringbus Aufbau kommt bestimmt auch noch was dazu.

@yurij: Ich meine Cache hat immer sehr viele Transistoren, das wird mit 20 mio bestimmt nicht hinkommen

@Floletni: von 80 Kernen war sehr lange die Rede und ein 80 Core Chip im Wafer wurde ja glaub ich ende 2007 (oder wars Ende 2008?) auf nem IDF hochgehalten. Aber wenns keine 80 sind, dann schon eher 64 als 32, wenn mal irgendwo nen 32 Core Chip zu sehen war, dann wahrscheinlich, weil in 45nm mit nur 32 Cores besser geforscht werden kann. Und zwei 32 Core Dies zum Highend Chip zusammen setzen wird sicher nicht kommen, das ist ja gerade der große Vorteil dieser Architektur, man kann für jede beliebige Geräteklasse beliebig Einheiten und Cores weglassen oder zu packen ohne großen Aufwand.

 

[Floletni]

Das war schon ein Lrb Wafer in 32 nm. Der 80 Kern Wafer war Polaris. Das war nur ein Versuchsprojekt um zu sehen was machbar ist.

Kann mich auch noch erinnern das zwischen den Kernen noch extra irgendwelche Einheiten waren. Die müsste man noch dazu zählen.