Was kommt (nach den ersten Deneb (K10.5+)) fuer den Desktop bis zum Launch der BD(APUs)?

@Höherer Takt
Auch wenn es ein wenig Off Topic ist, will ich das Zitat doch noch mal verlinken: Andy von Bechtolsheim entwirft Szenario für Exaflops-Rechner

Es geht hier nicht um spezielle Architekturen, etwa X86 oder nicht X86.
Ein kurzer Text daraus:
"...An der Taktschraube kann man allerdings nicht viel drehen, da dabei der Energieverbrauch zu sehr ansteigen würde. Bechtolsheim erwartet einen moderaten Anstieg von jetzt im Schnitt 2,5 GHz auf 4 GHz...."

Also 4GHz wohlgemerkt in zehn Jahren. Daher erwarte ich nicht, dass unsere CPU-Hersteller bereits in der kommenden Generation ihre Designs auf Takte jenseits davon auslegen. Was einzelne Freaks mit oder ohne Stickstoff sich für Takte erbasteln, sagt nichts Nennenswertes über die Effizienz bei entsprechendem Takt aus.
MfG und gute Nacht.
 
Also ganz "trivial" ist die Problematik sicherlich auch nicht.
Ich behaupte das was der höheren Taktung im Wesentlichen im Weg steht ist der Stromverbrauch und das Problem der immer höheren Leckströme bei kleineren Strukturen.
Ich würde eher sagen dass es mehr die sinnvolle Befüllung der Pipeline ist. Siehe P4.
Alles andere sind mehr oder weniger Effekte daraus.
 
Die pipelinebefüllung seh ich eher bei der "mehrfachauslegung" als problem, also wenn man nun ein design als doppel-nehalem als 8 issue-design auslegt etc. der takt hat mit der pipeline-befüllung erstmal nix zu tun... der mechanismus arbeitet bei weniger takt nicht anders wie bei höherem, nur der speicher wird irgendwann zu langsam...
 
Die pipelinebefüllung seh ich eher bei der "mehrfachauslegung" als problem, also wenn man nun ein design als doppel-nehalem als 8 issue-design auslegt etc. der takt hat mit der pipeline-befüllung erstmal nix zu tun... der mechanismus arbeitet bei weniger takt nicht anders wie bei höherem, nur der speicher wird irgendwann zu langsam...
Die Pipelineauslastung steht indirekt schon in Zusammenhang mit der Taktfrequenz. Designt man eine längere Pipeline mit weniger Arbeit pro Takt, kann man das Design grundsätzlich erstmal höher takten. Dafür gibts dann die Auswirkungen wie höhere Befehlsausführungslatenzen (die die Auslastung beeinflussen), mehr Takte Leerlauf bei einem falsch vorhergesagtem Sprug und Einiges mehr.

Speicher sollte durch die umfangreichen Cache-Levels u. -Größen sich größtenteils bei großen Working Sets auswirken, aber nicht direkt bei Geschichten bzgl. Pipeline.

Ein 8 issue-design müsste erstmal auch deutlich niedriger getaktet werden, weil einige Prozesse, die noch in einem Takt stattfinden können, dank linearer oder quadratischer Aufwandssteigerung nicht mehr so möglich sind. Das Finden von genügend Befehlen, die da parallel in die Einheiten geschickt werden können, ist natürlich ein Problem für sich.
 
Ok Jungs, harte Zeiten fordern harte Maßnahmen.

Zwei Mann in die Küche, alles Besteck wegpacken. Gläser wegschließen, Porzellan nicht vergessen.

Ein weiterer kocht einen milden Bachblütentee.

Einer in die Apotheke. Mit dem Hinweis auf einen Notfall Beruhigungsmittel besorgen. Drei bis vier Kilo Tranquilizer dürften reichen.

Zwei Mann suchen den Standort der nächstgelegenen Ambulanz. Einer ruft bei der Hotline für suizidgefährdete an und fragt ob es Tipps gibt.

Und der Rest holt bitte rkinet herein und hält ihm fest während er liest das sein über alles und innig geliebtes Z-RAM in Gefahr ist.
 
Für die Diskussion hier ist sicher interessant, dass Z-RAM erstmal vom Tisch ist u. T-RAM favourisiert wird.
Hmm ist doch nicht neu, da gabs letztens (halbes Jahr?) doch einen Link, in dem gesagt wurde, das ZRAM leider nicht das hielt, was es versprach und man sich deswegen anderweitig umschauen würde ..

Naja hoffentlich klappts jetzt endlich mit T-RAM ;-)

ciao

Alex
 
freut mich, wie sich jeder um rkinet sorgen macht....
 
Das "Langweilige" an T-RAM ist jedoch, dass es sowohl in SOI als auch in Bulk geht. Z-RAM war doch gerade deshalb für AMD so sexy, weil es ein SOI-only Produkt gewesen wäre. Partially Depleted und auch unter Fully Depleted machbar in Inseln, die dann wieder nur Pratially Depleted sind. MfG
 
Das "Langweilige" an T-RAM ist jedoch, dass es sowohl in SOI als auch in Bulk geht. Z-RAM war doch gerade deshalb für AMD so sexy, weil es ein SOI-only Produkt gewesen wäre.
Unten ist das Problem zu sehen - Intel Mainstream Quad-Core mit GPU und 8 MB L3.
Nicht nur die 25 CLK für einen L3 sind ein ernster Wert. Auch die 8 statt 4 MB wie beim Liano sind besser und reichen sogar als Unterstützung zur GPU.

18a.jpg
 
Llano wird aber wahrscheinlich deutlich kleiner sein. Sandy bedient einen anderen Markt als Llano. Ich halte die integrierte GPU in dem Preissegment, in dem Sandy angeboten wird, sowieso für unsinnig.
 
Llano wird aber wahrscheinlich deutlich kleiner sein.
a) Sandy Bridge hat ca. 225 mm2

b) Ein 4M Cache K10.5 wäre etwa so groß wie ein Barcelona Shrink zzgl. GPU ... +80 bis +100mm2 = (Intel hat wohl ca. 60 mm2). Also ca. 120-150 zzgl. GPU also eher über 200 mm2. DIE-Fläche.


Sandy bedient einen anderen Markt als Llano. Ich halte die integrierte GPU in dem Preissegment, in dem Sandy angeboten wird, sowieso für unsinnig.
http://www.fudzilla.com/content/view/14524/35/

Das Segment ist in beiden Fällen ähnlich - Mainstream.
Das sind dann jene PC-Kisten die für $500 - $800 über die Theke wandern werden.

http://www.computerbase.de/news/hardware/prozessoren/intel/2009/juli/clarkdale_306_ghz_theoretisch/

Der Clarkdale kommt im Schwerpunkt $100 - $200. Das dürfte auch Zielwert bei Sandy Bridge und Liano werden.
 
Zuletzt bearbeitet:
Dafür ist die AMDsche GRafik selbst in der Variante für 0815-IGPs immernoch ein ganz anderes kaliber als das was Intel in die Chipsätze lötet.
D.h. Liano wird in Prozessordingen wohl Ärger mit Sandy kriegen, sobald aber die GPU zum Zuge kommt, kann Sandy einpacken.
Sorry, aber wenn ich überlege was Intel gemeinhin so als Grafikchip bezeichnet...sorry.
Bei Larrabee haben sie auch jüngst 2 HD-Decoder in HW dazugebracht, nur um zu verhindern dass man ein AKW braucht um einen Videofilm zu dekodieren. Die erste Larrabee-Generation wird also ihre liebe Not haben mit RV870 und GT300.

grüßchen
ich
 
rkinet schrieb:

Was mir gerade auffällt...bisher hatten wir doch bei IGPs stetige aber kleine Leistungssteigerungen. Intel will aber beim Shrink auf 22nm gemäß bisheriger Vorgehensweise Nur verkleinern, jedoch keine Änderungen der Schaltung selbst vornehmen.

Ist das mit integrierter Grafik erfolgversprechend? Bei AMD natürlich die gleiche Frage, aber da gibt es kein Tick-Tack das das von vornherein vorgibt.
 
a) Sandy Bridge hat ca. 225 mm2

b) Ein 4M Cache K10.5 wäre etwa so groß wie ein Barcelona Shrink zzgl. GPU ... +80 bis +100mm2 = (Intel hat wohl ca. 60 mm2). Also ca. 120-150 zzgl. GPU also eher über 200 mm2. DIE-Fläche.
Also ich weiss ja nicht, was du dir da einbildest ;). Propus ist schon recht klein, in 32nm wird er noch deutlich kleiner, trotz etwas mehr L3-Cache. Und die Größe des L3 beim Deneb wird die APU garantiert nicht erreichen, also sind 200mm² schon mal gänzlich unwahrscheinlich. Ich halte es für viel wahrscheinlicher, dass die APU eben nicht so riesig wird, sie wird immerhin von lower-Mainstream bis Low-End angeboten werden, also kein Markt, in dem sich eine starke APU lohnen würde. Die APU wird also eher ziemlich klein ausfallen, was ganz anderes als Intel beim Sandy vorsieht. Diese "IGP" sind kaum vergleichbar, da sie völlig andere Märkte ansprechen. AMD sieht in den Bereichen, in denen Sandy auf den Markt kommen wird, garkeine APU mehr vor bis zum echten Fusion. MMn schätzt du die Lage wirklich grandios falsch ein. Ein Llano wird nicht größer sein als der Propus jetzt, denn er soll schließlich auchnoch billig verkauft werden können. Ich gehe mal so von 150mm² aus, nicht mehr. Ein geschrinkter Propus hat vllt. 100mm², mit Cache 110-120, mit APU 150 - damit wäre die APU schon so gross wie beim Sandy nebenbeibemerkt.

Für mich ist jedoch klar, dass Llano auch deutlich langsamer sein wird als Sandy. Wie gesagt, die Märkte, die diese CPUs ansprechen, sind unterschiedlich. Bei AMD werden DualCores das sein, was SingleCores heute sind, während bei Intel dann immernoch DualCores mit SMT aktuell sind.
http://www.fudzilla.com/content/view/14524/35/

Das Segment ist in beiden Fällen ähnlich - Mainstream.
Das sind dann jene PC-Kisten die für $500 - $800 über die Theke wandern werden.

http://www.computerbase.de/news/hardware/prozessoren/intel/2009/juli/clarkdale_306_ghz_theoretisch/

Der Clarkdale kommt im Schwerpunkt $100 - $200. Das dürfte auch Zielwert bei Sandy Bridge und Liano werden.

Sandy Bridge ist Konkurrenz zum Mainstream-BD von AMD, nicht vom Llano. Llano ist ein reiner OEM-Prozessor, so wie Propus und Regor heute.
 
Zuletzt bearbeitet:
Dafür ist die AMDsche GRafik selbst in der Variante für 0815-IGPs immernoch ein ganz anderes kaliber als das was Intel in die Chipsätze lötet.
D.h. Liano wird in Prozessordingen wohl Ärger mit Sandy kriegen, sobald aber die GPU zum Zuge kommt, kann Sandy einpacken.
Und AMD muss per GPU punkten. Wobei ein Quad-Core bei Office wohl immer zügig genug sein wird und z.B. Office 2010 eher genügsam für Hardware wird - http://www.golem.de/0907/68619.html

Und der Nachfolger des AMD 780G dürfte GPU-Core für Liano werden. Und da sind 80-100 mm2 auch in 32nm schnell verbraten.
 
Was ich nicht ganz versteh warum die GPU bei Sandy am L3 hängt. Für grafische Anwendungen ist das doch total hinerlich. In die 8MB L3 findet doch keine Textur platz und die 4 CPU Kerne wollen ja auch noch ihren Platz im L3. Soll der dann immer zwischen Speichern zwischen GPU und RAM? Wäre da ein direkter Link an den RAM per PCIe als eigener Speicherchannel nicht besser gewesen?
 
Spekulation:
Ich nehme schwer an, dass die Verbindung der GPU mit dem L3 beim Sandybridge mehr für GPGPU (Bei Intel müsste man wohl eher von GPCPU sprechen....) Anwendungen geplant ist, wo man nicht 500 MB Texturspeicher ablegen muss. Das würde allerdings voraussetzen, dass hier tatsächlich ein Mini-Larabee verbaut ist. Allerdings ist der Larrabee nach wie vor lediglich ein Papiertiger und selbst wenn hier ein kleineres Larabee-Derivat verbaut sein sollte, muss man abwarten wie gut das dann dafür nutzbar ist. Es wird wohl daneben aber nach wie vor eine Anbindung der GPU an den Ram geben, sonst wäre das ganze relativ sinnfrei.
Prinzipiell ist es aber doch eine gute Sache gerade für GPGPU eine direkte Verbindung zwischen CPU und GPU zu schaffen, wenn beide schon auf einem Die sitzen, anstatt sie dann extern über den Ram kommunizieren zu lassen, was letztlich einen Großteil der Vorteile der "Nachbarschaft" wieder aufheben würde. Allerdings wäre dann ein größerer Cache trotzdem durchaus wünschenswert.
Man muss allerdings eben abwarten, was da dann tatsächlich für ein Grafikkern verbaut ist.

Extremspekulation:
AMD wird vielleicht auch auf 22nm mit den richtigen Fusion CPUs warten, weil man dann (vielleicht mit T-Ram?) große Mengen Speicher unterbringen kann ohne dass der Stromverbrauch explodiert.
 
Zuletzt bearbeitet:
Was ich nicht ganz versteh warum die GPU bei Sandy am L3 hängt. Für grafische Anwendungen ist das doch total hinerlich. In die 8MB L3 findet doch keine Textur platz und die 4 CPU Kerne wollen ja auch noch ihren Platz im L3.
Der wird ggf. je nach Betriebszustand unterschiedlich genutzt.

Bei IDLE wären die 8 MB L3 quasi frei und würden auch bei 1680*1050 als local frame buffer reichen. Schließlich soll das Design auch im Mobilbereich gut nutzbar sein.

Zudem es war an Performance bringen wenn die GPU großzügig per prefetch Daten über den L3 erhält statt dass ständig der Vorrang beim DRAM-Zugriff für die GPU ausgelöst wird. Trotz DDR3 und Dual-Channel sind 4*2 Cores und eine GPU recht hungrig auf Daten und Intel mußte schon in die Optimierungskiste greifen damit alles zügig abläuft.

Auch bei AMD wird man alles optimieren müssen um den Liano auf Performance zu bringen. Nur einfach irgendwie noch eine GPUs auf DIE bringen wäre zuwenig im Wettbewerb mit Intel.
 
naja 8MB für Grafik ist doch schon einige Jahre her oder?

es wäre sicherlich besser, ein Speicherkanal direkt zum RAM zu haben, ggf. Extraram vergleichbar mit Sideportramzeuch bei AMD
 
Ich bezweifle stark, dass der L3 als normaler Framebuffer benutzung finden wird, weil man dadurch den Prozessor kastrieren würde, ohne einen Nutzen daraus zu ziehen.
 
naja 8MB für Grafik ist doch schon einige Jahre her oder?
1680 * 1050 * 3 Byte = 5,3 MByte für den reinen Bildschirmspeicher.

Solange das System nur IDLE schiebt wäre der L3 wohl der stromsparenste Lieferant von Daten für die GPU.
Ansonsten eben alles ausgelagert ins DRAM und der L3 allenfalls als kleiner Puffer für die GPU.
 
32Bit Farben = 4 Byte !
1680*1050*4 Byte = 7056000 Bytes = 6,73 MB
jedoch kommen nunmehr realistischere Farben bis 48 Bit = 6 Byte daher :

1680*1050*6 Byte = 10,1MB --> L3 zu klein :P

Es ist auch fraglich, ob ein L3 Cache sparsarmer sein soll als ein spez. ultra-low-volt. Extraram so um die 64MB

Auch werden im L3 auch Daten der CPU-Kerne liegen, da die 256KByte L2 nicht "reichen" dürften
 
Zurück
Oben Unten