Neuigkeiten zum K10

[Markus Everson]

Du verstehst das falsch

Keineswegs, ich habe nur einen anderen Blickwinkel wenn ich die Kristallkugel reibe.

ich bezweifle nicht, dass es einem normalen anwender möglich ist soetwas einzurichten, sondern, dass er einnen sinn dainter sieht.... warum sollte sich ein normaler windowsbenutzer ein linux als vm installieren?

Natürlich kann ich Dir als überzeugter Linux Nutzer 10^32 Gründe dafür nennen - aber um diese Anwendung geht es gar nicht.

Der stinknormale User wird sich - wenn ich nicht irre - in naher Zukunft seine Firewall als VM installieren, seinen Messenger mitsamt seiner VM als Download beziehen und seine Homebanking via Browser ebenfalls in einer VM machen die ihm die Bank zur Verfügung stellt.

Jetzt klar was ich meine? Die VM kann vom Phisher nicht so einfach erreicht werden, der Messenger kann gefahrlos offen bleiben während die Bankdaten bearbeitet werden und einbrüche in die Firewall sind beim nächsten Reboot wieder Geschichte. Alles natürlich nur blanke und nicht haltbare Theorie, aber gerade der Normaluser wird diesen Heilsversprechen glauben und sich freuen dass er weiterhin und künftig mit noch weniger schlechtem Gewissen auf alles Klicken darf was nicht bei "Drei" auf den Bäumen ist.

 

[gast0972]

(...)und einbrüche in die Firewall sind beim nächsten Reboot wieder Geschichte.(...)

...das langt einem Rootkit, einem Trojaner, einem Keylogger oder whatever um sich einzunisten. Selbst die Linuxfraktion @ IP-Cop rät von einem Einsatz einer Firewall innerhalb einer VM DRINGENDST(!) ab. Und als Nichtlinuxer traue ich den Schaffern dieser genialen Software in dem Punkt eher (denn das ist sie).

Aber sonst hast Du recht, bereits jetzt bietet Microsoft vereinzelt lauffähige VMs zum DL an, wie es auch die Konkurrenz tut.

 

[Markus Everson]

...das langt einem Rootkit, einem Trojaner, einem Keylogger oder whatever um sich einzunisten.

Der Angreifer muss nicht nur aus seiner Applikation ausbrechen sondern zusätzlich noch die VM verlassen.
Diese Hürde ist erheblich geringer als mit einer separaten Firewall (die der Angreifer allerdings vollständig übernehmen kann ohne dass es der User merkt), aber, erst recht auf einem 64Bit-System, dennoch viel größer als bei den bisher so beliebten Desktop-Firewalls.

Selbst die Linuxfraktion @ IP-Cop rät von einem Einsatz einer Firewall innerhalb einer VM DRINGENDST(!) ab.

Natürlich tut sie das und natürlich ist das vollkommen richtig.
Allerdings sind das Fundamentalisten. Die Realisten stellt zum Beispiel die IPCOP-Fraktion @ct

Aber sonst hast Du recht, bereits jetzt bietet Microsoft vereinzelt lauffähige VMs zum DL an, wie es auch die Konkurrenz tut.

Yepp. Das richtet sich bisher vorwiegend an Entwickler, aber ich sehe halt einen Trend der von ziemlich vielen Faktoren begünstigt wird.

 

[larsbo]

Da der thread ja nun schon ein paar Seiten hat, hab ich keine Lust, mehr alles zu durchsuchen und SuFu spuckt zu viel Unsinn aus.

Deshalb meine Frage, wurde das hier schon mal diskutiert? Andreas Stiller erwähnt im Geflüster Gerüchte darüber, dass der eigentlich mal geplante K10 code-morphing Technik gehabt hätte, sei dann aber wegen zu vielen Problemen doch gegen eine leichte Überarbeitung des klassischen K8 (=dem jetzigen K10) verworfen worden. Gabs das Gerücht hier auch schon mal?

 

[Opteron]

Deshalb meine Frage, wurde das hier schon mal diskutiert? Andreas Stiller erwähnt im Geflüster Gerüchte darüber, dass der eigentlich mal geplante K10 code-morphing Technik gehabt hätte, sei dann aber wegen zu vielen Problemen doch gegen eine leichte Überarbeitung des klassischen K8 (=dem jetzigen K10) verworfen worden. Gabs das Gerücht hier auch schon mal?

Hab ich gerade auch gelesen, aber soviel ich weiss, war das hier noch nicht bekannt. Das einzige was besprochen wurde war, dass das allererste K10 Design ne Art Alpha EV8 werden sollte, also ein dicker Brocken: Nochmal die Eckpunkte (damals ... vor 5 Jahren):
EV8 Architecture Overview

• Aggressive instruction fetch unit
• 8-wide super-scalar execution unit
• 4-way simultaneous multithreading (SMT)
• Large on-chip L2 cache
• Direct RAMBUS interface
• On-chip router for system interconnect for glueless, directory-based, ccNUMA with up to 512-way multiprocessing
  
  Execution Unit Characteristics
• Single issue queue
• 8-wide
• 112+ entries
  
  Register file
• 512 registers
• 16 read/8 write ports
  
  Function units
• 8 integer ALUs
• 4 floating ALUs
• 4 memory operations (2 read/2 write)
  

Tja .. das wäre auch jetzt immer noch ein heisses Eisen... .Wieso AMD den jetzigen K10 dann doch als quasi K8+ entworfen hat .. kA, vielleicht wars zu kompliziert, zu teuer etc. pp. Aber Codemorphing .. ne .. das einzige was ja vor ein paar Jahren "hipp" war, war das "reversed hyperthreading" aber das dürfte mit code morphing auch nix zu tun haben ..

Vielleicht weiss ja Bobo noch mehr.

ciao

Alex

 

[cumec]

Habt ihr nen Link zu dem Gerücht?

Jo, Codemorphing hat mit reverse HT wenig zu tun. Damit kann man ja Befehlssätze wie SSE, mmx, 3dnow etc. emulieren. Transmetas Prozessoren basieren komplett auf diese Technik...

gruß

cumec

 

[Opteron]

Habt ihr nen Link zu dem Gerücht?

Aber klar:

http://www.heise.de/ct/07/24/018/

Es geht das Gerücht, dass Transmeta-Investor und -Partner AMD beim ursprünglich vorgesehenen K10 an so etwas - wenn auch erfolglos - herumgebastelt habe.

ciao

Alex

 

[Bobo_Oberon]

... http://www.heise.de/ct/07/24/018/ ...

dann zitieren wir die scheinbar so wertvollen Worte doch weiter ...

" ... Ein damit arbeitender „software-basierter Mikroprozessor“ könnte beispielsweise zur Laufzeit die heißen Punke (Hot Spots) von Programmen ermitteln und den betreffenden Code gezielt für die jeweilige Workload dynamisch optimieren - was die Performance zum Teil drastisch verbessern könnte. ...

Da will ich doch gleich mal den lieben Jon Stoke anführen, der zwar Sympatie, aber doch auch eine kritische Sicht auf Code-Software-Morphing hat:

" ... In the end, nothing is "free" ó everyone has to make tradeoffs.

As I just stated, the information on how to do dynamic execution and runtime profiling has to be stored somewhere, and if it's stored off-die then it has to be loaded before it can be used.

So putting dynamic execution features "in software" doesn't make them "free" in terms of transistors, power dissipation or performance. It just shifts the burden of encoding the "know-how" for doing dynamic code optimization from one place in the system to another ó a shift that's not inherently bad in and of itself,

but that can be more or less optimal depending on the state of process, memory and interconnect technologies. Right now, it's less optimal, rather than more optimal. ... "

Siehe 1.

Von der reinen Rechenkraft haben die Transmeta-Prozessoren nur teilweise überzeugen können (2.). Die Rechenleistung wurde auch dadurch ermöglicht, dass zwar der Code beständig verbessert wurde, aber "zur Laufzeit" kann man das nicht so wirklich bezeichnen.

Die Transmetas hatten einen Zwischenspeicher, der teilweise Code versteckt zwischenspeichert (was das Betriebssystem nicht sieht) um dann evolutionär während des Betriebs im Hintergrund Programmcode auf dem Rechner zu verändern.

Das geschieht aber über einen Zeitraum von Tagen und Stunden während der Nutzung.

Das eigentliche Code-Morphing-Software ist natürlich auch eine prima Sache. Ermöglicht es doch auf einem recht einfachen RISC-Kern damit nahezu jede beliebige ISA nachzubilden. Das ist aber nicht im CPU-Kern implemetiert, sondern in einem statischen Speicher als Software auf einem Mainboard neben dem BIOS, erst das Zusammenspiel von CPU-BIOS und dem statischen Speicher ermöglicht diese Technik der Code-Morphing-Software ...

In Hardware direkt verdrahtete Befehle sind aber nach wie vor die schnellste Art, Code abzuarbeiten. Nicht grundlos werden heute nach wie vor gerne FPGAs verwendet, die Befehle in Hardware sozusagen nachbilden ... ja genaugenommen zielt AMDs Torrenza genau darauf ab diese FPGAs und andere Prozessoren latenzarm rattenschnell in die K8/K10 Systemplattform über HyperTransport einzubinden (Cray hat vor kurzem ihre X5-Linie eben mit HyperTransport 3.0 und eben jenen FPGAs vorgestellt).
PS. Der Efficeon kann dank HyperTransport auch direkt in die Systemarchitektur des K8/K10 eingebunden werden. Wäre mal spannend zu wissen, ob AMD neben FPGAs auch Transmeta-CPUs in Entwicklersystemen eingebunden hat/hatte. FPGAs wurden/werden tatsächlich bei AMD auch in der Chipentwicklung eingesetzt.

... Außerdem kann man weitaus bequemer neue Features hinzufügen als bei den „hartverdrahteten“ Kollegen, wie beispielsweise vor einiger Zeit das „No Execution“ von Speicherseiten, oder Bugs beseitigen - bei einem Transmeta-Chip geht das im Handumdrehen durch ein simples Update der Code Morphing Software (CMS) ... "

Die Idee, Bugs mit Codemorphing hingegen zu verdecken, und auch sehr flexibel die bestehende Schaltungen zu ergänzen hat aber in der Tat was bestechendes.

Das macht zwar eine nachträglich "geflickte" CPU (in Verbindung mit statischen Speicher und BIOS) mit Code-Morphing-Software im Vergleich zu einer verbesserten CPU-Revison nicht schneller, verspricht aber eine weitergehendes Bugfixing, als über Microcode.

Mit anderen Worten: Software-Code-Morphing macht eine CPU per Se nicht zwingend schneller, aber verspricht eine wesentlich tiefergreifendes Bugfixing und verspricht eine wesentlich höhere Flexibilität bei Neuerungen. Und das macht sicherlich alle CPU-Schmieden immer noch spitz auf Transmeta.

1. = Ach ja: "POWER5, UltraSparc IV, and Efficeon: a look at three new processors" [arstechnica.com].

2. = "Transmeta Rundumschlag. Vergleich Benchmarks" P3D.

3. = "Fortsetzung: Der FX!32 x86 Übersetzer". Derartiges hat sicher Intels x86-Echtzeit-Wrapper für die Itaniums auch geholfen, die Alpha-Patente vom einstmaligen IT-Giganten DEC und so manch ein DEC-Alpha-Entwickler sind ja nun bei Intel.

 

[larsbo]

Wobei halt einfach ein vergebliches Herumgebastel an einem code morphing Projekt zusammen mit den sicherlich begrenzten Entwicklungskapazitäten bei AMD durchaus erklären könnte, warum das, was jetzt als K10 rauskommt halt nur eine verhältnismäßig geringgradig aufgemotzte K7/K8-Architektur ist. Die tollsten Neuerungen sind nun mal 128bit breite SSE-Rechenwerke und nativ-Quad.

 

[Markus Everson]

Andreas Stiller erwähnt im Geflüster Gerüchte darüber, dass der eigentlich mal geplante K10 code-morphing Technik gehabt hätte

Das schreibt er nicht, Du interpretierst mehr rein als in ct steht.
AS schreibt dass AMD für den K10 an CodeMorphing "gebastelt" hätte, sich dann aber dagegen entschieden habe.

Ob das gesschrieben für den ursprünglichen K10 oder den schon zum K10 hochgezählten ursprünglichen K9 gilt bleibt im Schneegestöber der Kristallkugel verborgen.

 

[larsbo]

Einigen wir uns darauf, dass AMD mal für einen potentiellen Nachfolger des K8 an einem Prozessor mit code-morphing gearbeitet hat. Und was nun K8,5 , K9, K10, K11 oder sonstwas ist, daran braucht man sich IMHO nicht aufhängen. Für Nachfolger von K8 hat AMD sicherlich Entwicklungsarbeit betrieben, und offenbar laut AS eben auch an einem Prozessor-Projekt mit code-morphing. Ob es den nur auf dem Papier gab, oder in realiter schon in Si, dazu hab ich nichts gesagt..... Und wie lange und intensiv sie dran gearbeitet haben wissen wir natürlich auch nicht. Genaugenommen WISSEN wir noch nicht mal, ob es überhaupt stimmt, dass sie je dran gearbeitet haben. Wobei halt AS vermutlich doch ganz gute Connections hat, nehme ich an.
In jedem Falle wissen wir, dass es jetzt so ein Gerät nicht gibt, sondern nur einen klein wenig aufgebohrten K8. Sollten sie sehr viel Zeit und Geld in ein dann doch unfruchtbares code-morphing Projekt gesteckt haben, dann ist klar, dass sie nach einer 180° Kehrtwende nichts Weltbewegendes mehr aus dem Hut zaubern konnten sondern sich im Wesentlichen auf das konzentrieren mussten, was sie hatten. Auch das ist ja leider, wie wir inzwischen sehen, nur mäßig gut respektive nicht völlig konkurrenzfähig gut gelungen......

 

[Markus Everson]

Einigen wir uns darauf, dass AMD mal für einen potentiellen Nachfolger des K8 an einem Prozessor mit code-morphing gearbeitet hat.

Einverstanden.

Sollten sie sehr viel Zeit und Geld in ein dann doch unfruchtbares code-morphing Projekt gesteckt haben, dann ist klar, dass sie nach einer 180° Kehrtwende nichts Weltbewegendes mehr aus dem Hut zaubern konnten

Da gibt es viel Spielraum für Interpretationen.

Der Athlon64 war auch nichts anderes als ein Athlon mit minimal verbessertem IS, integriertem MC und HT-Links. Die Welt hat er trotzdem bewegt.

 

[Opteron]

Danke @Bobo für die Jon Stoke Zitate.

Was mir noch eingefallen ist ... AMD hat sich ja damals beim K8 bei Transmeta bedankt. Die hatten mal "schnell" die AMD64 Befehlssätze auf Ihren Crusoe programmiert, wodurch AMD mit Softwaretests anfangen konnte, obwohl es noch gar kein richtiges AMD64 Silizium gab.

Eventuell war das jetzt beim K10 wieder so, und das Gerücht war halt "nur" einwenig undeutlich. Basteln ja - aber nur zu Testzwecken.

Im Moment könnte ich mir z.B. auch vorstellen, dass SSE5 programmiert bzw. schon ausprobiert wird, die Spezifikation ist ja festgelegt. Aber naja das ist wieder mal Spekulation höchsten Grades

ciao

Alex

 

[Seemann]

Heute habe ich diesen Artikel bei Anand Tech gesehen:

http://www.anandtech.com/IT/showdoc.aspx?i=3162

Er hebt sich meiner Meinung nach wohltuend von den anderen Berichten dieser Tage ab, als dass pauschales AMD-Bashing vermieden wird und einige (wenige) Benchmarks recht differenziert betrachtet werden.

Als Quintessenz bleibt auch hier - wenig überraschend - festzuhalten, dass der K10 durchaus Potenzial hat (mit z.T. sehr guter Skalierung über verschiedene Takstufen), allerdings momentan noch 500MHz fehlen um ganz vorne mitmischen zu können (die lausige Verfügbarkeit bleibt natürlich nicht unerwähnt).

 

[rkinet]

Heute habe ich diesen Artikel bei Anand Tech gesehen:

http://www.anandtech.com/IT/showdoc.aspx?i=3162

Als Quintessenz bleibt auch hier - wenig überraschend - festzuhalten, dass der K10 durchaus Potenzial hat (mit z.T. sehr guter Skalierung über verschiedene Takstufen), allerdings momentan noch 500MHz fehlen um ganz vorne mitmischen zu können (die lausige Verfügbarkeit bleibt natürlich nicht unerwähnt).

Wobei es dann wohl der TLB-Fehler ist der wohl höhere Stückzahlen aus AMD-Sicht verhindert.
Mehr Wafer wären auch mehr selektierbare DIEs und schnelle 200-300 MHz mehr in der Spitze ohne jede Schaltungsänderung.

Auf http://www.anandtech.com/IT/showdoc.aspx?i=3162&p=2
wird die 44 cycle latency L3-Latenz bemängelt, ist aber ggf. schon ausgelegt auf die 6M des Shanghai. Oder beim Versuch eingeflossen, ein anderes Problem zu patchen (das TLB-Problem ? )

Insgesamt ist der K10 aber ein gelungener Wurf, der sich nur wg. ärgerlichen Details nicht voll mit Intel messen kann.

 

[whippersnapper]

Insgesamt ist der K10 aber ein gelungener Wurf, der sich nur wg. ärgerlichen Details nicht voll mit Intel messen kann.

Das von dir zu hören, lässt mich hoffen

Mfg

 

[rkinet]

Das von dir zu hören, lässt mich hoffen

Mfg

Danke !

Erst 2 Jahre sind vergangen: Schlußspurt der Industrie bei 45nm http://www.planet3dnow.de/vbulletin/showthread.php?t=224254&highlight=45nm

Heute wird AMD als rückständig eingestuft, weil der K10 schlacht taktete und noch in alter 65nm Fertigung erstellt wird.
Vor 2 Jahren waren die 45nm utopisch und ich ein Traumtänzer jenseits der technischen Realität durch die Bank definiert.

Ich hoffe, dass Ende 2009 meine Beiträge zum K10 immer noch so realistisch wirken wie jene damals beim 45nm Thema 8)

----

http://www.computerbase.de/news/har...7/november/amd_triple-core_februar_dual-core/

Der Dual-Core K10 verschiebt sich auf Q'2008, also wohl Juni.
Nachdem die IPC des K10 nicht so gewaltig ist und eher beim X3 / X4 sich die Vorzüge zeigen,
könnte es sein, dass AMD erst die volle Kapazität der Fab38 abwartet um das recht große DIE anstelle des kompakteren K8 / G2-Stepping zu fertigen.

Interessant der Athlon LE-1640 , der sowohl als 90nm als auch 65nm mit unterschiedlichen Cache und Taktraten weider gleichen Namen erhält.
Diese uralte Tradition aus der K7 XP Ära steht weider auf - man fühlt sich gleich 5 Jahre jünger

 

[dev art]

Fudzilla:

AMD's Phenom 2.6GHz+ bug free samples are out

Production in Q1

Despite the big announcement that stated that the current B2 revision has what AMD calls an “errata”, the new samples work stable at 2.6GHz and above.

The errata is fixed and the production version of this core is on track for Q1 2008 production. There is a chance that you will be able to buy a 2.6GHz Phenom by the middle of Q1 2008 and things are finally starting to look a bit better for AMD.

The company messed up, but we believe that 2008 is the year of AMD where the company will get back on its feet on a few fronts. 2007 has been the worst year in AMD’s history and this certainly is AMD’s Prescott.

We just found out that in Latin, errata is a word in plural, which clearly means that AMD had more than just one tiny mistake, but luckily it will be over soon.

____________________
Also wenn die jetzt die Masken machen, sind die 2,6er in 6 Wochen verfuegbar.

Gruss
Dev Art
.
EDIT :
.
Quelle: http://www.fudzilla.com/index.php?option=com_content&task=view&id=4470&Itemid=1

Gruss
Dev Art

 

[Rangoon]

There is a chance that you will be able to buy a 2.6GHz Phenom by the middle of Q1 2008 and things are finally starting to look a bit better for AMD.

Na, das ist doch einmal eine gute Nachricht. Wobei die Betonung auf dem Konjunktiv liegt: "There ist chance to buy a 2.6GHz Phenom....". Viel wichtiger als ein möglichst früher Launch des B3 ist aber, daß das Teil wirklich absolut stabil läuft. Da kommt es auf vier Wochen hin oder her auch nicht darauf an. Ferner bin ich gespannt, ob dieser 2.6GHz Phenom tatsächlich eine TDP von 140W hat. Kann (und mag) ich mir nicht wirklich vorstellen.

Es dürfte ohnehin interessant werden, wie AMD in Zukunft die K8 positioniert. Denn mit den hohen Taktraten, welche beim K8 mittlerweile möglich sind, konkurriert man hausintern bei der Spieleperformance mit dem K10. Pauschal kann man bei Games sagen, daß es ca. einen 3GHz Phenom braucht, um mit einem X2 6400+ mitzuhalten. So gesehen dürften AMD die hochgetakten K8 etwas lästig sein, schlagen sie doch das eigene Flaggschiff bei der Gaming-Performance um längen. Selbst ein Phenom mit 2.6GHz ändert da nichts dran.

Bei "ernsthaften" Anwendungen sieht es aber offensichtlich gar nicht mal so schlecht für den Phenom aus. Die Anzahl der Multithreading-Programme wächst und auf diesem Gebiet setzt sich der K10 doch sehr deutlich vom K8 ab. Wenn dann noch die neue SEE-Einheit zum tragen kommt, gibt es ja nochmal einen Performanceschub.

Na, mal schauen. Vielleicht ist die K10-Archtektur doch nicht so schlecht, wie ich letzte Woche beim Phenomlaunch noch geglaubt habe. Ein Gaming-Prozessor ist der Phenom aber offensichtlich nicht, von daher wird mein nächster ein Intel.

Gruß

Rangoon

 

[Markus Everson]

Vor 2 Jahren waren die 45nm utopisch und ich ein Traumtänzer jenseits der technischen Realität durch die Bank definiert.

Ich hoffe, dass Ende 2009 meine Beiträge zum K10 immer noch so realistisch wirken wie jene damals beim 45nm Thema 8)

Zitat:
"'2007' ist zumindest für IBM ein Zeitpunkt für die Realisierung von 45nm."
Zitatende.

Deine Kristallkugel eiert.

 

[Nightshift]

Jaja, angeblich soll nun laut Inquirer nun auch noch ein Fehler im L3 sein der bis zu 10% Performance kostet und demnächst mit einem Microcodeupdate gelöst werden soll, was dann die Phenoms um bis zu 10% beschleunigen soll.
Jetzt ist die Frage wieviel da dran ist oder ob da der Wunsch der Vater des Gedanken war.
Schön wärs natürlich wenn sich das bewahrheitet, würde doch dann bei gleichem Takt der Anschluss an den Conroe gefunden.

 

[Opteron]

Jaja, angeblich soll nun laut Inquirer nun auch noch ein Fehler im L3 sein der bis zu 10% Performance kostet und demnächst mit einem Microcodeupdate gelöst werden soll, was dann die Phenoms um bis zu 10% beschleunigen soll.
Jetzt ist die Frage wieviel da dran ist oder ob da der Wunsch der Vater des Gedanken war.
Schön wärs natürlich wenn sich das bewahrheitet, würde doch dann bei gleichem Takt der Anschluss an den Conroe gefunden.

Waa .. noch jemand, der den Blödsinn kopiert ... bitte entfern den Link, das ist wieder ne "Theo-hat-was-gehört-hat-keinen-Schimmer-aber-hält-große-Reden" Nachricht ...

Mehr dazu:
http://www.planet3dnow.de/vbulletin/showpost.php?p=3419707&postcount=8

ciao

Alex

 

[Nightshift]

Wieso "Blödsinn kopiert"?
Kopiert ist da wenig ich habe lediglich auf die Meldung hingewiesen, kurz abgefasst was drin steht und das mit angebrachten (und sich nun bewahrheitetem) Zweifel!? Falls ich mich hier selbst einmal zitieren darf:

Jaja, angeblich soll nun laut Inquirer nun auch noch ein Fehler im L3 sein der bis zu 10% Performance kostet und demnächst mit einem Microcodeupdate gelöst werden soll, was dann die Phenoms um bis zu 10% beschleunigen soll.
Jetzt ist die Frage wieviel da dran ist oder ob da der Wunsch der Vater des Gedanken war.
Schön wärs natürlich wenn sich das bewahrheitet, würde doch dann bei gleichem Takt der Anschluss an den Conroe gefunden.

P.S.: Nein keine Zensur, Link bleibt drin.
So ist wenigstens garantiert, dass niemand in 5 Minuten dasselbe nochmal hier schreibt.

 

[Opteron]

P.S.: Nein keine Zensur, Link bleibt drin.
So ist wenigstens garantiert, dass niemand in 5 Minuten dasselbe nochmal hier schreibt.

Stimmt auch wieder, da hast Du recht ...

Falls es einwenig zu harsch rüber kam, sorry

ciao

Alex

 

[Bobo_Oberon]

Vor 2 Jahren waren die 45nm utopisch und ich ein Traumtänzer jenseits der technischen Realität durch die Bank definiert.

Ich hoffe, dass Ende 2009 meine Beiträge zum K10 immer noch so realistisch wirken wie jene damals beim 45nm Thema 8)

Zitat:
"'2007' ist zumindest für IBM ein Zeitpunkt für die Realisierung von 45nm."

Deine Selbstreflexion und Einschätzung von Fremdbeiträgen ist hanebüchen.

Dass 45 nm kommen werden hatte schon damals Niemand ernsthaft bezweifelt, lediglich der Zeitpunkt zur Massenfertigung war vor zwei Jahren unklar.

Zudem war damals unklar, ob EUV, oder doch andere Methoden den Schritt auf 45 nm kostengünstig ermöglichen. Da hatte ich damals ein sehr grosses Fragezeichen bei EUV eingesetzt. Tatsächlich nutzt Intel Doppelbelichtungslithographie, während die Allianz rund um IBM auf Nasslithographie setzt.

Zur Info: IBM will erst ab Mitte 2008 45 nm in der Massen-Fertigung einsetzen. Ab etwa Mitte 2008 will IBM damit Power-PC-Derivate damit auf den Markt bringen.

Es ist ein kleiner Unterschied, ob es eine Testanlage gibt, die aber nun mal noch nicht für den Massenmarkt produziert. AMD und IBM betreiben jetzt derzeit die Vorbereitung für 45 nm Massenfertigung.

MFG Bobo(2007)