Intel Nehalem

... Wieviel-fach Skalar ist wohl Nehalem?
Ich kann mir vorstellen, dass man speziell dort noch etwas draufgesattelt hat. Die Architektur wird stark verbreitert, die Single-Thread-Performance hingegen bleibt gleich oder sinkt sogar etwas. ...
Ich kann mir gut vorstellen, dass der Nehalem im Grunde genommmen ein Penryn-Kern ist.


Die versprochenen Nehalem Leistungssteigerungen (Einzelthread: Faktor 1,1 (+10 Prozent) bis 1,25 (+25 Prozent), SMT-Leistungssteigerung Faktor 1,2 bis Faktor 2)) sind da meiner Meinung nach ein Indiz für die These, dass es im Grundsatz ein technisches Update zur Penryn-Microarchitektur ist.

Allerdings ist dieser dann in SMT-Technik (was schon deswegen einen neuen Namen gerechtfertigt) und
dann kommt statt Intels GTL-Bus nun Quick Path und/oder PCI-Express mit dem DMI-Grafiklink hinzu ... was für sich alleine ebenso einen neuen Namen gerechtfertigt).
Na ja, und dann kommen noch die SSE-Spielereien hinzu, die ein technisches Update für Kryptologie* sind.

Und wie bei den Core 2-Quad- (Harpertown, Clovertown) und Hexacore (Dunnington) wird Intel seine Multicores, wenn es wirtschaftlich vernünftig ist, mit mehreren Dice pro Chipträger auf den Markt bringen.

@Opteron
Mir war es neu, dass der Dunnington ein sechsfacher Multicore sein wird. ;)

MFG Bobo(2008 )


* = falsch von mir, der Einwand von Opteron ist richtig ;) !
intel_nehalem-sse4.2_westmere-aes-ni.jpg

Quelle
 
Zuletzt bearbeitet:
Hexa-Core geht eben noch thermisch in 45nm.

Gilt ebenso für AMD.
Bei AMD den Shanghai auf 6 Cores aufboren,
dafür den 6M-L3 auf eDRAM umstellen und auf ca. 12-16M aufgebohrt.
Hängt nur am eDRAM, denn sonst ist der Hexa-Core zu großflächig.
Allerdings steht in der AMD (immer noch) ein Oktacore, dessen TDP den Rahmen sprengen wird. Aber deshalb hat die geniale AMD-Führung ja die TDP abgeschafft ...

Trotzdem überrascht der Dunnington, schließlich klingt der Nehalem auf performant.
Allerdings ist der Dunnington wohl einfach Socketpflege mit viel Standarttechnik für Intel.
 
@Opteron
Mir war es neu, dass der Dunnington ein sechsfacher Multicore sein wird. ;)
Echt ? Sorry, dachte ich hätte Dir das damals geschickt, hab mal nochmal gegoogelt, hier wars, Oktober 07:

kaigai394_01l.gif


Artikel-Link (mit weiteren Infos):
http://pc.watch.impress.co.jp/docs/2007/1018/kaigai394.htm

Was ich zufällig gerade noch gefunden habe, Beckton wird *kein* MCM:
[Update 3:00PM - I got a clarification that the first version of Nehalem will be 4 cores in 2008, the second version of Nehalem will be 8 cores on a single monolithic die in 2009.]
http://blogs.zdnet.com/Ou/?p=758
Aber bei Hiroshige steht ja auch schon "native" 8core ;)

@mocad_tom:
Ich denke an der Skalarität wird sich nicht viel ändern, die Funktionsblöcke kommen mit 4fach nicht wirklich klar, irgendwo stand mal, dass das nur zu 20% genützt wird, wenn man noch "µOPT-Fusion" dazuzählt, dann könnte man fast von 5fach Superskalar sprechen. Der logische Schritt wäre also die Funktionseinheiten weiter aufzubohren, um den ganzen decodierten Befehlsschwall besser abarbeiten zu können. Aber da ist die Frage, ob Nehalem jetzt Penryn II ist, oder was total Neues. Nachdem Intel eher konservativ ist, sich mit der letzten "neuen" Architektur (Netburst) die Finger verbrannt hat, könnte Bobo schon recht haben -> ergo eher keine Änderung der Superskalarität.

Apropos Bobo: die Krypto Befehle kommen noch nicht mit Nehalem, der bekommt erst mal XML SSE 4.2 oder wie das hieß. Krypto ist erst für später angedacht, sagte einer der Intel Leute am Themenabend (Ich hatte da ja meinen "SSE" thread"^^).

Ansonsten zu AMD .. naja also ich seh da jetzt nur noch "Chancen" wenn Bulldozer hält was der Name verspricht ... angeblich kommt der ja 2009 ... Nehalem Ende 2008, also soviel zeitlicher Unterschied ist da nicht. Aber wer die Zuverlässigkeit der letzten AMD Pläne kennt, der rechnet mit einem Bulldozer wohl frühestens 2011 :(


ciao

Alex
 
Zuletzt bearbeitet:
Ansonsten zu AMD .. naja also ich seh da jetzt nur noch "Chancen" wenn Bulldozer hält was der Name verspricht ... angeblich kommt der ja 2009 ... Nehalem Ende 2008, also soviel zeitlicher Unterschied ist da nicht. Aber wer die Zuverlässigkeit der letzten AMD Pläne kennt, der rechnet mit einem Bulldozer wohl frühestens 2011
Der 'Bulldozer' ist doch schon aus der AMD-Roadmap verschwunden.

Im übrigen ist der 'Dunnington' doch für Intel ein überschaubares Produkt.
AMD könnte locker auch einen Hexacore bauen, da gib es in 45nm keine technischen Probleme. Es klemmt nur am L3-Cache in SRAM, der einfach zuviel Platz für brauchbare Stückzaheln und Yieldrates benötigt.
 
Montreal ist angeblich (hoffentlich sind die Gerüchte falsch) ein MCM aus 2 Shanghais, von daher nix besonderes. Die Speicherbandbreite wird suboptimal verteilt, und der Takt wird auch nicht übermäßig groß sein, da die 2 Dies unter einem Deckel gut heizen werden. Also Wunder würde ich da keine erwarten. Abgesehen legt Nehalem auch durch sein Hyperthreading im Serverbereich um Einiges zu, das darf man auch nicht vergessen ...

ciao

Alex

Hyper Threading hat aber nicht nur Vorteile, das sah man schon beim Pentium 4. Und daher nicht verstehe das Intel wieder "HT" einsetzen will. Es sei den man hat die Nachteile die sich dadurch ergeben, beseitigt.

Im Allgemeinen könnte Intel ähnliche Probleme bekommen, wie AMD damals wo sie dem FSB dem Rücken kehrten. So könnte AMD noch eine kleine Chance haben, wenn bei Intel dahingehend was schief läuft.
 
Der 'Bulldozer' ist doch schon aus der AMD-Roadmap verschwunden.
Ach stimmt ja, der ist ja aus der letzten Roadmap raus, genauso wie Bobcat ... meine rosarote AMD Brille verdrängt das wohl immer gerne ^^

Hoffen wir also auf 2010, falls es AMD dann noch gibt *suspect*

Irgendwie erinnert die AMD Situation an Cyrix nach der VIA Übernahme. VIA hat den Cyrix Laden dicht gemacht, Zitat von nem VIA Chef:" Zuviele Häuptlinge(Manager), zu wenig Indianer(Entwickler)" ... Centaur haben sie dagegen behalten .. und die liefern jetzt sogar einen neuen Core ab, zwar auch mit Verspätung, aber das sind da auch nicht wirklich viele Entwickler.

Mal schauen ob der Nickname CentaurHauls noch frei ist *lol*

Danke für den Hinweis.

@Zidane:
Wer HT nicht haben will, kanns im BIOS abschalten, war beim P4 doch auch schon so ... im Großen und Ganzen hat man aber sowieso nur Vorteile.

An Probleme glaube ich auch nicht, was Intel an Entwickler Resourcen haben ... puhh ... QPI ist, wenn ich mich recht erinnere, sowieso von den ehem. Alpha / DEC Entwicklern entworfen worden. Wenn sich wer in dem Milleu auskennt, dann die ...

ciao

Alex
 
Zuletzt bearbeitet:
Hyper Threading hat aber nicht nur Vorteile, das sah man schon beim Pentium 4. ...
Sagens wir mal anders ...

Warum nutzt AMD als einer der wenigen ganz grossen CPU-Schmieden IMMER noch keine SMT-Technik?

Nur weil der Pentium 4 teilweise Leistungseinbrüche damit hatte (die bei einem 3DCenter-Bericht zu Vista-Zeiten kaum noch relevant waren), bedeutet das noch lange nicht, dass jegliche Implementation von SMT-Technik sinnlos ist.

IBM, Sun, Fujitsu, MIPS zeigen genau das Gegenteil davon. Und da ist man nicht nur mit zweifachem SMT und einigen Quad- und Octacores dabei, sondern man nutzt mitunter achtfaches SMT, oder entwickelt darauf basierend völlig neuartige Technologien (Suns Rock mit Transaction-Speichertechnik).
Da AMD auch im Server-Bereich punkten will, ist AMDs beharrliche Verweigerungshaltung um so mehr verwunderlich.

MFG Bobo(2008 )
 
Zuletzt bearbeitet:
Sagens wir mal anders ...

Warum nutzt AMD als einer der wenigen ganz grossen CPU-Schmieden IMMER noch keine SMT-Technik ein?

Nur weil der Pentium 4 teilweise Leistungseinbrüche damit hatte (die bei einem 3DCenter-Bericht zu Vista-Zeiten kaum noch relevant waren), bedeutet das noch lange nicht, dass jegliche Implementation von SMT-Technik sinnlos ist.

IBM, Sun, Fujitsu, MIPS zeigen genau das Gegenteil davon. Und da ist man nicht nur mit zweifachem SMT dabei, sondern man ist mitunter bei achtfachem SMT dabei.
Da AMD auch im Server-Bereich punkten will ist AMDs beharrliche Verweigerungshaltung um so verwunderlich.

MFG Bobo(2008 )

Gut einen pasenden Link habe ich nicht, wenn ja stammte der aus einem wesentlich älteren Artikel, vielmehr hängt das Problem damit zusammen, das HT im ungünstigsten Fall andere Prozesse blockiert.

Und wozu HT einführen, wenn man auch physikalische statt logische Cores nutzen kann. Gut bei dem eh schon lahmen Pentium 4, war HT durchaus angebracht. Er war zwar schneller als ein Sockel A oder A64er Single-Core wenn es um Multi-Tasking ging, brach aber bei Games total ein, da half auch das HT nicht. Da waren die AMDs einfach schneller. Gut das Problem hat man ja mit der Core Technik nicht.

Gut aber im Fall des Pentium 4, stand eben nur 1 pyhsikalischer Core und ein logischer zur Verfügung. Mag sein, das bei 2 oder 4 oder 8 Kern CPUs mit HT die mögliche Bremse durch die anderen Cores wieder ausgeglichen wird.

Des letzteren können 8 oder mehr Cores auch ein System ausbremsen, bzw. kaum von nutzen sein, wenn die Verbindung es nicht hergeben kann (FSB) oder die Programme überwiegend nicht die Cores nutzen können.
 
Zuletzt bearbeitet:
... vielmehr hängt das Problem damit zusammen, das HT im ungünstigsten Fall andere Prozesse blockiert.
Intels HyperThreading war von der Umsetzung eines SMT-Prozessors strunzdumm in einem ohnehin fragwürdigen Prozessordesign.

Und wozu HT einführen, wenn man auch physikalische statt logische Cores nutzen kann. ...
Weil SMT-Technik vergleichsweise wenig Platz beansprucht, gegenüber einem weiteren CPU-Kern.

IBM, Fujitsu, MIPS haben ihre SMT-Umsetzung so gestrickt, dass in Programmumgebungen auch SMT zur Laufzeit von Fall zu Fall auch aus und eingeschaltet werden kann, wenn der SMT-Betrieb zu Leistungseinbrüchen führt.

8 oder mehr Cores auch ein System ausbremsen, bzw. kaum von nutzen sein, wenn die Verbindung es nicht hergeben kann (FSB) oder die Programme überwiegend nicht die Cores nutzen können.
Das ist kein Argument gegen SMT, bzw. es ist kein Argument, wenn ein Hersteller ohnehin auf Multicore-Technik und potenzielle Engepässe im Vorfeld wie FSB, Speicherbus, I/O-Links deutlich erweitert.

MFG Bobo(2008 )
 
@Zidane:
Sagens wir mal anders ...

Warum nutzt AMD als einer der wenigen ganz grossen CPU-Schmieden IMMER noch keine SMT-Technik?
Siehe oben ... anscheinend zuwenig Indianer :(
Das ist kein Argument gegen SMT, bzw. es ist kein Argument, wenn ein Hersteller ohnehin auf Multicore-Technik und potenzielle Engepässe im Vorfeld wie FSB, Speicherbus, I/O-Links deutlich erweitert.
Jo oder anders gesagt, was wird denn in ner CPU eingebaut ? Alles was der Leitung dient und nicht viel (Die) Fläche kostet. Da ist HT bzw. SMT eben topp, also rein damit in die CPU, v.a. wenn die externen Datenautobahnen drastisch verbreiter wurden und dort keine Engpässe zu erwarten sind.

Klar, 8 echte Kerne sind besser als 8 logische, aber 16 logische sind sehr oft eben noch besser ...

ciao

Alex
 
Zumindest Bulldozer werden wir vor 32nm sicherlich nicht sehen. Und Gerüchten zufolge soll Bulldozer SMT ja enthalten.

Nahelem wird an den gleichen Dingen kranken wie der K10 im Desktop Bereich. Die (S)MT Fähigkeiten werden kaum genutzt, die ISA Improvements ebenfalls nicht...
 
Zuletzt bearbeitet:
Klar, 8 echte Kerne sind besser als 8 logische, aber 16 logische sind sehr oft eben noch besser ...
Es ist auch immer eine Frage der TDP.

8 echte Core sind auch bei 45nm Fertigung kräftige Heizkissen.
4 echte Cores zzgl. SMT treiben die TDP vielleicht um 15-30% nach oben, nicht aber um min. 80% (bei gleichem Takt) wie der Übergang 4-fach auf 8-fach erwarten lässt.

Der Hexa-Core http://www.computerbase.de/news/har...2008/februar/intel_dunnington_hexa-core_2008/ hat noch den 'alten' Penryn-Core ohne SMT / HT und wird daher 35-45% über einem aktuellen unechten Quad bzgl. TDP liegen.
Die bisher bekannten TDP-Werte des Penryn lassen dies aber unkritisch erscheinen und 130 Watt max. sind für 6 echte Cores bzgl TDP/ Performance ein interessanter Wert.

Der Nehalem könnte 4-fach physikalisch / 8-fach HT etwa die Performance des Hexa-Core erreichen, aber bei reduzierter TDP.
Interessant, dass Intel beide Optionen gleichzeitig umsetzt, was wohl auf Stärken/Schwächen je Anwendungsbereich schließen läßt.
 
Ich kann mir gut vorstellen, dass der Nehalem im Grunde genommmen ein Penryn-Kern ist.


Die versprochenen Nehalem Leistungssteigerungen (Einzelthread: Faktor 1,1 (+10 Prozent) bis 1,25 (+25 Prozent), SMT-Leistungssteigerung Faktor 1,2 bis Faktor 2)) sind da meiner Meinung nach ein Indiz für die These, dass es im Grundsatz ein technisches Update zur Penryn-Microarchitektur ist.

Allerdings ist dieser dann in SMT-Technik (was schon deswegen einen neuen Namen gerechtfertigt) ...

http://pc.watch.impress.co.jp/docs/2007/1026/kaigai397.htm
kaigai397_08l.gif

(ich hoffe mal Hiroshige Goto killt uns nicht für das direkte Verlinken seiner Grafiken)

bei Yonah hat ein Kern ca.12,3Mio Transistoren,
bei Penryn hat ein Kern ca. 19Mio Transistoren
die Die-Fläche eines Nehalem-Kerns ist ca. 1,4 bis 1,5 mal so groß wie die Fläche eines Penryn-Kerns (also ca. 28Mio.).
Wenn man die Kerne betrachtet, kann man eine (optische) Verwandschaft zwischen Yonah und Penryn feststellen (man findet die Funktionsblöcke in Regionen wieder, die man erwartet, vllt etwas verschoben, aber nicht viel). Bei Nehalem tue ich mir schon sehr schwer überhaupt irgendetwas zu zuordnen.

MMn ist der "Kern-Sprung" Yonah -> Conroe nicht so groß wie der Sprung Penryn -> Nehalem .
(Ist man ein AMD-Supporter wird man auf ein Debakel wie beim Sprung Northwood -> Prescott hoffen, dort blieb auch (aus Kernsicht) kein Stein auf dem anderen)

@ "Einzelthread: Faktor 1,1 (+10 Prozent) bis 1,25 (+25 Prozent)"
Wenn man die Skalarität aufbohrt kann man diese Steigerung in sehr speziellen Fällen erreichen, wenn der Compiler schon die richtigen "Häppchen" für den Decoder zurechtrichtet, allerdings dann halt auch nur in diesen Fällen.

@ "SMT-Leistungssteigerung Faktor 1,2 bis Faktor 2"
In allen anderen Fällen zieht dann der SMT-Aspekt - Einheiten liegen brach und müssen durch einen zweiten Thread befeuert werden.

Ich stehe zu meiner Meinung - die Single-Thread-Performance wird im Schnitt gleich bleiben oder evtl. sogar etwas sinken, bei gleichem Takt.

Grüße,
Tom
 
Zuletzt bearbeitet:
SMT frisst ne Menge Transistoren, da ja viele Einheiten dafür doppelt ausgelegt werden müssen. Von daher kann das trotzdem hinkommen. Das dürfte auch der Hauptgrund sein, warum AMD das bisher nicht gebrauchen kann. Es macht die CPUs einfach zu gross.
Interessant ist, dass ein Nahelem 45nm Die nahezu so gross ist wie ein 65nm K10 (270 zu 284mm²).
Der 45nm K10 dürfte einiges kleiner sein, zumal man die Cache-Packdichte bei 45 und 32nm wohl enorm verbessert hat bei AMD/IBM. Kein Wunder also, dass AMD nun plötzlich auf grosse Caches setzt (8MB bei Shanghai, 10MB bei 4-Kern-Montreal, 20MB bei 8-Kern-Montreal).
Der Nahelem wird nicht auf Desktop eine gefährliche CPU, sondern im Serverbereich. Mit SMT und der Plattform ist Intel so gut aufgestellt wie schon seit Jahren nicht mehr. Stellt sich jetzt nurnoch die Frage nach der Energieeffizienz. AMD dürfte ca. 1 1/2 Jahre Rückstand im Serverbereich haben ggü. Nahelem bis Bulldozer das Ruder wieder herumreißen kann.
 
Zuletzt bearbeitet:
Der 45nm K10 dürfte einiges kleiner sein, zumal man die Cache-Packdichte bei 45 und 32nm wohl enorm verbessert hat bei AMD/IBM. Kein Wunder also, dass AMD nun plötzlich auf grosse Caches setzt (8MB bei Shanghai, 10MB bei 4-Kern-Montreal, 20MB bei 8-Kern-Montreal).

Der Nahelem wird nicht auf Desktop eine gefährliche CPU, sondern im Serverbereich. Mit SMT und der Plattform ist Intel so gut aufgestellt wie schon seit Jahren nicht mehr. Stellt sich jetzt nurnoch die Frage nach der Energieeffizienz.
http://www.computerbase.de/news/hardware/prozessoren/intel/2008/februar/intel_nehalem_performance/

Der Nehalem zieht ziemlich durch wie ersten Benchmarks zeigen.
Abert auch der Shanghai läßt den Barcelona stahen.

Bzgl. 8-Kern Montreal sehe ich die TDP das Projekt ersticken.
Der Ansatz 4-fach Core mit SMT / HT oder 6-fach Core ist einfach realistischer für 45nm.
Die Werte des 8-fach Montral sind also eher für 32nm geeignet, was aber noch lange dauern wird.
 
Intel bringt den Beckton gegen den Montreal-8-Kerner. Ich denke, da wird Montreal von der Energieeffizienz sogar einiges besser darstehen. Der Dunnington ist doch eher ein "Lückenfüller" bis Beckton kommt. Der Dunnington hat kein SMT und basiert auf der Penryn Generation. Ich denke, da sollte man besser nichts durcheinanderwerfen...
Der K10 Kern hat viel weniger Transistoren pro Kern als der Nahelem. Das macht sich natürlich auch bei der Energieeffizienz bemerkbar. Der jetzige 65nm K10 ist da kein Masstab.
Btw: Ich denke nicht, dass Montreal viel mehr als 320mm² auf die Waage bringt. Viel schlimmer als der jetzige Quad wird der Octa-Montreal nicht. Ich schätze die 45nm Shanghai Kerne auf eine Grösse von ca. 160/170mm² hat, vielleicht sogar weniger. Montreal bringt mehr Cache Effizienz, da ist noch einiges drin.

Ich finde auch nicht, dass Nahelem besonders Energieeffizient aussieht. Genauswenig wie die Plattform. Eine 270mm² CPU, die einen verhältnismässig geringen Cache Anteil hat (ggü den Vorgängern) ist ziemlich sicher ein Stromfresser, logischerweise. Man sollte bedenken, wer das Teil entwickelt hat (innerhalb Intel). Ich lasse mich da gerne eines besseren beleheren, aber bisher sieht das Teil weder nach einem Takt- noch nach einem Energiesparmonster aus. Hier könnte der 45nm K10 richtig in die Bresche springen. Klein, billig in der Produktion, energieeffizient.
Ich glaube auch nicht, dass der K10 die 45nm überleben wird. Man wird den Sprung auf 32nm gleich mit Bulldozer nutzen wollen, denke ich, um eine Menge Geld zu sparen. Man bräuchte dann ja kein 45nm Bulldozer oder 32nm K10 Design.
 
Zuletzt bearbeitet:
Im ExtremeSystems-Forum wird noch etwas interessantes angegeben:
http://www.xtremesystems.org/forums/showthread.php?p=2789367#post2789367

Das Nehalem Engineering Sample läuft mit 1Ghz und SuperPi 1M braucht ca. 180s.
Zum Vergleich, ein Pentium 3 mit 512kByte L2 @ 1GHz benötigt ca. 160s.
Wäre mal interessant Banias (1MB L2) und Dothan (2MB L2) Werte @1GHz im Vergleich dazu zu haben.
Ich könnte mich täuschen, aber evtl. kann man hier schon die L2-Cache-Grösse wirklich mit 256kByte fest angeben.

Wer weiß einen, der kennt einen, der weiß einen, der kann das messen :] ?

Grüße,
Tom
 
Danke, prima Vergleichsbilder! :)
... die Die-Fläche eines Nehalem-Kerns ist ca. 1,4 bis 1,5 mal so groß wie die Fläche eines Penryn-Kerns (also ca. 28Mio.).
Wenn man die Kerne betrachtet, kann man eine (optische) Verwandschaft zwischen Yonah und Penryn feststellen (man findet die Funktionsblöcke in Regionen wieder, die man erwartet, vllt etwas verschoben, aber nicht viel). Bei Nehalem tue ich mir schon sehr schwer überhaupt irgendetwas zu zuordnen. ...
Gute Argumente gegen meine These. Von daher werden wir derzeit andere Meinungen vertreten. ;)

Schon bei Pentium 4 hat Intel vom Williamette bis hin zum Prescott jeweils mehr als nur ein Shrink und schlichtes Redesign hingelegt. Optische Ähnlichkeit kann ein Indiz sein, muss es aber nicht.

Bleibt der Flächenzuwachs. Das ist schon recht bedeutsam, dass hier der Nehalem-Kern um den Faktor 1,4 - 1,5 grösser erscheint. Das kann ich mir derzeit auch nicht erklären*, zumal die Fertigungtechnik bei beiden ja 45 nm sind.
* = Allenfalls dadurch, dass Intel mit noch mehr EDA-Tools und Standard-Modulen arbeitet, die eine höhere Designflexibilität bieten, dafür aber etwas mehr Chipfläche fressen. Das ist auch zum Silverthorne-Design so kolportiert worden ( hat bei IBM übrigens auch die Power6/z6-Die-Fläche unter anderem wieder aufgeblasen ).

Intel bringt den Beckton gegen den Montreal-8-Kerner.
...
Der K10 Kern hat viel weniger Transistoren pro Kern als der Nahelem. Das macht sich natürlich auch bei der Energieeffizienz bemerkbar. ...
Btw: Ich denke nicht, dass Montreal viel mehr als 320mm² auf die Waage bringt. ...
Ich schätze die 45nm Shanghai Kerne auf eine Grösse von ca. 160/170mm² hat, vielleicht sogar weniger.
Halten wir das mal einfach so fest, das wird man sehen müssen.

... Ich finde auch nicht, dass Nahelem besonders Energieeffizient aussieht. Genauswenig wie die Plattform. Eine 270mm² CPU, die einen verhältnismässig geringen Cache Anteil hat (ggü den Vorgängern) ist ziemlich sicher ein Stromfresser, ...
Nun ja, Intel hat sich selbst mit einer TDP von 130 Watt selber festgetackert.
Zudem hat Intel den IT-Trend "Green Computing" auch für sich erkannt -> Silverthorne.

Ich glaube auch nicht, dass der K10 die 45nm überleben wird. Man wird den Sprung auf 32nm gleich mit Bulldozer nutzen wollen, denke ich, um eine Menge Geld zu sparen. Man bräuchte dann ja kein 45nm Bulldozer oder 32nm K10 Design.
Und dabei alle Technik für 45 nm in den Wind schiessen? Nein das ist noch teurer, zumal die Tools in der Halbleiterindustrie sich derzeit für 45 jetzt ökonomisch rechnen.

32 nm sind hingegen vom Reifegrad noch ein Stück entfernt für die Massenproduktion.
Was AMD zusätzlich wie Blei an den Füssen hängt sind deren aufgelaufenen Verluste.
Mag Intel notfalls eine 32 nm-Produktion im Betastatus sich erlauben können, um einen Zeitvorteil gegenüber den Wettbewerb bekommen, muss AMD in der Hinsicht jeden Dollar drei mal umdrehen. Keine Frage, IBM hat 32 nm in der Erprobung ( wie alle Branchengrössen es derzeit in Erprobung haben ).

MFG Bobo(2008 )
 
Zuletzt bearbeitet:
Im ExtremeSystems-Forum wird noch etwas interessantes angegeben:
http://www.xtremesystems.org/forums/showthread.php?p=2789367#post2789367

Das Nehalem Engineering Sample läuft mit 1Ghz und SuperPi 1M braucht ca. 180s.
Zum Vergleich, ein Pentium 3 mit 512kByte L2 @ 1GHz benötigt ca. 160s.
Wäre mal interessant Banias (1MB L2) und Dothan (2MB L2) Werte @1GHz im Vergleich dazu zu haben.
Ich könnte mich täuschen, aber evtl. kann man hier schon die L2-Cache-Grösse wirklich mit 256kByte fest angeben.

Wer weiß einen, der kennt einen, der weiß einen, der kann das messen :] ?

Grüße,
Tom

Hä?
Wie kann das sein? Habe gerade testweise meinen A64 3200+ (Winchester - SingleCore mit 512kB L2) auf 1GHz runtergetaktet und der schafft 1M in unter 43sec ???

Edit: Oh halt, Moment! Hatte vergessen C'n'Q auszuschalten...der hat immer brav auf 2GHz hochgetaktet ;D

Einen Moment...gleich kommt die richtige Messung ;D

Edit2: Wie zu erwarten: 80sec für 1M

Wenn das mit dem Nehalem und den 180sec stimmt, rate ich AMD einfach den Ur-A64 in 45nm herzustellen, davon 8Stück per HT anzubinden und einen Octa-A64-MCM zu bauen *chatt*
Wer braucht schon native MultiCore-CPUs? ;D

Edit3: Hier Kinners, ich finde meine Idee brilliant *buck*
Der Winchester hat bei 90nm und 512kB L2 Cache eine Die-Fläche von 84mm². Mit 45nm würde die Fläche (bei gleichgroßem L2 pro Kern) auf unter 40mm² fallen. Wir rechnen aber mal sehr großzügig mit 40mm², da jeder Kern noch SSE3/4/etcpp. hinterher geschmissen bekommt. Durch den Optimierungsschnickschnack der letzten Jahre im Speicherteil können wir wohl auch den L2 mit ruhigem Gewissen auf angenehme 2MB pro Kern erhöhen.
Ein OctaCore würde entsprechend auf ~320mm² mit insgesamt 8x 2MB L2 wachsen.
Zum Vergleich: Der Intel Core2Quad QX9650 in 45nm kommt mit seinen 4 Kernen und 2x 6MB L2 Cache auf 214mm². Mal 2 würde dass ein "DualCore-MCM-OctaCore" mit 4x 6MB L2 und 428mm² ergeben.

NA? NA? Wie findet ihr meine Idee...ich schick morgen direkt mal meine Bewerbung bei AMD ein *chatt*

Edit4: Das einzige was mir nur ein wenig Kopfzerbrechen machen würde, wäre die TDP...der Winchester hat (nach alter AMD-Worstcase-Rechnung) 67Watt...machen wir darauß "realistische" 50Watt...runter auf 45nm rechnen wir (diesmal nicht großzügig, sondern realistisch) mit einer "1/3-telung" der realistischen TDP auf ~17Watt...mal 8 macht das 136Watt. Hmm....bissl viel *chatt*
 
Zuletzt bearbeitet:
Jetzt habe wir schon zwei Richtwerte.

Ich fasse zusammen:
P3 mit 512kByte L2-Cache @ 1GHz = 160s
A64 mit 512kByte L2-Cache + integriertem Speichercontoller @1GHz = 80s
Nehalem mit 256kByte L2-Cache + ?schlecht funktionierendem? integriertem Speichercontroller @ 1GHz = 180s

Naja, der Nehalem wird in anderen Bereichen sicher auch noch seine Käferchen drin haben. Ich finds witzig, dass wieder so ein leichtes Säuseln durch den Boulevard-Blätterwald geht, sind immer spannende Wochen, kurz bevor konkretere Details vorgestellt werden.

Grüße,
Tom
 
Jetzt habe wir schon zwei Richtwerte.

Ich fasse zusammen:
P3 mit 512kByte L2-Cache @ 1GHz = 160s
A64 mit 512kByte L2-Cache + integriertem Speichercontoller @1GHz = 80s
Nehalem mit 256kByte L2-Cache + ?schlecht funktionierendem? integriertem Speichercontroller @ 1GHz = 180s

Naja, der Nehalem wird in anderen Bereichen sicher auch noch seine Käferchen drin haben. Ich finds witzig, dass wieder so ein leichtes Säuseln durch den Boulevard-Blätterwald geht, sind immer spannende Wochen, kurz bevor konkretere Details vorgestellt werden.

Grüße,
Tom

Wer weiß ob man den Werten trauen kann, denke ehr das es ein Fake ist oder sonstwas. Könnte mir kaum vorstellen ein Nehalem mit 1GHz schlechter sein soll als ein Pentium 3, würde schon fast an ein Aprilwitz denken, aber soweit sind wir ja noch nicht. Allerdings dürfte das wieder genug Futter für Diskussionen auf Bild Nivue geben.:]
 
Wer weiß ob man den Werten trauen kann, denke ehr das es ein Fake ist oder sonstwas. Könnte mir kaum vorstellen ein Nehalem mit 1GHz schlechter sein soll als ein Pentium 3, würde schon fast an ein Aprilwitz denken, aber soweit sind wir ja noch nicht. Allerdings dürfte das wieder genug Futter für Diskussionen auf Bild Nivue geben.:]
Ich denk bei sowas nur an die ersten K8 Werte ... damals mit Ax Silizium und 800 MHz ... das waren Bombenwert, falls sich noch jemand erinnert :)

ciao

Alex
 
Ich denk bei sowas nur an die ersten K8 Werte ... damals mit Ax Silizium und 800 MHz ... das waren Bombenwert, falls sich noch jemand erinnert :)

ciao

Alex

Waren die echten Werte denn dann so viel schlechter?
Ich weiß es nicht mehr...ist zu lange her *buck*
Ich meine mich nur noch erinnern zu können, dass der A64 doch recht gerockt hat...hach ja, das waren noch tolle Zeiten, als der Northwood richtig alt aussah und ihm selbst sein Hyperthreading kaum mehr was gebracht hat ^^

...und keiner gibt auf meine glorreiche Idee des 8-SingleCore-MCM-Athlon64-Prozessors eine Resonanz...IHR KAMERADENSCHWEINE! *chatt*
 
Zurück
Oben Unten