Intel lässt viele Dual- und Quad-Core CPUs auslaufen und senkt Preise

Der in der Regel gut informierte Branchendienst <a href="http://www.digitimes.com/NewsShow/MailHome.asp?datePublish=2008/9/17&pages=PD&seq=213" target="_blank">Digitimes</a> skizziert unter Berufung auf Quellen aus dem Bereich der Mainboard-Hersteller, dass Intel demnächst zahlreiche Produkte einstellen wird. Dabei gibt es wie üblich zwei Stufen: "product discontinuance notice" (PDN) und "end of life" (EOL).

Demnach soll es im ersten Quartal 2009 die Core 2 Extreme QX9770 und 9650 treffen, ebenso wie Core 2 Quad Q9450, 10 Dual-Core CPUs samt Core 2 Duo E8300, drei Pentium CPUs inklusive Pentium E2220 und den Celeron E1200. All diese CPU sollen bis zum zweiten Quartal 2009 EOL sein.

Dafür rücken eine Reihe neuer CPUs nach. Im Oktober soll erst einmal ein Core 2 Duo E7400 erscheinen. Das wichtigste jedoch: für den November ist der Launch des <a href="http://www.planet3dnow.de/cgi-bin/newspub/viewnews.cgi?category=1&id=1212666530">Nehalem</a> geplant, der als Intel Core i7 965 (3,2 GHz), Intel Core i7 940 (2,93 GHz) und Intel Core i7 920 (2,66 GHz) erscheinen soll - zusammen mit dem für die neue Plattform notwendigen Chipsatz Intel X58. Zudem sollen Ende November noch einmal neue Core 2 Prozessoren erscheinen, die da wären: Core 2 Quad Q8300 (2,5 GHz), Pentium E5300 (2.6 GHz) und ein Dual-Core Celeron E1500 (2,2 GHz) zu Preisen von US$224, US$86 und US$53 bei Abnahme von 1000 Stück. Im Januar soll ein Core 2 Duo E7500 (2,93 GHz; US$133) folgen.

Zudem soll es zahlreiche moderate Preissenkungen geben. Im Oktober sollen zuerst einmal die Preise für Core 2 Quad Q8200 und Q6600, Core 2 Duo 7300, sowie Pentium E2220 und E2200 CPUs fallen. Im Januar sollen Preissenkungen folgen für Core 2 Quad Q8200 von US$193 auf US$183, Core 2 Duo E7400 von US$133 auf US$113, Pentium E5200 von US$84 zu US$76, Pentium E2220 von US$84 zu US$64 und Celeron E1400 von US$54 zu US$43.

Die Informationen sind unbestätigt.

Kann das sein, dass die Jungs bei Intel zur Zeit wahnsinnig Gas geben?
Es vergeht glaub ich keine Woche die letzte Zeit, wo ich nicht was über Intel Ankündigungen lese, echt erstaunlich

Avatar schrieb:

Kann das sein, dass die Jungs bei Intel zur Zeit wahnsinnig Gas geben?
Es vergeht glaub ich keine Woche die letzte Zeit, wo ich nicht was über Intel Ankündigungen lese, echt erstaunlich

Zum Vergrößern anklicken....

Schaut so aus, als möchte man die 3M Penryn und 2M Penryn preislich attraktiver gestalten. Der Q8xxx wird dann der Einstieg bei den Quadcore Modellen...


Grüße!

Ok, jetzt wird's bei Intel langsam auch wieder unübersichtlich mit den Namensschemata.

wieso?

Es gibt die Pentium E2xxx

Celerons E1xxx

Core2Duo E7xxx & E8xxx

Core2Quad E8xxx 9xxx

und dann die Nehalms die 3

Desertdelphin schrieb:

Core2Quad E8xxx 9xxx

Zum Vergrößern anklicken....

Tausche E für ein Q und du hast den 6600er vergessen - der hat noch keine PDN oder EOL abgekriegt.

für eine preistabelle hat die zeit nicht mehr gereicht ?

Desertdelphin schrieb:

wieso?

Es gibt die Pentium E2xxx

Celerons E1xxx

Core2Duo E7xxx & E8xxx

Core2Quad E8xxx 9xxx

und dann die Nehalms die 3

Zum Vergrößern anklicken....

Naja, im Prinzip basiert das doch auf Core 2 Modelle mit 2MB shared L2, 3Mb shared L2 und 6 Mb shared L2, dazu eben die Quads mit 2 Dies in einem Package....

Die E5200 und 5300 sind dann die Dualcore Pendants zum Q8200/Q8300...ersterem sind die SSE4.1 Funktionen gekappt, bei den Quads fehlt Intel VT....

2MB shared L2 finde ich grade bei den Quads etwas knapp bemessen...mit FSB 266 wird es auch keine Quads mehr geben, wohingegen bei den Dualcores die E5xxx Reihe mit 200 FSB auskommt und die E7xxx Reihe mit 266...Der Rest hat wie gewohnt FSB 333 und neue Modelle mit FSB 400 wie den Q9770 wirds anscheinend nicht geben....
Grüße!

Also der Pentium Dual Core E5200 ist nen super Teil. 45nm, gut übertaktbar dank hohem Multiplier (12,5) und mit 2MB L2 auch nicht der langsamste. Der E5300 ist bei dem hohen Multiplier eigentlich garnicht mehr nötig. *g

Der C2Q6600 hält sich wacker...

irgendwas müssen sie mit ihren 65nm Fabs auch noch machen!

Hi,

gibts eigentlich schon Nehalem-Test Systeme, so als vorab Tests in irgendwelchen Redaktionen? Speziell ein Vergleich zu den Penryns wäre ja interessant (leistungsmäßig, kostenseitig, und Effizienz).

mw33 schrieb:

Hi,

gibts eigentlich schon Nehalem-Test Systeme, so als vorab Tests in irgendwelchen Redaktionen? Speziell ein Vergleich zu den Penryns wäre ja interessant (leistungsmäßig, kostenseitig, und Effizienz).

Zum Vergrößern anklicken....

... das endet doch meist damit, daß sinnlose Spiele- oder Videotests gefahren werden Vor allem wird der Core-i7 bei Spielen schlecht(er) abschneiden (so jedenfalls die Progonosen von Anandtech), weil der Cache mit nur 8MB doch erheblich kleiner ist als jener der Penryns. Der Rechendurchsatz hingegen soll sich ja laut Aussagen des neuen Intel-Primus SUN erheblich verbessert haben, man spricht von 'Rekorden'. Da fällt mir ein, daß AMD ähnliches von den eigenen K10 vor dessen Start behauptete - die Messungen wurden wohl unter Ausschluß der Konkurrenz und nur im Vergleich der Kinder aus eigenem Hause getätigt. Intel wird es nicht anders machen bzw. gemacht haben.

Tests wären toll, die SPEC Suite auf einem X58/i7-940 System wäre schick ...

Drohne schrieb:

Vor allem wird der Core-i7 bei Spielen schlecht(er) abschneiden (so jedenfalls die Progonosen von Anandtech), weil der Cache mit nur 8MB doch erheblich kleiner ist als jener der Penryns.

Zum Vergrößern anklicken....

Die Ursache dürfte hier nicht die Größe sein (bisher standen ja auch nur 6 MB On-Die shared für zwei Kerne zur Verfügung), sondern daran, dass der große Cache eine Stufe in der Hierachie nach unten gewandert ist. Beim Penryn war der Last-Level Cache der Level 2 Cache, beim Nehalem ist es der Level 3 Cache, der den Großteil der Daten puffert. Unterschied: die L2-Latenz liegt im Bereich von 12 Takten, die L3-Latenz dagegen irgendwo bei 40 Takten. Der Nehalem kann schon noch jede Menge an Daten für die Spiele-Engine cachen, es dauert nur länger, bis sie aus dem Cache geholt werden können.

Intel hat das Prinzip der großen shared L2-Caches beim Nehalem zu gunsten von kleinen privaten L2-Caches aufgegeben. So stehen den Nehalem-Kernen künftig dedizierte, eigene L2-Caches zur Verfügung, auf die wesentlich schneller zugegriffen werden kann, als bisher. Nachteil: sie sind nur noch je 256 KB groß, nicht mehr 6 MB. Bei Spielen wirkt sich das offenbar nachteilig aus, da die Game-Engine und die am häufigsten verwendeten Daten somit nicht mehr in den L2-Cache passen, sondern immer wieder aus dem relativ langsamen L3 geholt werden müssen.

Nero24 schrieb:

Die Ursache dürfte hier nicht die Größe sein (bisher standen ja auch nur 6 MB On-Die shared für zwei Kerne zur Verfügung), sondern daran, dass der große Cache eine Stufe in der Hierachie nach unten gewandert ist. Beim Penryn war der Last-Level Cache der Level 2 Cache, beim Nehalem ist es der Level 3 Cache, der den Großteil der Daten puffert. Unterschied: die L2-Latenz liegt im Bereich von 12 Takten, die L3-Latenz dagegen irgendwo bei 40 Takten. Der Nehalem kann schon noch jede Menge an Daten für die Spiele-Engine cachen, es dauert nur länger, bis sie aus dem Cache geholt werden können.

Intel hat das Prinzip der großen shared L2-Caches beim Nehalem zu gunsten von kleinen privaten L2-Caches aufgegeben. So stehen den Nehalem-Kernen künftig dedizierte, eigene L2-Caches zur Verfügung, auf die wesentlich schneller zugegriffen werden kann, als bisher. Nachteil: sie sind nur noch je 256 KB groß, nicht mehr 6 MB. Bei Spielen wirkt sich das offenbar nachteilig aus, da die Game-Engine und die am häufigsten verwendeten Daten somit nicht mehr in den L2-Cache passen, sondern immer wieder aus dem relativ langsamen L3 geholt werden müssen.

Zum Vergrößern anklicken....

Ist das bei AMD nicht auch so ? , mag mit dem Design des nativen Mem-Controller zusammenhängen, jeder Core hat seinen eigenen L2 wärend man bei nicht nativen Cores quasi gemeinsam auf einen L2 zurückgreift. Zumindest vermute ich das mal. Hat sicher Vor und Nachteile die Lösung.

Zidane schrieb:

Ist das bei AMD nicht auch so ? , mag mit dem Design des nativen Mem-Controller zusammenhängen, jeder Core hat seinen eigenen L2 wärend man bei nicht nativen Cores quasi gemeinsam auf einen L2 zurückgreift. Zumindest vermute ich das mal. Hat sicher Vor und Nachteile die Lösung.

Zum Vergrößern anklicken....

Ja, das ist bei AMD auch so. Mit dem Unterschied, dass der Last-Level Cache beim Phenom nicht 8 MB, sondern nur 2 MB groß ist und dass die Cache-Latenzen beim Phenom - sowohl aus dem L2, als auch aus dem L3-Cache - deutlich schlechter sind, als beim Nehalem. Dazu kommt noch der Kohärenz-Overhead beim K10 durch die exklusive Cache-Verwaltung (beim Nehalem: inklusiv).

Mit dem integrierten Memory-Controller hat das nichts zu tun. Es gibt eben verschiedene Philosophien bei der Cache-Konzeption. Die eine Strategie hat hier Vorteile, die andere dort. Die meisten Spiele scheinen eben mit großen, shared L2-Caches besser klar zu kommen.

Ich glaube aber nicht, dass sich das nachteilig auf den Erfolg des Nehalem auswirken wird. Die ganze Plattform und die Kerne selbst haben so viele Verbesserungen erfahren, die machen das locker wett.

Davon ist - nach den vorab-berichten bisher - wirklich zu erwarten.
Ich jedenfalls bin sehr auf die ersten unabhängigen Tests gespannt.

'Shanghai' wird ja nun auch mit 6 MB L3 Cache das Licht der Welt erblicken, womit er zumindest volumenmäßig mit i7 konkurrieren kann. Wenn ich inklusive und /oder exklusive Strategien richtig verstanden habe, muß bei Intels Cache ein 256 KB L2 Cache nochmals identisch im L3 liegen, während bei AMD L3 und die jeweiligen L2 Caches disjunkt sind. Bei AMD wären dann wirkliche 4x 512KB + 2 MB Cache vorhanden, während bei Intel im L3 eben die Größen der L2-Caches, summa summarum 1 MB, abzuzuehen wären. Dann erscheint der 8 MB L3 Cache doch wiederum relativ klein und es würde erklären, warum die L2 Caches so klein gewählt sind. Das natürlich nur dann, wenn es wirklich Kompromisse einzugehen gäbe.
Mal schauen, was AMD am Shanghai verändert hat hinsichtlich Cache-Latenzen und, viel wichtiger, wie sich i7 im mathematisch-physikalischen Umfeld im Vergleich zum Barcelona schlägt.

die 8MB klein, weil 1MB abgezogen werden muss?
Das wären immernoch 7MB L3-Cache...also 1MB mehr, als beim Shanghai...

Auch der L1 muss beim Intel im L2 liegen und danach im L3, soweit ich weiß.

Wobei sich das beim i7 geändert haben könnte. MOESI kam ja auch.

lg
__tom

tomturbo schrieb:

Auch der L1 muss beim Intel im L2 liegen und danach im L3, soweit ich weiß.

Wobei sich das beim i7 geändert haben könnte. MOESI kam ja auch.

lg
__tom

Zum Vergrößern anklicken....

dann rechne mal, wieviel Cache er unterm stroch dann wirklich hat

Andy06 schrieb:

dann rechne mal, wieviel Cache er unterm stroch dann wirklich hat

Zum Vergrößern anklicken....

Das war immer so bei den Blauen
Das soll den hartgesottenen SuperPI Fanboy aber noch nie gestört haben *gg*

lg
__tom

Drohne schrieb:

Wenn ich inklusive und /oder exklusive Strategien richtig verstanden habe, muß bei Intels Cache ein 256 KB L2 Cache nochmals identisch im L3 liegen, während bei AMD L3 und die jeweiligen L2 Caches disjunkt sind.

Zum Vergrößern anklicken....

Das hast Du völlig richtig verstanden. Bei Intel ist es so: Daten, die im L1-Cache liegen, liegen auch im L2-Cache und im L3-Cache - und zwar nicht nur optional, sondern auf jeden Fall. Sie verschwenden damit Platz. Bei AMD dagegen liegen Daten ENTWEDER im L1 XODER im L2 XODER im L3. Damit wird kein Platz verschwendet.

Die exklusive Cacheverwaltung bei AMD stammt aus der Zeit des K7. Damals war On-Die Cache noch ein wertvolles Gut aufgrund der groben Strukturen. Beim ersten K7 war der L2-Cache sogar noch Off-Die. Beim ersten Thunderbird mit On-Die L2 war eine exklusive Cacheverwaltung daher genau die richtige Strategie, weil sie sehr behutsam mit dem knapp bemessenen Cache umgeht. Nachteil: sie ist aufwändiger und bedingt längere Cache-Latenzen.

Inzwischen jedoch, wo die Herstellungsverfahren so weit verbessert wurden, dass On-Die Cache nicht mehr KB-weise, sondern MB-weise auf die CPUs belichtet werden kann, verliert die exklusive Cacheverwaltung ihre Darseinsberechtigung immer mehr. Stattdessen schlagen die Nachteile voll durch.

Am schlimmsten macht sich die exklusive Cacheverwaltung bei Multi-Core Prozessoren in Multi-Sockel-Systemen bemerkbar. In einer solchen Umgebung, muss ein Prozessor bei einem Cache-Miss im eigenen Node zuerst in den Caches aller anderen Nodes (=CPUs) nachsehen - und zwar sowohl in deren L3-Cache, als auch in sämtlichen L2- und L1-Caches, um sicherzustellen, dass dort nicht irgendwo aktuelle Daten herumliegen. Erst wenn feststeht, dass dies nicht der Fall ist, darf auf das RAM zugegriffen werden. Bei Intels inklusiver Cacheverwaltung dagegen genügt es, im Last-Level-Cache der anderen Nodes nachzusehen. Liegen die Daten dort nicht, ist sichergestellt, dass sie auch in keinem der übergeordneten Caches liegen und es steht viel schneller fest, ob auf das RAM zugegriffen werden muss/darf oder nicht. Der L3-Cache maskiert damit die zahlreichen privaten L2-Caches und spart einiges an Kohärenz-Overhead. Aus diesem Grund müsste der Nehalem in Multi-Sockel Umgebungen (also im HPC-Bereich und großen Datenbank-Servern) meiner Meinung nach hervorragend skalieren.

...und man sieht: hier ist der shared L3-Cache (im Gegensatz zur Geschichte mit den Spielen) wiederum ein riesen Vorteil.

Interessant Nero. Danke...

Allerdings dazu eine Frage:

Wie kommt es, dass Intel so locker soviel mehr Cache als AMD verbaut und trotzdem keine signifikant größeren Dies abliefert?

Deracus schrieb:

Wie kommt es, dass Intel so locker soviel mehr Cache als AMD verbaut und trotzdem keine signifikant größeren Dies abliefert?

Zum Vergrößern anklicken....

Die haben die bessere Transistorentechnik und können somit mehr Zellen auf weniger Platz pressen. IBM (und damit wohl auch AMD) ist eigentlich bei 45nm mehr oder minder gleichgezogen, aber beim Shanghai werden trotzdem noch die dicken Zellen verbaut ... keine Ahnung wieso, vielleicht weil das IBM Design bei AMDs 45nm Entwurfsphase noch nicht verfügbar war. Mal schauen, wie die Cachegröße beim 6 Kerner ausfällt.

ciao

Alex