Intel Pentium 5 mit 64 Bit Windows Elementen

[KM]

Spekulation Extrem:
http://www.the-inquirer.net/?article=11785

Laut "The Inquirer" auf Computex 2003 soll es Intel-intern Januar 2004 in 90 nm produziert werden und bis zu 6 Monate später den Markt mit LGA 775 pin Socket erreichen.
Es soll 5 bis 7 GHz erreichen und 2+ MB Level 2 Cache haben.
Es soll einen FSB von 4000 MHz haben.
Die 64 Bit Elemente von Windows soll es auch unterstützen. Klingt irgendwie nach Athlon64.

FSB von 4000 MHz klingt extrem viel.
Momentan sind es 200 MHz mit 4 Byte pro Takt = FSB 800
Bei 4000 MHz denke ich eher 8 Byte pro Takt. Dann wäre es real 500 MHz. Dann müssen die mit 500 MHz außerhalb der Chips zurechtkommen.

(Ich habe einen weiteren Hinweis im Board nicht gesehen. Kann man Suchfunktion für max. 1 Woche oder so nicht machen? Nicht länger)

[Gast]

Ich finde ein mod sollte diesen Unfug schleunigst zumachen oder auf die Spielwiese verlagern!

[KM]

Original geschrieben von Gast
Ich finde ein mod sollte diesen Unfug schleunigst zumachen oder auf die Spielwiese verlagern!
Wenn es der Wunsch ist, dann werde ich nichts/kaum mehr posten.
Andererseits kannst Du Anstand zeigen, anstatt dies als Gast zu posten.

[Demirug]

Original geschrieben von Gast
Ich finde ein mod sollte diesen Unfug schleunigst zumachen oder auf die Spielwiese verlagern!

Warum? Ist auch nichts schlechter oder besser als das was sonst so im Spekulationsforum ist.

[Tigerchen]

Original geschrieben von Demirug
Warum? Ist auch nichts schlechter oder besser als das was sonst so im Spekulationsforum ist.

Stimmt.
Liest sich allerdings wie schierer Nonsens.

[KM]

Original geschrieben von Tigerchen

Stimmt.
Liest sich allerdings wie schierer Nonsens.
Stimmt auch. Von "The Inquirer" ist man von deren Spekulationen nichts anderes gewöhnt. Ab und zu treffen sie ins Schwarze. ;)

[Aqualon]

Original geschrieben von KM
Ab und zu treffen sie ins Schwarze. ;)

Tja, wer genügend Pfeile abfeuert, wird auch irgendwann treffen ;)

Das mit dem FSB halte ich auch für unwahrscheinlich. Ich denke es ist eher wahrscheinlich, dass Intel auch die Idee des integrierten Memory Controllers übernimmt und der Begriff FSB damit eh überflüssig wird wie beim A64.

Aqua

[Crazytype]

das glaube ich nicht. intel hat auch seinen stolz, und keine lust, amd immer alles nach zu machen.

[GUNDAM]

Ich sage nur: Man sollte nicht alles glauben was bei The Inquirer steht;)

[Aqualon]

Original geschrieben von Crazytype
das glaube ich nicht. intel hat auch seinen stolz, und keine lust, amd immer alles nach zu machen.

Stolz hin oder her, dass ein integrierter Memory Controller besonders bei den Latenzen ziemliche Vorteile bringt ist ja nicht von der Hand zu weisen.

Und da die alleine durch DDR2 nicht besser werden (eher das Gegenteil), muss sich Intel was einfallen lassen.

Aqua

[Crazytype]

mehr takt= geringere latenzen, vielleicht steigen die ja wieder auf rambus um *g*

[Aqualon]

Original geschrieben von Crazytype
mehr takt= geringere latenzen, vielleicht steigen die ja wieder auf rambus um *g*

mehr Takt = mehr Wärme = Problem

Wahrscheinlich wird bald beim RAM auch noch ein Lüfter draufgeklebt, wenn das so weitergeht. Erste Maxime bei der Erstellung von Chips sollte IMO immer sein eine fest definierte Leistung mit möglichst geringem Energieaufwand zu erreichen. Deswegen halte ich von Intels GHz-Wahn nicht sonderlich viel.

Aqua

[Endorphine]

Immer wieder schön, die Yamhill-Spekulationen wollen nicht enden. Dabei wird gerne vergessen, dass Intel schon seit Jahren einen eigenen Nachfolger der IA32-Architektur entwickelt: IA64, die "EPIC" Architektur, realisiert in der von HP und Intel gemeinsam entwickelten und vorangetriebenen Itanium-Produktlinie.

Als Reaktion auf den Opteron hat Intel den Deerfield-Itanium auf den Markt gebracht, der den hauseigenen Xeon-Produkten Konkurrenz macht. Eckdaten Itanium mit Deerfield Kern: "nur" 1,5 MB L3-Cache, in 1,0 und 1,4 GHz verfügbar. Die low-voltage Variante mit 1,0 GHz setzt dabei nur 62 Watt in Wärme um. Kosten: 1,0 GHz ~740 US$, 1,4 GHz ~1200 US$. Ein Schnäppchen also für einen Itanium2. Intel beschleunigt also die Marktdurchdringung von IA64 als Reaktion auf AMD64-Produkte.

Ich finde die Annahme lustig, dass AMD eine 64-Bit Architekturerweiterung zu IA32 auf den Markt bringt und dann bereits ein Jahr nach dem Start dieser Produktlinie ernsthaft spekuliert wird, ob Intel deshalb nun Milliarden an Investitionen aus dem IA64-Projekt abschreibt, die Itanium-Produktlinie zugunsten einer Fremdarchitektur abschreibt, die gerade mal käuflich zu erwerben ist, aber überhaupt noch nicht etabliert oder gar Marktgewicht hat.

Und - nichts gegen die AMD64-Architektur, sie schreibt ja die x86-Geschichte 1:1 weiter (man vergleiche IA32 -> AMD64 mit i80286 -> i80386). Aber ist AMD64 wirklich die grosse Weiterentwicklung, der grosse architektonische Sprung? Mir persönlich gefällt da der IA64-Ansatz besser. Ich kann mir einfach nicht vorstellen, dass das ehrgeizige IA64-Projekt durch eine aufgebohrte 64-Bit Erweiterung von IA32 in einem Desktopprozessor torpediert werden soll. Die Annahme ist doch absurd.

[Crazytype]

ja mehr takt= mehr wärme. das sieht man ja am prescott. irrgentwann geht es nichtmehr weiter. daher ist auch der SOI Einsatz von AMD innovativ.

[Leonidas]

Original geschrieben von KM
Es soll einen FSB von 4000 MHz haben.
FSB von 4000 MHz klingt extrem viel.



Was die da wieder zusammentexten. Nach wie vor recht feststehenden Roadmap siehe hier:
http://www.forum-3dcenter.org/vbulletin/showthread.php?s=&postid=1023040#post1023040
Einzige wesentliche Änderung (neben Terminverschiebungen): Nehalem wird neue Architektur.

[Demirug]

Endo, es wäre nicht das erstemal das sich die x86 Gruppe gegen "die Anderen" durchsetzt. Die Fortführung der x86 Reihe war von Intel ja eigentlich nur als Lückenfüller gedacht. Nur waren dieser Lückefüller immer erfolgreicher als das Produkt das eigentlich von Intel für die Zukunft vorgesehen war. Ich sage nur i860 und i960.

[Aqualon]

Original geschrieben von Demirug
Endo, es wäre nicht das erstemal das sich die x86 Gruppe gegen "die Anderen" durchsetzt. Die Fortführung der x86 Reihe war von Intel ja eigentlich nur als Lückenfüller gedacht. Nur waren dieser Lückefüller immer erfolgreicher als das Produkt das eigentlich von Intel für die Zukunft vorgesehen war.

Vorallem wird man die IA64-Reihe in den nächsten Jahren wohl nicht in den Mainstream und Lowcost-Markt bringen können, da diese Prozessoren momentan einfach zu teuer in der Herstellung sind.

Und selbst wenn Intel die A64-Technologie übernehmen sollte, gäbe es noch genügend Möglichkeiten IA64 im Highend-Server Bereich zu positionieren.

Geschwindigkeitsmäßig sieht es ja sehr gut für die Itaniums aus, wenn die Software darauf angepasst worden ist (gegen die FP-Einheit des Itanium 2 z.B. sieht ja ein Opteron auch kein Land).

Und ob es technisch möglich (und vorallem finanziell rentabel) ist einen IA64-Prozessor mit schneller IA32-Unterstützung zu bauen, wird sich zeigen müssen. Auch Intel hat IMO nicht genügend Marktmacht, um die x86-Technik, die mit 32 Bit Architektur seit 18 Jahren existiert durch eine dazu inkompatible 64 Bit Technik zu ersetzen, wenn es eine alternative Technik mit sehr schneller 32 Bit Unterstützung gibt.

AMDs Weg ist da meiner Meinung nach eindeutig die bessere Lösung, was aber nicht heisst, dass es für IA64 keine Marktchancen gibt. Aber im Normaluser-Markt dürfte IA64 wohl vorerst keine Chance haben.

Aqua

[BlackBirdSR]

Original geschrieben von Aqualon
Und ob es technisch möglich (und vorallem finanziell rentabel) ist einen IA64-Prozessor mit schneller IA32-Unterstützung zu bauen, wird sich zeigen müssen.

muss Intel gar nicht. Anscheinend legt man einen Software Layer über das Ganze. Der x86 Code wird dann in Laufzeit in IA64 umgewandelt, der Itanium direkt mit optimiertem iA64 Code gefüttert.
Zumindest in der Theorie ;)

[Tigerchen]

Original geschrieben von Endorphine
Immer wieder schön, die Yamhill-Spekulationen wollen nicht enden. Dabei wird gerne vergessen, dass Intel schon seit Jahren einen eigenen Nachfolger der IA32-Architektur entwickelt: IA64, die "EPIC" Architektur, realisiert in der von HP und Intel gemeinsam entwickelten und vorangetriebenen Itanium-Produktlinie.

Als Reaktion auf den Opteron hat Intel den Deerfield-Itanium auf den Markt gebracht, der den hauseigenen Xeon-Produkten Konkurrenz macht. Eckdaten Itanium mit Deerfield Kern: "nur" 1,5 MB L3-Cache, in 1,0 und 1,4 GHz verfügbar. Die low-voltage Variante mit 1,0 GHz setzt dabei nur 62 Watt in Wärme um. Kosten: 1,0 GHz ~740 US$, 1,4 GHz ~1200 US$. Ein Schnäppchen also für einen Itanium2. Intel beschleunigt also die Marktdurchdringung von IA64 als Reaktion auf AMD64-Produkte.

Ich finde die Annahme lustig, dass AMD eine 64-Bit Architekturerweiterung zu IA32 auf den Markt bringt und dann bereits ein Jahr nach dem Start dieser Produktlinie ernsthaft spekuliert wird, ob Intel deshalb nun Milliarden an Investitionen aus dem IA64-Projekt abschreibt, die Itanium-Produktlinie zugunsten einer Fremdarchitektur abschreibt, die gerade mal käuflich zu erwerben ist, aber überhaupt noch nicht etabliert oder gar Marktgewicht hat.

Und - nichts gegen die AMD64-Architektur, sie schreibt ja die x86-Geschichte 1:1 weiter (man vergleiche IA32 -> AMD64 mit i80286 -> i80386). Aber ist AMD64 wirklich die grosse Weiterentwicklung, der grosse architektonische Sprung? Mir persönlich gefällt da der IA64-Ansatz besser. Ich kann mir einfach nicht vorstellen, dass das ehrgeizige IA64-Projekt durch eine aufgebohrte 64-Bit Erweiterung von IA32 in einem Desktopprozessor torpediert werden soll. Die Annahme ist doch absurd.

Wär ja nicht das erste 64 Bit Abenteuer von Intel daß in der Versenkung verschwindet oder?
War da nicht mal was mit dem i860?

[BlackBirdSR]

Original geschrieben von Tigerchen

Wär ja nicht das erste 64 Bit Abenteuer von Intel daß in der Versenkung verschwindet oder?
War da nicht mal was mit dem i860?

das war meines Wissen nach, eine 32Bit CPU.

der i960 ebenso, allerdings auch eher eine embedded CPU als ein x86 Nachfolger, soweit ich das sehen kann.

[Demirug]

Original geschrieben von BlackBirdSR
das war meines Wissen nach, eine 32Bit CPU.

der i960 ebenso, allerdings auch eher eine embedded CPU als ein x86 Nachfolger, soweit ich das sehen kann.

Intel bezeichnete den i860 immer als 64Bit CPU. Die Datenbusse waren ja auch alle mindestens 64 Bit breit. Die ALU war aber wirklich nur eine 32 Bit Einheit.

i860 war als Workstation prozessor gedacht wurde dann aber eher in Supercomputer verbaut. Der i960 ist dann in den embedded Bereich abgerutscht.

[GloomY]

Original geschrieben von BlackBirdSR
muss Intel gar nicht. Anscheinend legt man einen Software Layer über das Ganze. Der x86 Code wird dann in Laufzeit in IA64 umgewandelt, der Itanium direkt mit optimiertem iA64 Code gefüttert.
Zumindest in der Theorie ;) Jep, das ist Theorie. Wie will man denn den erwähnten "optimierten" IA64 Code aus x86 Code erzeugen? Bei x86 überlässt der Compiler quasie dem Prozessor seine Optimierungen (d.h. Parallelität, Branch Prediction, OOO-E usw.). Diesen nicht oder wenig optimierten Code nun auf einer Hardware laufen zu lassen, welche sich komplett darauf verlässt, dass der Compiler ALLE Optimierungen macht (und diese z.B. bei Branches mittels Predication Bits sogar im Code festhält), kann ja nicht das Optimum darstellen.

Wie soll die Software, die die Umsetzung x86 -> IA64 Code macht, denn wissen, welche Bits z.B. für die Branch Prediction vorteilhaft sind, wenn diese Software nur den schon compilierten x86-Code analysiert und den eigentlichen Quellcode der Apllikation nicht kennt? Ein Compiler kann - dadurch dass er den Quellcode kennt - viel besser optimieren als eine Software, die nur den schon vorverdauten Code eines Compilers analysieren muss.

Dazu kommt natürlich auch noch, dass jede Übersetzung zur Laufzeit immer Zeit und Rechenleistung kostet (siehe Java). x86 ist einfach nicht für die Ausführung auf IA64 vorgesehen und selbst mit modernsten Optimierungen wird der Itanium bei x86 Code nie wirklich gut darstehen.

[Richthofen]

glaube auch nicht, dass der Itanium da besonders gut aussehen wird, zumal die x86 CPUs auch weiterhin schneller und besser werden wie der Itanium natürlich auch. Deswegen wird der Unterschied bei X86 Software bestehen bleiben und die bildet die große Masse an vorhandener Software weltweit.

Hinzu kommt, dass der Aufwand beim Itanium einfach in keinster Weise in einem gesunden Verhältnis zur erzielten Leistung steht. Um diesen riesen Die zu rechtfertigen, müsste das gute Stück den schnellsten X86 Prozessor bei X86 Software geradezu demontieren und das ist einfach nicht in Sicht.

Vor allem muss man sich die Unternehmen anschauen und die Softwarehersteller.
Die Zeit in der nur der Technik wegen irgendwas neues eingeführt wird sind eindeutig seit dem Platzen der .COM Blase vorbei. Nur was wirklich am Ende einen Mehrwert schafft, der sich in Mio von Dollarn niederschlägt wird sich durchsetzen. Diesen Trend wird auch Intel mit seinen 80% Marktanteil nicht ändern können. Vor 5 Jahren, als so gut wie keiner auf den wirklichen Mehrwert von IT-Neuerungen geschaut hat, hätte ich einem Modell wie dem des Itanium bzw. der IA64 Architektur durchaus Chancen eingeräumt. Heute würde ich das nicht mehr tun - zumindest nicht im X86 Bereich.
Es lohnt sich einfach nicht. X86 Software gewinnt dadurch nix und der Aufwand ist zu gross sowohl beim Chip selber als auch bzw. vor allem bei der Software. X86-64 ist einfach der smoothere Weg und der wird, sofern MS mitspielt und Intel in die Schranken weist - was ich hoffe, noch über einige Jahre maßgeblich sein.
Dort ist der Gewinn schnell zu realisieren und benötigt vergleichsweise wenig Aufwand. Die Unternehmen würden sich mit IA64 einen weiteren Standard ins Haus holen, der einfach inkompatibel zu den anderen ist. Das will einfach keiner, weils Geld kostet. Weniger wegen der Hardware, jedoch vielmehr wegen des Aufwandes bei der Softwareimplementierung und Integration der Architektur in die bestehende IT-Systemlandschaft eines Unternehmens.

Es macht einfach keinen Sinn, weswegen ich glaube, dass AMD mit x86-64 diesmal eindeutig den Wunsch des Kunden getroffen hat und würden die mehr Kapazitäten haben und die OEMs nicht so verlogene Arschkriecher sein, dann wäre die Diskussion IA64 oder X86-64 auf dem Desktop und Servermassenmarkt spätestens Ende 2004 erledigt.

Insofern bleibt die Hoffnung, dass IBM voll mit einsteigt und das MS standhaft bleibt und dafür sorgt dass Intel
A) auf X86-64 setzen muss
und
B) somit zwangsläufig auch Marktanteile verliert und die längste Zeit in der Position waren, wo NUR sie bestimmt haben was wie gemacht werden muss, was letztlich auch dazu führt, dass am Bedarf vorbei entschieden wird. Nur solange es eben keine ernsthafte Konkurenz gibt, muss der Kunde das fressen. Jetzt ist das aber nicht der Fall.

Also @IBM kommt in die Pushen und steigt in die Fertigung ein oder überlasst AMD die FAB :)

[BlackBirdSR]

Original geschrieben von GloomY
Jep, das ist Theorie. Wie will man denn den erwähnten "optimierten" IA64 Code aus x86 Code erzeugen? Bei x86 überlässt der Compiler quasie dem Prozessor seine Optimierungen (d.h. Parallelität, Branch Prediction, OOO-E usw.). Diesen nicht oder wenig optimierten Code nun auf einer Hardware laufen zu lassen, welche sich komplett darauf verlässt, dass der Compiler ALLE Optimierungen macht (und diese z.B. bei Branches mittels Predication Bits sogar im Code festhält), kann ja nicht das Optimum darstellen.

Wie soll die Software, die die Umsetzung x86 -> IA64 Code macht, denn wissen, welche Bits z.B. für die Branch Prediction vorteilhaft sind, wenn diese Software nur den schon compilierten x86-Code analysiert und den eigentlichen Quellcode der Apllikation nicht kennt? Ein Compiler kann - dadurch dass er den Quellcode kennt - viel besser optimieren als eine Software, die nur den schon vorverdauten Code eines Compilers analysieren muss.

Dazu kommt natürlich auch noch, dass jede Übersetzung zur Laufzeit immer Zeit und Rechenleistung kostet (siehe Java). x86 ist einfach nicht für die Ausführung auf IA64 vorgesehen und selbst mit modernsten Optimierungen wird der Itanium bei x86 Code nie wirklich gut darstehen.

was fragst du mich schon wieder Sachen von denen ich keine Ahnung habe ;)
Lassen wir uns überraschen, ob und wie Intel das abziehen will.

[Aqualon]

Original geschrieben von BlackBirdSR
Lassen wir uns überraschen, ob und wie Intel das abziehen will.

Wegen der für den Normalanwender doch eher geringen Vorteile von 64Bit, müssen sie fast zwangsläufig eine sehr schnelle 32Bit-Emulation mitliefern, damit die ältere Software weiterhin schnell läuft. Ok, bei über 400 Mio Transistoren die so ein Itanium 2 auf die Waage bringt, könnten sie auch locker nen kompletten 32Bit-Prozessor mit aufs Die packen, das macht die Kuh auch nicht mehr fett ;)

Aber ich bezweifle wirklich, dass so ein Transistor-Monster in den nächsten Jahren wirtschaftlich zu produzieren ist. Es wollen ja schließlich nicht nur Highend-Fetischisten bedient werden, die mal locker 700 Euro für nen Prozessor ausgeben.

Aqua

[BlackBirdSR]

Original geschrieben von Aqualon
Wegen der für den Normalanwender doch eher geringen Vorteile von 64Bit, müssen sie fast zwangsläufig eine sehr schnelle 32Bit-Emulation mitliefern, damit die ältere Software weiterhin schnell läuft. Ok, bei über 400 Mio Transistoren die so ein Itanium 2 auf die Waage bringt, könnten sie auch locker nen kompletten 32Bit-Prozessor mit aufs Die packen, das macht die Kuh auch nicht mehr fett ;)

Aber ich bezweifle wirklich, dass so ein Transistor-Monster in den nächsten Jahren wirtschaftlich zu produzieren ist. Es wollen ja schließlich nicht nur Highend-Fetischisten bedient werden, die mal locker 700 Euro für nen Prozessor ausgeben.

Aqua

ich denke nicht, dass es darum geht die IA64 jetzt schon in den Desktop Markt zu drücken...

[Muh-sagt-die-Kuh]

Original geschrieben von Richthofen
glaube auch nicht, dass der Itanium da besonders gut aussehen wird, zumal die x86 CPUs auch weiterhin schneller und besser werden wie der Itanium natürlich auch. Deswegen wird der Unterschied bei X86 Software bestehen bleiben und die bildet die große Masse an vorhandener Software weltweit.

Hinzu kommt, dass der Aufwand beim Itanium einfach in keinster Weise in einem gesunden Verhältnis zur erzielten Leistung steht. Um diesen riesen Die zu rechtfertigen, müsste das gute Stück den schnellsten X86 Prozessor bei X86 Software geradezu demontieren und das ist einfach nicht in Sicht.Du verlangst also, dass jede CPU mit einem großen DIE den schnellsten X86 Prozessor bei X86 Software schlägt....auch dann, wenn diese CPU auf einer komplett anderen ISA basiert...in anderen Worten: Du forderst hier praktisch, dass jede CPU mit einer anderen ISA x86-Code perfekt ausführen können muss....egal ob PPC, PA-RISC, Alpha oder sonstwas...hast du sonst noch irgendwelche überzogenen Vorderungen?

Vielleicht solltest du dir mal Gedanken darüber machen, dass x86 nicht in allen Sektoren der IT-Welt eine solche Rolle wie im Desktop-Geschäft spielt...Vor 5 Jahren, als so gut wie keiner auf den wirklichen Mehrwert von IT-Neuerungen geschaut hat, hätte ich einem Modell wie dem des Itanium bzw. der IA64 Architektur durchaus Chancen eingeräumt. Heute würde ich das nicht mehr tun - zumindest nicht im X86 Bereich.
Es lohnt sich einfach nicht. X86 Software gewinnt dadurch nix und der Aufwand ist zu gross sowohl beim Chip selber als auch bzw. vor allem bei der Software. X86-64 ist einfach der smoothere Weg und der wird, sofern MS mitspielt und Intel in die Schranken weist - was ich hoffe, noch über einige Jahre maßgeblich sein.IA-64 war von Anfang an nicht für den Desktop-Markt vorgesehen, deine Ausführungen sind somit rein spekulativ.
Dort ist der Gewinn schnell zu realisieren und benötigt vergleichsweise wenig Aufwand. Die Unternehmen würden sich mit IA64 einen weiteren Standard ins Haus holen, der einfach inkompatibel zu den anderen ist. Das will einfach keiner, weils Geld kostet. Weniger wegen der Hardware, jedoch vielmehr wegen des Aufwandes bei der Softwareimplementierung und Integration der Architektur in die bestehende IT-Systemlandschaft eines Unternehmens.Mit solchen Pauschalisierungen würde ich vorsichtiger sein...Es macht einfach keinen Sinn, weswegen ich glaube, dass AMD mit x86-64 diesmal eindeutig den Wunsch des Kunden getroffen hat und würden die mehr Kapazitäten haben und die OEMs nicht so verlogene Arschkriecher sein, dann wäre die Diskussion IA64 oder X86-64 auf dem Desktop und Servermassenmarkt spätestens Ende 2004 erledigt.Die Frage hat sich nie gestellt.

[Aqualon]

Original geschrieben von BlackBirdSR
ich denke nicht, dass es darum geht die IA64 jetzt schon in den Desktop Markt zu drücken...

Ich denke IA64 wird im Desktop-Markt nie eine wirkliche Chance haben.

Im Hochleistungsbereich wie Server oder Superrechner hat das Konzept bestimmt eine Chance, aber für den Desktop ist es einfach nicht ausgelegt worden und wird wohl auch nie dahingebracht werden können.

Aqua

[Muh-sagt-die-Kuh]

Original geschrieben von Aqualon
Ich denke IA64 wird im Desktop-Markt nie eine wirkliche Chance haben.

Im Hochleistungsbereich wie Server oder Superrechner hat das Konzept bestimmt eine Chance, aber für den Desktop ist es einfach nicht ausgelegt worden und wird wohl auch nie dahingebracht werden können.

Aqua Doch....nämlich dann wenn es genug Anwendungen gibt und man 2-6 MB Cache (am besten mit einem integrierten Speichercontroller) auf einer für Desktop-CPUs üblichen DIE-Größe unterbringen kann ;)

[Legolas]

Original geschrieben von Muh-sagt-die-Kuh
Doch....nämlich dann wenn es genug Anwendungen gibt und man 2-6 MB Cache (am besten mit einem integrierten Speichercontroller) auf einer für Desktop-CPUs üblichen DIE-Größe unterbringen kann ;)

Die Frage ist dann allerdings, wie z.B. ein auf AMD64 basierender Prozessor mit derselben Transistoranzahl im Vergleich zum Itanium performen wird.

[Aqualon]

Original geschrieben von Muh-sagt-die-Kuh
Doch....nämlich dann wenn es genug Anwendungen gibt und man 2-6 MB Cache (am besten mit einem integrierten Speichercontroller) auf einer für Desktop-CPUs üblichen DIE-Größe unterbringen kann ;)

Also wenn wir bei einem < 40nm Prozess angelangt sind? ;)

Aqua

[GloomY]

Original geschrieben von Muh-sagt-die-Kuh
Doch....nämlich dann wenn es genug Anwendungen gibt und man 2-6 MB Cache (am besten mit einem integrierten Speichercontroller) auf einer für Desktop-CPUs üblichen DIE-Größe unterbringen kann ;) Bis dahin steigen die Datenmengen, die üblicherweise Programme verwenden so weit an, dass 2 bis 6 MB Cache ganz normal ist. Die Itanium Architektur braucht aber mehr Cache als der Durchschnitt, das ist der Punkt.

Während bei einer "normalen" CPU mit OOO-E die Pipeline nicht vollständig steht, wenn ein Cache Miss stattfindet, ist das bei allen IA64 CPUs der Fall. Ein Hauptspeicherzugriff dauert 100 bis 150 Takte und während dieser Zeit macht die Pipeline nichts aber auch gar nichts.
Der Itanium wird immer größere Caches haben (müssen!), um nicht performancemäßig hinten zu liegen. Ich bin schon mal auf die Benchmarkergebnisse der Low-Watt Itaniums mit nur 1,5 MB L3 Cache gespannt...

btw: Die Codedichte ist bei IA64 schätzungsweise gerade mal ein Drittel derer von x86, also braucht man auch die dreifache Größe für den L1 Instruction Cache für den gleichen Inhalt...

[Richthofen]

@Muh-sagt-die-Kuh

Ich hab jetzt keine Lust dein ganzes Posting wieder auseinanderzunehmen.
Aber du hast mein Posting in einem völlig falschen Zusammenhang zerstückelt bzw. hast du anscheinend nicht gemerkt worüber wir die letzten 1,5 Seiten diskutiert haben und das ist die Chance von IA64 im Desktop Markt und generell im Massengeschäft auch bei Servern.

Und die ist schlicht und ergreifend 0 und warum das so ist habe ich oben hinreichend begründet.
In einer speziellen Marktniesche wo IA64 den Anforderungen genügt, kann die Architektur durchaus bestehen aber das wird eben immer der kleinste Teil bleiben.
80% der weltweiten Software dürfte X86 getrieben sein wenn nicht sogar noch mehr.
Überall dort wird der Itanium den Performancenachteil nicht ausgleichen können, da der Aufwand in keinem gesunden Verhältnis steht.
Es ist ja nicht so, dass heutige X86 CPUs sich nicht mehr steigern werden.
Im Gegenteil, sie profitieren von neuen Ideen und kleineren Prozessen ebenso nur muss der Itanium immer ein großes Stück mehr liefern als ein aktueller X86 Prozessor um dort überhaupt bestehen zu können und das wird keiner bezahlen.

Und darüber wurde weiter oben diskutiert und nicht über die Nieschenchancen der IA64 Architektur.
Dort wird er seine Berechtigung haben, es sei denn Intel lässt ihn irgendwann fallen.

Aber eine grosse Portierungswelle von X86 Software auf den IA64 Standard bzw. eine Neuprogrammierung wird im großen Stil nicht statt finden. X86 wird noch sehr sehr lange leben, weil so einen Unsinn niemand bezahlen will. Vor der .com Pleite hätte ich mir noch gut vorstellen können, dass dies einer bezahlt aber heute - no way.

[Tigerchen]

Original geschrieben von GloomY
Bis dahin steigen die Datenmengen, die üblicherweise Programme verwenden so weit an, dass 2 bis 6 MB Cache ganz normal ist. Die Itanium Architektur braucht aber mehr Cache als der Durchschnitt, das ist der Punkt.

Während bei einer "normalen" CPU mit OOO-E die Pipeline nicht vollständig steht, wenn ein Cache Miss stattfindet, ist das bei allen IA64 CPUs der Fall. Ein Hauptspeicherzugriff dauert 100 bis 150 Takte und während dieser Zeit macht die Pipeline nichts aber auch gar nichts.
Der Itanium wird immer größere Caches haben (müssen!), um nicht performancemäßig hinten zu liegen. Ich bin schon mal auf die Benchmarkergebnisse der Low-Watt Itaniums mit nur 1,5 MB L3 Cache gespannt...

btw: Die Codedichte ist bei IA64 schätzungsweise gerade mal ein Drittel derer von x86, also braucht man auch die dreifache Größe für den L1 Instruction Cache für den gleichen Inhalt...

Dann hoffen wir mal daß INTEL das Ding nicht in den Desktop drücken kann.Dürfte dort kaum für preiswerte Rechenknechte sorgen.

[Muh-sagt-die-Kuh]

Original geschrieben von GloomY
Bis dahin steigen die Datenmengen, die üblicherweise Programme verwenden so weit an, dass 2 bis 6 MB Cache ganz normal ist. Die Itanium Architektur braucht aber mehr Cache als der Durchschnitt, das ist der Punkt.

Während bei einer "normalen" CPU mit OOO-E die Pipeline nicht vollständig steht, wenn ein Cache Miss stattfindet, ist das bei allen IA64 CPUs der Fall. Ein Hauptspeicherzugriff dauert 100 bis 150 Takte und während dieser Zeit macht die Pipeline nichts aber auch gar nichts.
Der Itanium wird immer größere Caches haben (müssen!), um nicht performancemäßig hinten zu liegen. Ich bin schon mal auf die Benchmarkergebnisse der Low-Watt Itaniums mit nur 1,5 MB L3 Cache gespannt...

btw: Die Codedichte ist bei IA64 schätzungsweise gerade mal ein Drittel derer von x86, also braucht man auch die dreifache Größe für den L1 Instruction Cache für den gleichen Inhalt... Das brauchst du mir nicht alles zu erzählen, das weiss ich selbst ;)

Was diese Architektur wirklich braucht, ist ein integrierter Speichercontroller, die geringeren Latenzen bringen einem in-Order Design noch deutlich mehr als einem out-of-Order Design.

Was die Benchmarkergebnisse der Low-Watt Itaniums angeht...schnapp dir einfach die SPEC Resultate von 900 mhz Itanium 2 CPUs mit 1,5 MB L3 und leg noch ein bischen drauf.

[Muh-sagt-die-Kuh]

Original geschrieben von Richthofen
@Muh-sagt-die-Kuh

Ich hab jetzt keine Lust dein ganzes Posting wieder auseinanderzunehmen.
Aber du hast mein Posting in einem völlig falschen Zusammenhang zerstückelt bzw. hast du anscheinend nicht gemerkt worüber wir die letzten 1,5 Seiten diskutiert haben und das ist die Chance von IA64 im Desktop Markt und generell im Massengeschäft auch bei Servern.

Und die ist schlicht und ergreifend 0 und warum das so ist habe ich oben hinreichend begründet.Im Moment mag das stimmenX86 wird noch sehr sehr lange leben, weil so einen Unsinn niemand bezahlen will. Vor der .com Pleite hätte ich mir noch gut vorstellen können, dass dies einer bezahlt aber heute - no way. Wir werden sehen ;)

[Endorphine]

IA64 bringt für die Zukunft auf jeden Fall mehr als AMD64. Ich denke das bestreitet niemand. Die Frage ist nur, ob sich die Geschichte wiederholen wird und IA64 nur ein weiterer i860/i960 werden wird. Das wäre IMHO sehr schade.

IA64 ist IMHO überhaupt der einzig sinnvolle Ansatz, die immer weiter steigende interne Parallelisierung in der CPU sinnvoll auszulasten. IA64 passt perfekt in das Konzept, in Zukunft zusammen mit SMT dann SMP-on-die zu verwirklichen.

[del_4901]

IA64 wird niemals im Desktopmarkt aufschlagen, nicht umsonnst hat Intel AMD64 gegen ISSE2 getauscht. Ausserdem legt der Destopmarkt (insbesondere x86) Wert auf abwärtskompatibilität, die is mit IA64 nicht mehr gegeben.
Ausserdem streubt sich Microsoft bestimmt wieder dagegen, wenn se nicht AMD64 einsetzen. ergo bleibt alles vorerst beim alten, solange die NEXGEN Architektur noch skalierbar is, sowieso.

[Endorphine]

Original geschrieben von AlphaTier
IA64 wird niemals im Desktopmarkt aufschlagen, nicht umsonnst hat Intel AMD64 gegen ISSE2 getauscht. Ausserdem legt der Destopmarkt (insbesondere x86) Wert auf abwärtskompatibilität, die is mit IA64 nicht mehr gegeben.
Ausserdem streubt sich Microsoft bestimmt wieder dagegen, wenn se nicht AMD64 einsetzen. ergo bleibt alles vorerst beim alten, solange die NEXGEN Architektur noch skalierbar is, sowieso. http://www.neochaos.de/forumemo/bullshit.jpg

[Muh-sagt-die-Kuh]

Original geschrieben von Endorphine
http://www.neochaos.de/forumemo/bullshit.jpg Hart, aber treffend :D

[GloomY]

Original geschrieben von Muh-sagt-die-Kuh
Das brauchst du mir nicht alles zu erzählen, das weiss ich selbst ;)Hmm, der eine beklagt sich, dass ich ihn Sachen fragen würde, von denen er keine Ahnung habe und du... naja egal. ;)

Ich habe obiges geschrieben, um zu zeigen, dass IA64 sich sicher nicht in den Desktop verirren wird. Caches sind teuer und im Desktop Bereich wird viel mehr auf den Preis geachtet als bei den Servern/HPC.
Original geschrieben von Muh-sagt-die-Kuh
Was diese Architektur wirklich braucht, ist ein integrierter Speichercontroller, die geringeren Latenzen bringen einem in-Order Design noch deutlich mehr als einem out-of-Order Design.Jep.
Original geschrieben von Muh-sagt-die-Kuh
Was die Benchmarkergebnisse der Low-Watt Itaniums angeht...schnapp dir einfach die SPEC Resultate von 900 mhz Itanium 2 CPUs mit 1,5 MB L3 und leg noch ein bischen drauf. Ja, dann mach' ich mich mal auf die Suche...

@Endorphine: Bezüglich deiner Sympathie gegenüber IA64: Du sprichst von Vorteilen, aber bist du dir auch über die Nachteile bewusst? Kannst du in etwa abschätzen, ob Vor- oder Nachteil überwiegt? Imho eher letzteres, auch wenn ich den IA64 Ansatz natürlich technisch interessant finde.

[del_4901]

Was bringt bitteschön die schnellste technik, wenn Sie sich nicht verkaufen lässt? Bzw. wenn die Kosten/Nutzen Rechnung nicht aufgeht. So dumm ist nichtmal Intel. Nur Microsoft kriegt das hin (siehe XBOX). IA64 hat im Desktopmarkt nichts zu suchen solange die Software für den Anwender nicht attraktiv ist. Und die Softwarebuden entwickeln nicht für einen Desktop-IA64 solange sich das Teil nicht verbreitet hat. AMD ist da mit AMD64 besser dran, die verkaufen ihren Athlon64, weil er auch unter 32bit noch schnell ist, irgendwann hat AMD64 einen Großteil des Marktes erobert, und DANN kommt erst die Software! Intel wird solange warten, und dann die AMD64 Erweiterung in ihren Pentiums freischalten. Die Lizenz dazu ist vorhanden, ausserdem währ das wirtschaftlich gesehen, der klügste Schachzug.

[Endorphine]

Original geschrieben von AlphaTier
[...]
http://www.neochaos.de/forumemo/deargod_stop.jpg

:eyes:

[del_4901]

Hast du noch ander Lustige Bildchen auf Lager? *gähn* Anstatt mal was Sachlich beizusteuern, oder Sachlich zu wiederlegen.

[del_4901]

Original geschrieben von Endorphine
[...]

:eyes:

http://www.neochaos.de/forumemo/gehspielen.jpg

[Demirug]

Jungs, die Bilder mögen ja ganz nett sein aber das hier ist keine Galerie. Also bitte. Danke

[BlackBirdSR]

Original geschrieben von GloomY
Hmm, der eine beklagt sich, dass ich ihn Sachen fragen würde, von denen er keine Ahnung habe und du... naja egal. ;)


Nimms nicht so ernst,
in Sachen IA6 finde ich die meisten Diskussionen einfach sinnlos, da sehr viel einfach noch offen ist.

IA64 ist sicherlich nicht der heilige Gral, und es gibt eine Menge Nachteile. Aber wenn es denn wirklich mal so weit kommen sollte, kann man sich auch nicht davor verschließen.

Deshalb hab ich einfach keine Ahnung von der Sache.. das artet am Schluss nur in persönlichen Preferenzen und Bildern :D aus.
Diesen IA64 Diskussionen geht man besser aus dem Weg.. die sind Giftig:bäh:

[del_4901]

Original geschrieben von BlackBirdSR
Nimms nicht so ernst,
in Sachen IA6 finde ich die meisten Diskussionen einfach sinnlos, da sehr viel einfach noch offen ist.

IA64 ist sicherlich nicht der heilige Gral, und es gibt eine Menge Nachteile. Aber wenn es denn wirklich mal so weit kommen sollte, kann man sich auch nicht davor verschließen.

Deshalb hab ich einfach keine Ahnung von der Sache.. das artet am Schluss nur in persönlichen Preferenzen und Bildern :D aus.
Diesen IA64 Diskussionen geht man besser aus dem Weg.. die sind Giftig:bäh:

Der Itanium is ja auch verdammt schnell, ich hätte gern einen als Numbercruncher, wenn ich die Kohle hätte. Aber ich würde wenn Intel nen IS64-Desktop ankündigt, keine Aktien und schon gar nicht Optionsscheine kaufen, weil die Sache echt heikel is. Obwohl man bei Intel Aktien nicht viel falsch machen kann.

[BlackBirdSR]

Original geschrieben von AlphaTier
Der Itanium is ja auch verdammt schnell, ich hätte gern einen als Numbercruncher, wenn ich die Kohle hätte. Aber ich würde wenn Intel nen IS64-Desktop ankündigt, keine Aktien und schon gar nicht Optionsscheine kaufen, weil die Sache echt heikel is. Obwohl man bei Intel Aktien nicht viel falsch machen kann.

Numbercruncher?

ich will nur 2 Spiele Ports für IA64.. und wenns nur Dedicated Server sind :D

Aber für BF1942 + Bots kann man nie genug Rechenleistung haben, und die passende CPU für Battlezone2 muss auch noch entwickelt werden ;)

Ist nur die Frage, ob man auf IA64 so richtig Spielen kann. Ich glaube nicht unbedingt dass die Architektur da voll zum Tragen kommt.

[del_4901]

Original geschrieben von BlackBirdSR
Numbercruncher?



Ne Maschine wo man schnell/parallel wissenschaftliche Rechnungen ausführen kann. Sowas wie Seti z.B.

Oder auch für's Offline-Rendern währ das Ding zu gebrauchen.

Für'n Battlefielddedicated währs natürlich auch geil. Aber ich glaube kaum das das jehmals laufen wird. ;( Ich träume bestimmt diese Nacht von nem Battlefieldserver mit 2000 Bots ;)

[zeckensack]

Original geschrieben von Endorphine
IA64 bringt für die Zukunft auf jeden Fall mehr als AMD64. Ich denke das bestreitet niemand.Doch. Ich :)
Die Frage ist nur, ob sich die Geschichte wiederholen wird und IA64 nur ein weiterer i860/i960 werden wird. Das wäre IMHO sehr schade.

IA64 ist IMHO überhaupt der einzig sinnvolle Ansatz, die immer weiter steigende interne Parallelisierung in der CPU sinnvoll auszulasten. IA64 passt perfekt in das Konzept, in Zukunft zusammen mit SMT dann SMP-on-die zu verwirklichen. Prozessoren ohne OOOE sind eigentlich längst tot. OOOE ist außerdem eine Voraussetzung für SMT.

Ich habe Schwierigkeiten, in IA64 den "einzig [...] sinnvolle[n] Ansatz" zu sehen, wo doch so viele andere sinnvolle Ansätze auf dem Tisch liegen. Sei's traditionell OOO-Post-RISC (Power 4), dito mit Code-Kompression (K7/K8), oder massiv Multithreaded (Sun's Sparc-Pläne).

Und der letzte Satz verschließt sich mir völlig :|
Zu SMT habe ich bereits etwas gesagt, und SMP on die lässt sich nun wirklich mit jeder Kernarchitektur implementieren.

[del_4901]

Naja, Zecke, IA-64 hat schon seine Berechtigung, nämlich bei Servern und Mainframes, vielleicht noch Workstations(wobei ich bei letzteren den Opteron vorziehen würde). Bei den Desktops und Workstations ist sicherlich AMD64 das Maß aller Dinge im mom.

[zeckensack]

Original geschrieben von Muh-sagt-die-Kuh
Du verlangst also, dass jede CPU mit einem großen DIE den schnellsten X86 Prozessor bei X86 Software schlägt....auch dann, wenn diese CPU auf einer komplett anderen ISA basiert...in anderen Worten: Du forderst hier praktisch, dass jede CPU mit einer anderen ISA x86-Code perfekt ausführen können muss....egal ob PPC, PA-RISC, Alpha oder sonstwas...hast du sonst noch irgendwelche überzogenen Vorderungen?

Vielleicht solltest du dir mal Gedanken darüber machen, dass x86 nicht in allen Sektoren der IT-Welt eine solche Rolle wie im Desktop-Geschäft spielt...Richtig. Es gibt Märkte in denen Code mal eben schnell neu kompiliert werden kann (oder sowieso in house geschrieben wird). Primär wissenschaftliche Anwendungen. Und es gibt auch die Fälle, in denen man vom Hersteller mit den passenden binaries gefüttert wird.

Der Punkt ist nun aber folgender: für sowas braucht man nicht zwingend IA64. Wenn man in Sachen ISA flexibel ist, dann kann man sich frei aussuchen, welchen Prozessor man nimmt. Dann konkurriert IA64 eben doch mit dem K8, und auch mit dem Power 4 und wie sie alle heißen. Das ist ein Kampf, den IA64 wirtschaftlich nicht gewinnen kann (ganz einfacher Grund: die size).

Der K8 kann nun zusätzlich x86-Code (schnell!) ausführen.
Dh:
K8 wildert im Revier von IA64, Power 4, etc
&&
IA64, Power 4, etc, wildern nicht im Revier des K8

IA-64 war von Anfang an nicht für den Desktop-Markt vorgesehen, deine Ausführungen sind somit rein spekulativ.Für welchen Markt ist IA64 überhaupt gedacht? Offiziell "für Server", klar.
Offiziell ist auch der Gallatin "für Server", und gleichzeitig an anderer Stelle "für Spieler", und im Mobil-Segment der P4-M "speziell für Notebooks" (ältere Fernsehwerbung von Intel). Der offiziellen Marktsegmentierung würde ich nicht mal so weit trauen, wie ich meinen Schreibtisch werfen kann :)

VLIW ist eine gute* Lösung für "Multimedia" (aka Workstation aka Streaming, Codecs, etc).
Wie definiert sich denn eine gute* Server-CPU? IMO ganz anders ...

*gut im Sinne von hoher Leistung (bei gesetztem Transistor-Budget und anderen Rahmenbedingungen)

[del_4901]

Original geschrieben von zeckensack
Richtig. Es gibt Märkte in denen Code mal eben schnell neu kompiliert werden kann (oder sowieso in house geschrieben wird). Primär wissenschaftliche Anwendungen. Und es gibt auch die Fälle, in denen man vom Hersteller mit den passenden binaries gefüttert wird.

Der Punkt ist nun aber folgender: für sowas braucht man nicht zwingend IA64. Wenn man in Sachen ISA flexibel ist, dann kann man sich frei aussuchen, welchen Prozessor man nimmt. Dann konkurriert IA64 eben doch mit dem K8, und auch mit dem Power 4 und wie sie alle heißen. Das ist ein Kampf, den IA64 wirtschaftlich nicht gewinnen kann (ganz einfacher Grund: die size).

Der K8 kann nun zusätzlich x86-Code (schnell!) ausführen.
Dh:
K8 wildert im Revier von IA64, Power 4, etc
&&
IA64, Power 4, etc, wildern nicht im Revier des K8

Für welchen Markt ist IA64 überhaupt gedacht? Offiziell "für Server", klar.
Offiziell ist auch der Gallatin "für Server", und gleichzeitig an anderer Stelle "für Spieler", und im Mobil-Segment der P4-M "speziell für Notebooks" (ältere Fernsehwerbung von Intel). Der offiziellen Marktsegmentierung würde ich nicht mal so weit trauen, wie ich meinen Schreibtisch werfen kann :)

VLIW ist eine gute* Lösung für "Multimedia" (aka Workstation aka Streaming, Codecs, etc).
Wie definiert sich denn eine gute* Server-CPU? IMO ganz anders ...

*gut im Sinne von hoher Leistung (bei gesetztem Transistor-Budget und anderen Rahmenbedingungen)

Der K8 wildert zwar im Revier von Sun, Intel, IBM etc. aber eins darf man dabei nicht vergessen. In dem Segment kommt es darauf an das die Hardware Stabil, und am besten noch 100Jahre am Stück läuft. Deswegen sind in dem Segment Grantien, von mehreren Jahrzehnten keine Seltenheit. Für Intel, Sun, IBM ist es kein Problem auf eine CPU 50 Jahre Garantie zu geben, bei deren Marktkapitalisierung sind das Peanuts wenn 10% der CPUs die Garantiespanne nicht überleben. AMD hingegen kann es sich nicht leisten solche lange Garantiezeiten zu gewährleisten, denn wenn dann doch mal was kaputt geht sind die ganz schnell wieder aus der Gewinnzohne raus. Und das würde AMD auf längere Sicht nicht überleben.

[KM]

Zuerst bringt Intel den Prescott mal raus.
Danach gibt es für Intel nach meiner Meinung zwei Möglichkeiten:
- Intel wird kompatibel zur AMDs 64bit Plattform, was ich bei der Arroganz (ist etwas hart, aber trifft teilweise zu) und Intels Größe eher bezweifle (hoffe schon :))
- oder Intel hat aus der Miesere von IA64 gelernt und entwickelt einen Prozessor, der sowohl zur IA64 als auch zur IA32 Plattform kompatibel ist. Das bedeutet aber nicht, dass der Prozessor an die Performance von einem richtigem Itanium rankommen muss. Hauptsache er ist zuer IA64 kompatibel und schnell wie die IA32 Plattform, denn das zählt dem Massenmarkt eher. Dann wäre AMDs 64bit Plattform im Massenmarkt eine Todgeburt (hoffe nicht :()
Die nächste Zeit wird spannend, da sie die Zukunft des nächsten Jahrzehnts festlegt.

[Gast]

Original geschrieben von Endorphine
http://www.neochaos.de/forumemo/deargod_stop.jpg

:eyes: und du schimpfst Leute amd Fanatiker dann bist du wohl ein intel fetischiest :)

Aber HP hat intel für ihren Unsinn schon damals den rücken gekehrt und ihre eigene 64 Bit (PA-RISK/Alpha EV7) Linie zur Sicherheit parallel weite geführt! Alpha würde wiederum von intel aufgekauft hmm und amd hat doch mal son blödes Busprotokoll von denen lizensiert.

Da die HW Industrie und Software Industrie seit ein paar Jahren ums überleben kämpfen müssen kann man logisch betrachtet IA 64 komplett abhacken!

Ach die expensive Edition ist natürlich auch keine Kurzschluß Reaktion wie mit dem 1 GHz p3 damals!

[Muh-sagt-die-Kuh]

Original geschrieben von Gast
Ach die expensive Edition ist natürlich auch keine Kurzschluß Reaktion wie mit dem 1 GHz p3 damals! P4EE ist ohne Zweifel eine kurzfristige Reaktion auf den A64FX.

Meiner Meinung nach ist es aber ein kluger Schritt ohne jeglichen Entwicklungsaufwand...teilweise defekte Gallatin-MP Cores verkauft Intel schon seit ein paar Monaten im So478 Gehäuse als ganz normale P4er.

[Gast]

Original geschrieben von Muh-sagt-die-Kuh
P4EE ist ohne Zweifel eine kurzfristige Reaktion auf den A64FX.

Meiner Meinung nach ist es aber ein kluger Schritt ohne jeglichen Entwicklungsaufwand...teilweise defekte Gallatin-MP Cores verkauft Intel schon seit ein paar Monaten im So478 Gehäuse als ganz normale P4er.
Clever ist das auf jedenfall!
Kennen wir ja schon vom Sellerie

[GloomY]

Original geschrieben von BlackBirdSR
Nimms nicht so ernst,
in Sachen IA6 finde ich die meisten Diskussionen einfach sinnlos, da sehr viel einfach noch offen ist.
[...]
Diesen IA64 Diskussionen geht man besser aus dem Weg.. die sind Giftig:bäh: Achwas. Die Vor- und Nachteile kann man ja diskutieren. Man darf sich dabei nur nicht die Köpfe einschlagen. Wenn man sachlich darüber redet, sehe ich darin kein Problem.
Original geschrieben von zeckensack
Doch. Ich :)Ich ebenpfalz ;)
Original geschrieben von zeckensack
OOOE ist außerdem eine Voraussetzung für SMT.:O
Warum das denn? Wenn das wahr ist, dann ist IA64 mit großer Sicherheit eine Sackgasse. Dann kann man mit IA64 ja ausschliesslich ILP optimieren (neben der eher uneffizienten TLP Optimierung mittels SMP). Die Zukunft geht aber mit großer Sicherheit in beide Richtungen, also ILP mit kombiniertem TLP.

http://www.realworldtech.com/includes/images/articles/EV8-part3-fig3.gif

edit: Die Frage ist auch, wie viele ungenutzte Ausführungseinheiten die CPUs der IA64 Architektur besitzen, wenn a) ihr ILP durch das EPIC Konzept maximiert wurde und b) die Ausführungseinheiten sowieso schon durch dadurch "verstopft" werden, dass bei jeder Programmverzweigung beide Wege gegangen werden, bis das Ergebnis der Verzweigung bekannt ist.

[zeckensack]

Original geschrieben von GloomY
:O
Warum das denn?Ich muß zugeben, daß das nicht sauber von mir war. Ich habe nochmal drüber gegrübelt, und muß dieses Statement zurückziehen.

Für SMT braucht man
a)ein zweites (drittes, viertes, etc) register file
b)einen 'Demultiplexer hinter dem Decoder', der eben die Ops aus mehreren Threads, zusammen mit einer Referenz auf das jeweils aktuelle Regfile oä, in die issue ports schiebt.
c)Zweimal alles das, was für Fetch, Segmentierung und Speicherschutz benötigt wird. Bei x86 sind das EIP und die diversen descriptor tables. MMU ahoi.

Das sind nicht wirklich die gleichen Voraussetzungen wie für OOOE. Wen mehrere Threads in order durch die Pipeline gejagt werden, dann kann man sich das Zurücksortieren in die Programmreihenfolge (am Ende der Pipeline) sparen.

Soviel dazu. Ein Satz zu dem ich momentan noch ganz gut stehen kann, wäre folgender:
Von OOOE aus implementiert sich SMT am leichtesten.

a)lässt sich durch das rename register file lösen, wenn dieses groß genug ist.
b)sowieso. Die Zielregister müssen auch für OOOE schon penibel festgelegt werden, da ist SMT kein Aufwand mehr.
c)ist der eigentliche Aufwand

[BlackBirdSR]

naja.. bei x86 ist SMT ja insofern sinnvoll, da die CPU Funktionseinheiten eh meistens nur mit warten beschäftigt sind.

Bei IA64 kann ich mir vorstellen, dass durch die strikte Compilerabhängigkeit das etwas besser läuft.
SMT mit sagen wir 4 Threads, wäre dann ohne OOOE, ebenso auf eine strikte optimierung durch den Compiler gerichtet.. oder nicht?

Naja, SUN bekommts demnächst ja auch irgendwie hin.

[GloomY]

Ja, leichter ist es allemal. EPIC und SMT zu vereinen dürfte einige Schwierigkeiten machen. Ein paar Gedanken meinerseits:

Die feste Reihenfolge der Instruktionen ist eher weniger das Problem. Vielmehr stört die Tatsache, dass die Befehle zu parallelisierbaren Befehls-Bündeln zusammengefasst sind. EPIC packt die Befehle in Befehls-Tripel mit 128 Bit Länge (wobei komischweise nur ein FP Befehl hinein darf). Jeder Befehl wird mit 41 Bit kodiert. Die restlichen 5 Bit sind Information über die Parallelisierbarkeit mit dem nächsten Tripel und die Vorhersage des Compilers bei Sprüngen.
Mehrere Tripel werden dann zu den erwähnten Befehls-Bündeln zusammengefasst, welche parallel in einem Takt ausgeführt werden können (besser: in die Pipelines hineinkommen).

Wenn man nun aber mehrere Threads gleichzeitig ausführen will, so gibt es zwei Möglichkeiten: Die erste und angenehme ist die, dass die Summe der Anzahl der Befehle der beiden Threads für einen bestimmten Takt die Anzahl der Ausführungseinheiten nicht überschreitet. Dann können die Befehls-Bündel der beiden Threads gleichzeitig und ohne Probleme ausgeführt werden. Die zweite Möglichkeit ist eben, dass es zusammen mehr als die zur Verfügung stehenden Ausführungseinheiten sind. Dann muss man - zumindest bei einem Thread - diese Befehls-Bündel wieder so aufteilen, dass der Rest des Bündels im nächsten Takt ausgeführt wird.

Zum einen macht das die Vorsortierung der Bündel für den zweiten Thread unsinnig, zum andern ist das für Threadwechsel gefährlich. Soviel ich weiss, kann prinzipiell zu jedem Zeitpunkt ein Threadwechsel stattfinden, also auch wenn obiges Szenario gerade stattfindet. Hier reicht es nun nicht aus, einfach den Befehlszeiger zu sichern, da es durchaus sein kann, dass ein Befehl eines Befehls-Tripels schon ausgeführt ist, die restlichen zwei aber noch nicht. Der Befehlszeiger zeigt ja immer auf das nächste Befehlstripel und nicht auf den nächsten abzuarbeitenden Befehl, denn bei der normalen byte-weisen Adressierung des Hauptspeichers kann man ja nicht auf Speicherorte zeigen, die 41 Bit auseinander liegen.

Diese teilweise Abarbeitung müsste bei einem Threadwechsel auch mit abgespeichert werden, was wieder den den Hardwareaufwand vergrößern würde. Ein Ziel von EPIC war es aber auch, dass die Komplexität der OOO-E Chips (Scheduler, Re-Order Buffer usw.) unterboten wird. Damit würde man sich aber auch wieder in diese Richtung bewegen.

EPIC und SMT zu vereinen ist technisch sicher nicht unmöglich, würde aber einen ziemlich großen Aufwand bedeuten und zwar sowohl für dir Entwicklung als auch für die zu realisiernden Hardware-Schaltungen.

[KM]

Es gibt auch andere Möglichkeiten.
z.B. kommt mir die PACT’s Extreme Processing Platform (XPP™) in den Sinn.
Siehe: http://www.pactcorp.com/xneu/px_xpphw.html
http://www.pactcorp.com/xneu/px_paper.html
Ein Prozessor mit einem Array von ALUs. Für einen normalen Prozessor ist es ungewöhnlich, aber es gibt eine Menge Anwendungen, die von massiv parallelen ALUs profitieren könnten, z.B. MPEG4 in Echtzeit encoden, bei Handys mehrere Einheiten zusammenfassen.

[Aqualon]

Mal ne Zwischenfrage: Was bedeuten denn OOOE? Hab da nicht wirklich was brauchbares gefunden.

Aqua

[KM]

@Aqualon
oooe=out-of-order-execution
http://www.fh-augsburg.de/informatik/projekte/emiel/casa/casa/kapitel/kapitel07/07_04_003.htm

Edit
Lernprogramm für Rechnerarchitektur
http://www.fh-augsburg.de/informatik/projekte/emiel/casa

http://galway.informatik.uni-kl.de/courses/ws01-02/Proseminar/Pipe2/Pipe2.html

[Tigerchen]

Mal ne andere Zwischenfrage.
Ist das Sichern der vielen Register nicht viel zeitintensiver beim Itanium?
Ist dies nicht ein ziemlicher Nachteil wenn man das Ding für Desktop-PC's nutzt?

[GloomY]

Original geschrieben von Tigerchen
Mal ne andere Zwischenfrage.
Ist das Sichern der vielen Register nicht viel zeitintensiver beim Itanium?
Ist dies nicht ein ziemlicher Nachteil wenn man das Ding für Desktop-PC's nutzt?Das dauert bei mehr Registern schon etwas länger, das ist korrekt. Imho ist das eigentlich kritische aber die Cacheinhalte, die natürlich direkt nach dem Wechsel noch gar keine Daten des neuen Threads beinhalten. Das ist natürlich viel kritischer für die Performance als die paar Bytes für die Register. Daher sollte das kaum Unterschiede machen.

Übrigends sind meine obigen Überlegungen/Bedenken falsch, da die Bündel nicht auf Ausführung in einem Takt vom Compiler erzeugt werden sondern generell auf maximale Parallelität. Sonst müsste man ja allen IA64 Binärcode neu compilieren, wenn man z.B. vom Merecd mit 4 Int Units auf McKinley oder Madison mit ihren 6 Int Units umsteigt.

edit: Frisch aus einer HP Präsentation vom September 2003:
http://berg.heim.at/zermatt/441542/misc/HP_Itanium.gif
Wer findet die meisten Fehler? *g*

So viel wie dort drin sind, kann ja fast schon kein Zufall mehr sein...

[Gast]

Beim opteron sind die l1 angaben falsch der hat doch immer noch 64/64 128 kb

[GloomY]

Original geschrieben von Gast
Beim opteron sind die l1 angaben falsch der hat doch immer noch 64/64 128 kb Korrekt, das ist wohl das, was einem am schnellsten ins Auge springt. Aber es gibt noch andere Fehler. Gerade beim Power4 ...

[Gast]

Power4 L1 64 kb inst cache
L2 1,5 mb shared l2 caches
32 MB of chip l3 cache 10 Gb banbreite

[KM]

@GloomY
Bei solchen Präsentationen kommen öfters "Fehler" vor. Mal will ja irgendwie die Hardware schmackhaft machen.
Am Ende ist es doch wichtig, was rauskommt.

[GloomY]

Original geschrieben von Gast
Power4 L1 64 kb inst cache
L2 1,5 mb shared l2 cachesJep, die Größe von L1 D- und I-Cache sind vertauscht.
Original geschrieben von Gast
32 MB of chip l3 cache 10 Gb banbreiteDas ist die eigentliche Frechheit, dort "N/A" hinzuschreiben.

Und wenn man ganz genau ist, so stimmt die L2 Angabe bei der USIII auch nicht: Nur die Daten des L2 Caches liegen off-die. Die Tags und Control Logic sind on-die.

Und was die Register angeht: Beim Opteron komme ich bei 32 Bit auf 8 GPRs, 8 FP/MMX und 8 SSE Register, also 24 insgesamt und unter 64 Bit auf 40 Register (16 GPR, 8 FP/MMX, 16 SSE). Und ähnlich wie auch beim Power4 sind das ja nur die direkt ansprechbaren Register. Insgesamt gibt es ja weitaus mehr.

Sorry, wenn ich diesen Thread etwas missbraucht habe, aber wir waren ja sowieso schon absolut OT.
Original geschrieben von KM
@GloomY
Bei solchen Präsentationen kommen öfters "Fehler" vor. Mal will ja irgendwie die Hardware schmackhaft machen.
Am Ende ist es doch wichtig, was rauskommt. Sorry, aber bei der Wahrheit sollte man dann trotzdem bleiben. Ist schon komisch, dass ausgerechnet der L3 Cache beim Power4 fehlt, wo beim Itanium immer so stolz die 6MB L3 präsentiert werden...