Intel bestätigt 64Bit für Desktop [Archiv]

Stone2001

2004-01-30, 15:17:11

Original geschrieben von Tiamat
Ich hoffe immer noch das es IA64 sein wird :)
hmm, wäre sicherlich nicht schlecht und durchaus nicht unwahrscheinlich, zumal es ja eine IA32 Execution Layer, zumindest für Windows, gibt, die die x86er Befehle von Windows und Co ins EPIC-Format umwandelt.
Was aber, zumindest für mich, dagegen spricht, sind die zu geringen Taktraten, der aktuellen IA64 Prozessoren. Entweder kommt eine hochgezüchtete Varinate eines Itanium (möglich), eine neuer Prozessor (unwahrscheinlich) und Intels Marketungabteilung bekommt schon wieder ein riesiges Problem (am wahrscheinlichsten).

Was aber auch noch möglich ist, ist, das das was lange als Yamhill umherging, doch letztenendes doch auf den Markt kommt. Wobei ich dann davon ausgehe, das AMD64 verwendet wird. Gegen eine Eigententwicklung spricht die Aussage von Microsoft, kein weiteres Windows für 64 bit Architekturen herausbringen zu wollen.

reunion

2004-01-30, 15:52:46

Original geschrieben von Tiamat
Ich hoffe immer noch das es IA64 sein wird :)

1.) Würde IA64 mit den im Vergleich zum Itanium kleinen Cache von nur 1MB ziemlich lahm sein.

2.)Hat M$ gesagt man entwickelt kein weiters 64-bit OS. Somit muss Intel kompatibel zu AMD64 sein und was liegt da näher als AMD64 auch zu verwendenm ;)

Stone2001

2004-01-30, 16:00:26

Original geschrieben von reunion
1.) Würde IA64 mit den im Vergleich zum Itanium kleinen Cache von nur 1MB ziemlich lahm sein.

uhh! IA64 ist eine Architektur und der Itanium ist ein Prozessor, die zwei vergleichen zu wollen entspricht einem Äpfel - Birnen -Vergleich. ;)
Und das ein Itanium mit kleinerem Cache langsamer ist, als einer mit größerem Cache sein dürfte, dürfte wohl klar sein.

Endorphine

2004-01-30, 16:12:59

Original geschrieben von reunion
Hat M$ gesagt man entwickelt kein weiters 64-bit OS. Somit muss Intel kompatibel zu AMD64 sein und was liegt da näher als AMD64 auch zu verwendenm ;) Damit meint Microsoft, dass sie Windows nicht auf einen dritten IA32-Nachfolger portieren werden. Windows 64-Bit Edition für IA64 existiert bereits, die Variante für AMD64 befindet sich in der Betaphase.

Edit: Deshalb ist Intel mitnichten gezwungen, AMD64 zu implementieren. Ich spekuliere übrigens immer noch auf IA64. Alles andere wäre wirtschaftlicher Wahnsinn aus Sicht von Intel und gleichzeitig ist es (noch) nicht notwendig, da AMD64 noch in den Kinderschuhen steckt. Ich denke es wird auf low-power Versionen des Itanium hinauslaufen. Vielleicht auch etwas anderes/neues. AMD64 kann ich mir beim besten Willen nicht vorstellen. Das Interview zeigt imho nur, dass Intel endlich aufgewacht ist und AMD64 ernst nimmt. Welchen Weg sie nun beschreiten werden wird die Zeit zeigen. Ich denke jedoch, dass Intel jetzt mit aller Macht IA64 vorantreiben wird. Da scheinbar derzeit die Entscheidung gefällt wurde und noch kein Zwang zum AMD64-Support besteht wird Intel IA64 irgendwie in den Massenmarkt bringen.

Mal sehen, was Intel tun wird.

Bokill

2004-01-30, 16:44:06

@Stone2001

Äpfel und Birnen

Hier werden keine Äpfel mit Birnen verglichen

Original geschrieben von reunion
1.) Würde IA64 mit den im Vergleich zum Itanium kleinen Cache von nur 1MB ziemlich lahm sein.

Is zwar etwas krumm formuliert, denn es ging um die KonsumerCPU von Intel.

Wenn der nächste Konsumer Itani(c)um wirklich nur sehr wenig Cache haben sollte, dann liefe IA64 verdammt mässig darauf.

EPIC ist das Speicher- und Cache- intensivste Konzept im Vergleich zu CISC und RISC

MFG Bokill

Stone2001

2004-01-30, 17:09:56

Original geschrieben von Bokill
@Stone2001

Äpfel und Birnen

Hier werden keine Äpfel mit Birnen verglichen

Stimmt, aber (Prozessor-)Architekturen mit Prozessoren, was auf dasselbe hinausläuft! Falls nicht, erklär mir mal, wie man eine Architektur und ein Prozessor vergleicht!

BlackBirdSR

2004-01-30, 17:14:02

Original geschrieben von Stone2001
Stimmt, aber (Prozessor-)Architekturen mit Prozessoren, was auf dasselbe hinausläuft! Falls nicht, erklär mir mal, wie man eine Architektur und ein Prozessor vergleicht!

Äpfel und Birnen gehören zur gleichen Familie :)
Ehrlich gesagt, unterscheiden sie sich nur in wenigen Punkten. Nur so nebenbei ;)

Ich würde auch sagen, IA64 wäre hinsichtlich der Itaniums die logische Alternative, allerdings glaube ich, dass Intel trotzdem gezwungen ist auf AMDs Zug aufzuspringen.

Tiamat

2004-01-30, 17:15:55

Das geht alles ..
Der Itanium hat 256kb l2 Cache ,eine vergleichsweise sehr langsame Speicheranbindung und ne menge L3 Cache.Damit ist der aber vorallem für vielfach CPU Systeme ausgelegt
Der Xeon könnte aber locker die Dual CPU Rolle übernehmen ohne dem Itanium gefährlich zu werden.Mit 1MB l2 Cache und mit vorallem viel schnellerer Speicheranbindung wird man hinsichtlich der Performance bestimmt nicht so die Probleme haben.Notfalls kann man hier immer noch Versionen mit massiv L3 Cache vorstellen (dieses Jahr mit bis zu 4MB),was ja mittlerweile gar nix mehr neues ist.
Für den Itanium gibt es ja schon Win2000 ,Win2003 Server und WinXP 64 ,wobei auch ne Menge Business und Profi Applikationen vorhanden sind.Es fehlt nur an Mainstream Apps und Games..
Anders als WinXp 64 für x86-64 ... welches noch nicht mal das OS bieten kann.
Dann gibt es für Intel auch gar keinen Grund wieso man AMD beim Aufbau ihrer 64bit Erweiterung helfen sollte.Für Intel wäre es doch viel interessanter wenn x86-64 im Sand verläuft und sie ihre eigene Architektur pushen können ;D
Falls X86-64 Erfolgreich sein sollte ,kann man immer noch kompatible CPUs anbieten ,aber jetzt ist es erstmal wichtig die Itaniumplattform vor dem Untergang zu bewahren.

TheCounter

2004-01-30, 17:17:14

Original geschrieben von Endorphine
Edit: Deshalb ist Intel mitnichten gezwungen, AMD64 zu implementieren. Ich spekuliere übrigens immer noch auf IA64. Alles andere wäre wirtschaftlicher Wahnsinn aus Sicht von Intel und gleichzeitig ist es (noch) nicht notwendig, da AMD64 noch in den Kinderschuhen steckt. Ich denke es wird auf low-power Versionen des Itanium hinauslaufen. Vielleicht auch etwas anderes/neues. AMD64 kann ich mir beim besten Willen nicht vorstellen. Das Interview zeigt imho nur, dass Intel endlich aufgewacht ist und AMD64 ernst nimmt. Welchen Weg sie nun beschreiten werden wird die Zeit zeigen. Ich denke jedoch, dass Intel jetzt mit aller Macht IA64 vorantreiben wird. Da scheinbar derzeit die Entscheidung gefällt wurde und noch kein Zwang zum AMD64-Support besteht wird Intel IA64 irgendwie in den Massenmarkt bringen.

Ich misch mich da mal kurz ein, hab da ne Frage:

Würde das bedeuten das ich für einen Intel bzw. AMD jeweils ein verschiedenes OS brauche, falls Intel IA64 verwendet?

Stone2001

2004-01-30, 17:19:01

Original geschrieben von BlackBirdSR
Äpfel und Birnen gehören zur gleichen Familie :)
Ehrlich gesagt, unterscheiden sie sich nur in wenigen Punkten. Nur so nebenbei ;)
Haarspalterei ahoi :)
Original geschrieben von BlackBirdSR
Ich würde auch sagen, IA64 wäre hinsichtlich der Itaniums die logische Alternative, allerdings glaube ich, dass Intel trotzdem gezwungen ist auf AMDs Zug aufzuspringen.
Wie hat man sich dann das vorzustellen? Ein Itanium mit AMD64 Execution Layer z.B.?

Tiamat

2004-01-30, 17:19:25

Tiamat

2004-01-30, 17:21:35

Ja
Edit :Dieses Ja bezog sich auf die Frage von TheCounter..

Avalox

2004-01-30, 17:24:49

Na dieses schreit doch nach einer Abstimmung.

Das "Wartet ab, wir überraschen nach dem Preskott Flop euch noch positiv. Alles so geplant. Bitte keine Athlon 64 kaufen." Interview ist merkwürdig.

Das Interview ist verwirrend. Für die AMD64 Erweiterung existiert mit Linux eine schon durchaus einsetzbares BS.
Trotzdem erscheint dieser Schritt logischer zu sein. Vielleicht um HT(h) erweitert, bedeutet aber die Unterstützung von AMD64 einen Image Schaden und den Nagel im Sarg des Itaniums schlechthin.

Für den IA-64 gibt es diese BS ebenfalls, inzwischen sogar sehr ausgereift.
Ausserdem glaube ich nicht, dass Intel verwöhnte x86 Programmierer EPIC zumutet. Ein einziger Graus.

Endorphine

2004-01-30, 17:28:39

Original geschrieben von TheCounter
Ich misch mich da mal kurz ein, hab da ne Frage:

Würde das bedeuten das ich für einen Intel bzw. AMD jeweils ein verschiedenes OS brauche, falls Intel IA64 verwendet? Ja. Die beiden Architekturen haben zwar IA32-Binärkompatibilität als kleinsten gemeinsamen Nenner, die 64-Bit Architekturen sind aber zu verschieden, als dass ein Kernel beide bedienen könnte. Windows "64-Bit Edition für IA64" läuft nicht auf AMD64-Systemen und Windows "64-Bit Editoon für AMD64" läuft nicht auf IA64-Systemen.

Theoretisch wäre es denkbar, beides in einem Paket zusammenzuschnüren und dann bei der Installation automatisch den passenden Kernel zu verwenden. Ich denke aber, dass mit der Zeit eine der beiden Architekturen das Nachsehen haben wird, so dass diese Horrorvision nicht eintreten wird.

Tiamat

2004-01-30, 17:28:39

Für was denn ,die Abstimmung ist von der IA64 Seite doch sowieso verloren.3 Leute gegen die ganzen AMD Jungs ;D

Endorphine

2004-01-30, 17:30:50

Original geschrieben von Avalox
Na dieses schreit doch nach einer Abstimmung. Momentan kann eh' nur spekuliert werden, für welchen Weg sich Intel entscheiden wird. Da könntest du ebenso fragen, welche Architektur vom Einzelnen bevorzugt wird.

Da wird AMD64 haushoch gewinnen, weil sie halt von AMD kommt. ;) Egal wie IA64 in einem fairen Vergleich abschneiden würde.

peecee

2004-01-30, 17:36:00

diese Annahme von BlackBird in nem anderem Thread deute doch auch auf IA64 hin oder ist das Schwachsinn?

"Irgendwie gibt das Ganze keinen Sinn.

125 Millionen Transistoren. Daraus könnte man doch ein Dual Nothwood mit 1MB L2 Cache und 64Bit Erweiterungen bauen, wie jemand so freundlich war hinzuweisen.

Irgendwas steckt da noch drinn, es schluckt ordentlich an Strom, macht aber nicht nichts.
Wahrscheinlich eine ganze IA64 CPU"

mfg

BlackBirdSR

2004-01-30, 17:51:54

Original geschrieben von peecee
diese Annahme von BlackBird in nem anderem Thread deute doch auch auf IA64 hin oder ist das Schwachsinn?

"Irgendwie gibt das Ganze keinen Sinn.

125 Millionen Transistoren. Daraus könnte man doch ein Dual Nothwood mit 1MB L2 Cache und 64Bit Erweiterungen bauen, wie jemand so freundlich war hinzuweisen.

Irgendwas steckt da noch drinn, es schluckt ordentlich an Strom, macht aber nicht nichts.
Wahrscheinlich eine ganze IA64 CPU"

mfg

ist Schwachsinn ;),
war eher sarkastisch gemeint.
Ich glaube ehrlich gesagt nicht daran, dass Intel schon genug portierte Software hat, um IA64 in den Markt zu drängen.

Auf der anderen Seite.. IA64 Hybriden zu bauen, könnte von Anfang an, Intels Plan gewesen sein.
Lassen wir uns überraschen. Sind ja nur noch knapp 2 1/2 Wochen.

Flolle

2004-01-30, 17:53:29

Original geschrieben von Endorphine
Da wird AMD64 haushoch gewinnen, weil sie halt von AMD kommt. ;) Egal wie IA64 in einem fairen Vergleich abschneiden würde.

Von den Fanboys, mit denen man über sowas normalerweise sowieso nicht reden kann, mal abgesehen wollen halt ein paar Leute keinen Marktführer mit 80% Marktanteil sehen. ;)

Ich hoffe, wegen dem gerade genannten Grund, dass Intel AMD64 übernimmt. Ich habe aber keine Ahnung welche 64bit-Variante jetzt besser ist. Dafür kenne ich mich zu wenig mit diesen Sachen aus. Deshalb meine marktechnische Sichtweise (oder besser: Aus Kundensicht beste Möglichkeit, da dadurch keine Monopol-Preise entstehen).

P.S. Ich merke gerade, dass Leute, die eher zu Intel tendieren, meinen ersten Absatz in den falschen Hals bekommen könnten. Deshalb eine Klarstellung: Mit Fanboys meine ich Intel- wie AMD-Fanboys.

peecee

2004-01-30, 18:05:23

Wie ich das so mitbekommen habe sind heutige x86 CPUs intern ja RISC Prozessoren, die mit Decoder für die x86 Befehle ausgestattet sind.
Wäre es nicht möglich eine IA64 CPU mit x86 Decoder Einheiten auszustatten so das die CPU IA64 Code und x86 Code einlesen und verarbeiten kann?

Das würde ja auch irgendwie die wahrscheinlich nicht vorhandene Geschwindigkeitssteigerung bei den Prescott CPUs erklären.

Endorphine

2004-01-30, 18:12:54

Original geschrieben von Flolle
Von den Fanboys, mit denen man über sowas normalerweise sowieso nicht reden kann, mal abgesehen wollen halt ein paar Leute keinen Marktführer mit 80% Marktanteil sehen. ;)

Ich hoffe, wegen dem gerade genannten Grund, dass Intel AMD64 übernimmt. Ich habe aber keine Ahnung welche 64bit-Variante jetzt besser ist. Dafür kenne ich mich zu wenig mit diesen Sachen aus. Deshalb meine marktechnische Sichtweise (oder besser: Aus Kundensicht beste Möglichkeit, da dadurch keine Monopol-Preise entstehen). Ich würde es auch gern sehen, wenn Intel AMD64 übernimmt. Das wäre für die Gegenwart wohl die optimale Lösung: sanftmöglichster Übergang auf eine 64-Bit Architektur. Volle 32-Bit Leistung und 40-Bit möglicher Adressraum in einer Architektur.

Nachteilig finde ich daran nur, dass AMD64 nichts neues für die Zukunft bringt. Es ist imho das Erweiterungsprinzip von i80286 -> i80386 auf die bestehende IA32-Architektur angewendet. Derzeit stösst die Entwicklung von nach aussen hin seriell arbeitenden CPUs aber an die Grenzen. Die interne Parallelverarbeitung nimmt immer mehr zu. SMT ist ein Ansatz, einen zweiten I/O-Port für die Software zugänglich zu machen, um die Entwicklung hin zu mehr Parallelverarbeitung fortsetzen zu können. Das dumme ist nur, dass die Entwicklung hin zu SMP on-die geht. EPIC halte ich deshalb für deutlich zukunftsträchtiger, weil es sich den spezifischen Problemen der Parallelverarbeitung direkt annimmt.

Bei AMD64 fehlt jegliche Optimierung bezüglich der zukünftigen Entwicklung der Hardware. AMD64 nimmt sich der Probleme der IA32-Architektur ausserhalb des zu geringen Adressraumes nicht an. Mehr Register sind immer wünschenswert, klar. Ein wirklicher Architekturfortschritt im Sinne eines Paradigmenwechsels ist AMD64 imho nicht.

mrdigital

2004-01-30, 18:21:06

Ich glaube nicht, dass der Prescott 64bit kann, denn warum sollte Intel das Ding dann nach wie vor Pentium 4 nennen? Der einfachen Logik, neuer Name = neue Features folgt das Intelmarketing, wenn doch schon "nur" SSE ausreicht um aus einem P2 einen P3 zu machen. Ausser sie bennen das Teil in kürze in P5 um und releasen die selbe CPU nochmal (im neuen Sockel 775?) Ich glaube auch nicht, das es eine hybrid-CPU wird, denn im IA64 Mode würde die gesammte 32bit Software sehr langsam werden, denn das Intelargument ist ja die Backward Compatibility, und dann würde ja AMD um Welten besser da stehen (läuft im 64bit Mode und kann jede Art von Software schnell abarbeiten VS läuft im 64bit Modus und ist nur mit speziell angepasster 64bit Software schnell aber die alten 32bit Sachen sind lahm). Ich denke, dass Intel versuchen wird IA64 weiterhin als Highend, Profiservervariante zu vermarkten und mit einer x86-64 Version auf dem Desktop und den kleinen Servern AMD das Leben schwer zu machen (was ihnen mit dem grossen Marketing auch gelingen wird). Intel wird das mit keinem Wort im Marketing erwähen, dass x86-64 von AMD kommt, genauso wie AMD nicht sagt, das SSE(2) von Intel kommt, und bei der grossen Masse der Leute wird es nie ankommen, das Intel x86-64 nicht erfunden hat (spielt für den Kunden ja auch keine Rolle). Aber das sind alles wilde Vermutungen ;)

Bokill

2004-01-30, 18:25:45

@peecee

Der Witz am Itani(c)um ist ja, das er auch irgendwie x86 kann. Nur vergleichsweise kraftlos. Der sollte gar nich kraftvoll x86 können.
Die interne Einheit wurde so "liebevoll" entworfen, dass sogar ein Softwaredecoder schneller ist.
Ich denke es hat marktechnische Gründe weniger technologische, dass der Itani(c)um so mies x86 umsetzt.

Intel ist vermutlich durch den Zeitverzug ganz ordentlich in Bedrängnis geraten. Bzw. x86 hat ein Leistungsplus bekommen, welches am Anfang der Projektphase vom Itani(c)um so noch nicht angedacht war.

Ein CPU Design wächstt ja auch nicht an jedem Baum, erst Recht nicht, wenn dazu noch eine völlig eigene Sprache dazu erfunden wird. Die Folgen sehen wir jetzt, wenn die Marketing- und Rechte- Abteilung zu mächtig gegenüber den Hardwaredesignern ist.

MFG Bokill

StefanV

2004-01-30, 18:29:32

Original geschrieben von BlackBirdSR
Ich würde auch sagen, IA64 wäre hinsichtlich der Itaniums die logische Alternative, allerdings glaube ich, dass Intel trotzdem gezwungen ist auf AMDs Zug aufzuspringen.

Denke ich auch, zumal X86-64 die kompatiblere und wirtschaftlichere Lösung wäre...

StefanV

2004-01-30, 18:31:37

Original geschrieben von Endorphine
Ich würde es auch gern sehen, wenn Intel AMD64 übernimmt. Das wäre für die Gegenwart wohl die optimale Lösung: sanftmöglichster Übergang auf eine 64-Bit Architektur. Volle 32-Bit Leistung und 40-Bit möglicher Adressraum in einer Architektur.

Nachteilig finde ich daran nur, dass AMD64 nichts neues für die Zukunft bringt. Es ist imho das Erweiterungsprinzip von i80286 -> i80386 auf die bestehende IA32-Architektur angewendet. Derzeit stösst die Entwicklung von nach aussen hin seriell arbeitenden CPUs aber an die Grenzen. Die interne Parallelverarbeitung nimmt immer mehr zu. SMT ist ein Ansatz, einen zweiten I/O-Port für die Software zugänglich zu machen, um die Entwicklung hin zu mehr Parallelverarbeitung fortsetzen zu können. Das dumme ist nur, dass die Entwicklung hin zu SMP on-die geht. EPIC halte ich deshalb für deutlich zukunftsträchtiger, weil es sich den spezifischen Problemen der Parallelverarbeitung direkt annimmt.

Bei AMD64 fehlt jegliche Optimierung bezüglich der zukünftigen Entwicklung der Hardware. AMD64 nimmt sich der Probleme der IA32-Architektur ausserhalb des zu geringen Adressraumes nicht an. Mehr Register sind immer wünschenswert, klar. Ein wirklicher Architekturfortschritt im Sinne eines Paradigmenwechsels ist AMD64 imho nicht.

Naja, du musst auch sehen, daß sich die bisherigen AMD Erweiterungen leider nicht wirklich durchgesetzt haben, was unter anderm bei 3DNow recht schade ist...

Deshalb denke ich, daß AMD aus diesem Grunde nicht allzuviel Energie in X86-64 gesteckt hat...

Endorphine

2004-01-30, 18:42:01

Original geschrieben von Stefan Payne
Naja, du musst auch sehen, daß sich die bisherigen AMD Erweiterungen leider nicht wirklich durchgesetzt haben, was unter anderm bei 3DNow recht schade ist...

Deshalb denke ich, daß AMD aus diesem Grunde nicht allzuviel Energie in X86-64 gesteckt hat... Ich denke sie haben einfach den Weg eingeschlagen, der am sichersten für den Erfolg (http://www.aceshardware.com/read.jsp?id=60000309) erscheint. :)

AMD hat einfach das Erfolgsprinzip des i80386 auf die IA32-Architektur angewendet und hier und da etwas aufgebohrt. Intel ist (wieder mal) viel zu ehrgeizig an die Sache rangegangen und wird wohl an diesem Ehrgeiz wie mit RDRAM scheitern. IA64 ist zu teuer (da komplex) und kann die architektonischen Vorteile jetzt noch nicht ausspielen. Zudem ist die IA32-Performance bescheiden. Wer kauft da IA64, nur weil es in der Zukunft aller Wahrscheinlichkeit grosse Vorteile bringt? Niemand... Dieser Ehrgeiz wird Intel noch mal kräftig Marktanteile kosten oder Intel das Genick brechen, wenn sie es mal richtig übertreiben sollten.

zeckensack

2004-01-30, 19:18:10

Original geschrieben von Avalox
Trotzdem erscheint dieser Schritt logischer zu sein. Vielleicht um HT(h) erweitert, bedeutet aber die Unterstützung von AMD64 einen Image Schaden und den Nagel im Sarg des Itaniums schlechthin.?(
Der Sarg samt Inhalt ist längst fest verschlossen, war auch schon im Krematorium, und seine Überreste liegen auf dem Grund des Pazifiks, an der tiefsten Stelle.

zeckensack

2004-01-30, 19:23:26

Original geschrieben von Endorphine
<...>
IA64 ist zu teuer (da komplex) und kann die architektonischen Vorteile jetzt noch nicht ausspielen. Zudem ist die IA32-Performance bescheiden. Wer kauft da IA64, nur weil es in der Zukunft aller Wahrscheinlichkeit grosse Vorteile bringt?
<...>Welche Vorteile?
Verbraucht mehr Speicher?
Verbraucht mehr Bandbreite?
"Modernstes" reines in-order design?
Kann mit dynamischen Branches nichts anfangen?
Es steht "Intel" drauf?

Gast

2004-01-30, 19:31:42

Die Behauptung, es würde Intel schaden, AMD sanften Übergang zu 64 Bit zu übernehmen, ist lächerlich. Von Gesichtsverlust ist die Rede. Selten so ein Schwachsinn gehört. Der Marktführer tut alles um erfolgreich zu sein, da übernimmt man auch die Idee des vermeintlichen Konkurrenten und melkt die Kuh wie gehabt. Den Aktionären ist völlig gleich, wie.

BlackBirdSR

2004-01-30, 19:40:52

reunion

2004-01-30, 19:56:29

Original geschrieben von Gast
Die Behauptung, es würde Intel schaden, AMD sanften Übergang zu 64 Bit zu übernehmen, ist lächerlich. Von Gesichtsverlust ist die Rede. Selten so ein Schwachsinn gehört. Der Marktführer tut alles um erfolgreich zu sein, da übernimmt man auch die Idee des vermeintlichen Konkurrenten und melkt die Kuh wie gehabt. Den Aktionären ist völlig gleich, wie.

Es geht auch darum dass wenn Intel X86-64 von AMD übernimmt der Itanium mit seinem IA64 praktisch tot wäre.

zeckensack

2004-01-30, 19:57:02

Original geschrieben von BlackBirdSR
Die IA64 kann damit ihre Stärken nicht annähernd ausspielen.Welche Stärken?

reunion

2004-01-30, 19:59:06

Original geschrieben von zeckensack
Welche Vorteile?

Würde mich auch mal intressieren. :kratz:

Gast

2004-01-30, 20:02:38

Bei den 125 Millionen Transistoren des Prescotts: http://mitglied.lycos.de/scavengerx/pres3.jpg
Muss man den NW um mehr als nur 512kb L2 erweitern.Man könnte da locker noch zusätzlich einen IA64-Core unterbringen.Bei einem L2-Cache von 1MB und 6,4GB/s Speicherbandbreite sollten IA64 Programme ordentlich performen:chainsaw2. Mit einem IA64-Windows und 32bit Performance auf P4-Niveau wäre das eine echte AMD64-Alternative, die Intels Konzept nicht eine komplette Fehlinvestition werden lassen könnte.

Gast

2004-01-30, 20:08:27

Original geschrieben von reunion
Es geht auch darum dass wenn Intel X86-64 von AMD übernimmt der Itanium mit seinem IA64 praktisch tot wäre.

Noch mehr Unsinn :) Der Itanic ist wohl nicht für Desktopsegment entwickelt und plaziert worden. Intel bedient bekanntlich alle Bereiche. Die Software ist ebenfalls verschieden, ein Koexistenz ist problemlos möglich.

reunion

2004-01-30, 20:16:15

Original geschrieben von Gast
Noch mehr Unsinn :) Der Itanic ist wohl nicht für Desktopsegment entwickelt und plaziert worden. Intel bedient bekanntlich alle Bereiche. Die Software ist ebenfalls verschieden, ein Koexistenz ist problemlos möglich.

Ansichtssache ;)

reunion

2004-01-30, 20:17:19

Die ersten Gerüchte um die sagenumwobene Yamhill-Technologie sind bereits mehr als zwei Jahre alt (wir berichteten). Yamhill bezeichnete die 64-Bit Technologie von Intel für die x86-kompatiblen Desktop-Prozessoren. Bis dato hatte Intel die Notwendigkeit von 64-Bit Erweiterungen für Heimanwender stets verneint. Yamhill war lediglich ein Produkt der Gerüchteküche, die allerdings stets gut informiert schien. Inzwischen jedoch scheint gerade der Markterfolg von AMDs Opteron-Prozessor gegen die Xeon-Prozessoren für den mittleren Server-Bereich ein Umdenken bei Intel ausgelöst zu haben.

Wie ZDNet heute berichtet will Intel am 17. Februar seine 64-Bit Pläne zum ersten mal in der Öffentlichkeit präsentieren. Offiziell heißt die Technologie "CT", wobei die Bedeutung des Kürzels noch nicht bekannt ist. In jedem Fall soll Intels CT-Technologie kompatibel sein zu AMDs x86-64 Techologie. Die Intel 64-Bit Pentiums können damit die gleichen AMD64-Betriebssysteme und Programme verwenden, wie der AMD Opteron und Athlon 64. Ein Novum in der CPU-Entwicklung: Intel übernimmt eine Technologie von AMD.

Einige Experten sehen die Möglichkeit, dass CT eventuell schon in den Prescott-Prozessoren enthalten sein könnte, die demnächst vorgestellt werden. Theorien dazu gibt es genug. Man bedenke: auch HyperThreading war bereits von Anfang an in allen Pentium 4 CPUs integriert; nur deaktiviert. Freigeschaltet wurde sie nur in den Xeons und später bei den FSB800 Prozessoren respektive beim 3.06 GHz Pentium 4. Möglicherweise verfolgt Intel beim Prescott eine ähnliche Strategie. Alle Meldungen zum Thema Yamhill in der Vergangenheit gibt's hier.

In wie weit sich dieser Kurswechsel nun auf den dedizierten Server-Prozessor Intel Itanium auswirken wird, der mit seinem IA64 Befehlssatz gänzlich inkompatibel ist zur x86-Welt, muss abgewartet werden. Gewiss zielt der Itanium auf ein völlig anderes Marktsegment. Dennoch bleibt zu sehen, ob es für Intel langfristig möglich und vor allem sinnvoll ist, zwei zueinander inkompatible 64-Bit Technologien in einem Haus zu pflegen. Der 17. Februar dürfte demnach ein sehr interessanter Termin werden...
THX Robert für den Hinweis

http://www.planet3dnow.de/cgi-bin/newspub/viewnews.cgi?category=1&id=1075470923

BlackBirdSR

2004-01-30, 20:47:55

Original geschrieben von zeckensack
Welche Stärken?

du weisst wie ich das meine ;)
Fließkomma Power z.B.
Aber halt nicht mit x86 Code

zeckensack

2004-01-30, 22:49:44

Original geschrieben von BlackBirdSR
du weisst wie ich das meine ;)
Fließkomma Power z.B.
Aber halt nicht mit x86 Code VLIW hat traditionell Stärken bei stream kernel processing. Das sei dem Itanium gegönnt. Ein Itanium 2 gibt mit Sicherheit einen grossartigen MP3-Encoder, respektive DivX-Kompressor ab. Und das 'gute' daran:
Man braucht die Software garnicht erst darauf optimieren, nein, man darf sie gleich komplett neu schreiben.

Als Desktop- oder gar Server-Prozessor kann mir das ganze dennoch gestohlen bleiben. Die Integer-Leistung ist eher langweilig, das P/LV* ist absolut mangelhaft, und ganz wichtig, was schon wieder alle zu vergessen scheinen:
Auf IA64 laufen keine "Windows-Applikationen"!
Es sei denn, man ist mit der Performance eines 1,5GHz Willamette zufrieden, dann kann man sich diesen "Umstieg" aber wirklich auch gleich schenken.

Sorry, aber wenn hier wieder mal die halbe Welt IA64 für einen geeigneten x86-Ersatz hält ...
Das ist alles längst durchgekaut, immer wieder die gleiche Leier. Ich erwarte von den meisten Leuten hier, dass sie durchaus wissen was Begriffe wie "ISA", "Binärkompatibel" etc bedeuten. Vor diesem Hintergrund kann ich dann wirklich nur noch den Kopf schütteln.

Und dann noch solche Schoten:Zu lesen @ Planet3DNow!
Gewiss zielt der Itanium auf ein völlig anderes Marktsegment.Ja, er zielt auf das Segment der "um jeden Preis Intel haben will und zuviel Geld hab"-Personen.
Wem die ISA egal ist, der braucht sich auch nicht gerade auf IA64 festzulegen. Da kann man zB auch zu einem 64bittigen PPC greifen, oder - Gott bewahre! - zu einem K8.
Wer Wert auf Windows-Kompatibilität legt, der sollte sich auch definitiv woanders umsehen. Nochmal, weil's so schön war: was nützt ein portiertes OS, wenn die Applikationen nicht laufen, oder wenn sie doch irgendwie laufen, langsamer sind als auf einem 200 Dollar-Prozessor?

Bitte mal wühlen und vergleichen:
a (http://www.ibm.com/products/us/finder/finder?N=200002+601035&rsLst=off&DMC=Processor&Ne=400060&tmpl=%2Fproducts%2Fus%2Ffinder%2Ffinder&DVC=Processor%3a+Intel%26reg%3b+Itanium%26reg%3b+2)
b (http://www-132.ibm.com/content/home/store_IBMPublicUSA/en_US/eServer/pSeries/entry/pSeries_entry.html)
c (http://www-132.ibm.com/webapp/wcs/stores/servlet/CategoryDisplay?catalogId=-840&storeId=1&categoryId=2583808&langId=-1&dualCurrId=73)

d (http://www.aceshardware.com/SPECmine/index.jsp?b=0&s=1&v=1&if=0&r1f=2&r2f=0&m1f=0&m2f=2&o=0&o=1&start=20)
e (http://www.aceshardware.com/SPECmine/index.jsp?b=2&s=1&v=1&if=0&r1f=2&r2f=0&m1f=0&m2f=2&o=0&o=1)

GloomY

2004-01-30, 22:56:33

Original geschrieben von Bokill
@peecee

Der Witz am Itani(c)um ist ja, das er auch irgendwie x86 kann. Nur vergleichsweise kraftlos. Der sollte gar nich kraftvoll x86 können.
Die interne Einheit wurde so "liebevoll" entworfen, dass sogar ein Softwaredecoder schneller ist.
Ich denke es hat marktechnische Gründe weniger technologische, dass der Itani(c)um so mies x86 umsetzt.Imho ist das klar technisch bedingt. Die Konzepte von x86 und IA64 sind einfach zu verschieden. IA64 ist eine VLIW Architektur, d.h. der Compiler muss Parallelität, Predication und spekulative Loads finden und diese im Code festhalten. Die CPU verlässt sich darauf, dass sie diese Informationen im Code bekommt. Wenn sie nun x86 Code bekommt, welchem all diese Informationen fehlen, hat die IA64 CPU ein gewaltiges Problem.
Original geschrieben von zeckensack
Welche Stärken? Predication ist eine ganz schöne Sache. :) Damit meine ich allgemein, dass der Compiler Informationen der CPU geben kann, wie sie am Besten arbeiten soll.

IA64 kann z.B. FP Befehlen einen Zusatz verpassen, dass dieser Befehl extrem schnell ausgeführt werden soll (weil das Ergebnis wichtig ist und gebraucht wird). Daraufhin werden keine anderen FP Befehle mehr verarbeitet und alles daran gesetzt, diesen einen möglichst schnell fertig zu bekommen. Die Ausführungslatenz dieses einen Befehls sinkt dann beträchtlich, während der Gesamtdurchsatz natürlich darunter leidet. Für die insgesamte Performance kann das aber trotzdem sehr nützlich sein, wenn damit Wartezyklen vermieden werden können.

All diese Informationen bezüglich des optimalen Programmablaufs sind Vorteile einer VLIW Architektur (und speziell damit auch von EPIC). Ich will diese Vorteile gar nicht bestreiten oder niederreden. Es sind welche, jedoch reichen sie in der Summe IMHO nicht aus, um die großen Nachteile auszugleichen, die man sich ebenfalls damit ins Haus geholt hat (meine kritische Meinung zu EPIC sollte ja bekannt sein).

zeckensack

2004-01-30, 23:21:25

Original geschrieben von GloomY
Predication ist eine ganz schöne Sache. :) Damit meine ich allgemein, dass der Compiler Informationen der CPU geben kann, wie sie am Besten arbeiten soll.Predication ist auf jeder Architektur mit konditionalen moves möglich. Alternativ auch mit "quasi-konditionalen" moves ala PCMPEQD (setzt bei Erfüllung des Konditionals alle Bits des Ziel-Registers, bei Nichterfüllung wird es auf 0 gesetzt; damit kann man dann via bitweisem AND ganze "Zweige" einer if-else-Konstruktion eliminieren). Das ganze geht selbstverständlich auch auf x86 (http://www.forum-3dcenter.org/vbulletin/showthread.php?threadid=77975). Ich sehe keinen vernünftigen Grund, eine Architektur die mit Predication arbeiten muss, einer anderen mit starken 'echten' Branches und Predication vorzuziehen.

Apropos echte Branchesif (weather.rain)
{
<...>
}
else
{
<...>
}

Ein konditional, das sich zur Laufzeit nie oder nur in grossen Intervallen (mehrere Sekunden) ändert, kann von einer dynamischen branch prediction immer korrekt 'erlernt' werden. Nach maximal vier Treffern auf den Code können sowohl K7 als auch NetBurst den Sprung 100%ig korrekt vorhersagen. Der Verlust durch falsche Sprungvorhersage liegt über die gesamte Laufzeit bei quasi Null komma nichts.

Ein Compiler kann das nicht, ergo kann IA64 es auch nicht.

Erinnert sich noch jemand an Daniel Vogel von Epic Games?
"ziemlich viel if( IsKyro ) in unserer Codebase ;)"
http://www.forum-3dcenter.org/vbulletin/showthread.php?postid=273444#post273444

IA64 kann z.B. FP Befehlen einen Zusatz verpassen, dass dieser Befehl extrem schnell ausgeführt werden soll (weil das Ergebnis wichtig ist und gebraucht wird). Daraufhin werden keine anderen FP Befehle mehr verarbeitet und alles daran gesetzt, diesen einen möglichst schnell fertig zu bekommen. Die Ausführungslatenz dieses einen Befehls sinkt dann beträchtlich, während der Gesamtdurchsatz natürlich darunter leidet. Für die insgesamte Performance kann das aber trotzdem sehr nützlich sein, wenn damit Wartezyklen vermieden werden können.Moderne x86-Prozessoren sind auf solchen - sorry - Unsinn nicht angewiesen. Abhängigkeiten werden sowieso erkannt und entsprechend behandelt. Wo liegt hier der Vorteil der Compiler-basierten 'Lösung'?
All diese Informationen bezüglich des optimalen Programmablaufs sind Vorteile einer VLIW Architektur (und speziell damit auch von EPIC). Ich will diese Vorteile gar nicht bestreiten oder niederreden. Es sind welche, jedoch reichen sie in der Summe IMHO nicht aus, um die großen Nachteile auszugleichen, die man sich ebenfalls damit ins Haus geholt hat (meine kritische Meinung zu EPIC sollte ja bekannt sein).Diese sogenannten Vorteile sind Vereinfachungen, die VLIW bewusst in Kauf nimmt, um bei einem bestimmten Durchsatz klein, stromsparend und billig sein zu können.

Endorphine

2004-01-31, 00:11:41

*self deleted* Keine Lust mehr auf diese Argumentationskette.

Endorphine

2004-01-31, 00:19:32

*und auch hier*

HellHorse

2004-01-31, 00:20:07

Original geschrieben von zeckensack
...
Auf IA64 laufen keine "Windows-Applikationen"!
....
Java ;)
.NET ?

Hat jemand Zahlen oder einen Itanic zum testen?

Demirug

2004-01-31, 01:13:54

Der grösste Fehler bei IA64 ist eindeutig der Befehlssatz.

In Zeiten wo die Speicherbandbreite sowieso schon knapp bemessen ist einen Befehlssatz zu verwenden bei dem man gezwungen ist NOPs einzufügen ist eine sehr unüberlegte Handlung.

Das ganze hätte man auch einfacher haben können. Ein Opcode zu einleiten einer Sequenz die unabhängig ist und einer zum beenden. Oder Alternativ ein Opcode welcher zwei Blöcke trennt.

Die anderen durchaus schönen Ansätze von IA64 könnte man auch alle mit einer regulären X86 CPU nutzen wenn man nur genügend Register hat. Der Compiler müsste natürlich mitspielen. Es kommt ja letzten Endes nur darauf an zwischen dem schreiben eines Registers und dem verwenden dieses möglichst viel Arbeit mit anderen Register zu pressen.

GloomY

2004-01-31, 01:41:39

Original geschrieben von zeckensack
Predication ist auf jeder Architektur mit konditionalen moves möglich. Alternativ auch mit "quasi-konditionalen" moves ala PCMPEQD (setzt bei Erfüllung des Konditionals alle Bits des Ziel-Registers, bei Nichterfüllung wird es auf 0 gesetzt; damit kann man dann via bitweisem AND ganze "Zweige" einer if-else-Konstruktion eliminieren). Das ganze geht selbstverständlich auch auf x86 (http://www.forum-3dcenter.org/vbulletin/showthread.php?threadid=77975).Ich hab's mir damals durchgelesen und nicht wirklich verstanden; Ich hab's mir jetzt nochmal durchgelesen und steige nicht komplett dahinter. :| Vielleicht liegt's auch an der Uhrzeit...

Ich werd's mir morgen nochmal anschauen.
Original geschrieben von zeckensack
Ich sehe keinen vernünftigen Grund, eine Architektur die mit Predication arbeiten muss, einer anderen mit starken 'echten' Branches und Predication vorzuziehen.IA64 muss nicht mit Predication arbeiten, auch wenn sie es größtenteils tut. Die Prozessoren haben ebenso eine ganz normale Branch Prediction Unit, wie jeder andere Prozessor auch. Ob eine Verzweigung mittels Predication aufgelöst wird oder wie sonst ganz normal mit der Branch Unit abgearbeitet wird, entscheided (wie üblich) der Compiler.
Original geschrieben von zeckensack
Apropos echte Branchesif (weather.rain)
{
<...>
}
else
{
<...>
}

Ein konditional, das sich zur Laufzeit nie oder nur in grossen Intervallen (mehrere Sekunden) ändert, kann von einer dynamischen branch prediction immer korrekt 'erlernt' werden. Nach maximal vier Treffern auf den Code können sowohl K7 als auch NetBurst den Sprung 100%ig korrekt vorhersagen. Der Verlust durch falsche Sprungvorhersage liegt über die gesamte Laufzeit bei quasi Null komma nichts.

Ein Compiler kann das nicht, ergo kann IA64 es auch nicht.Die normale Branch Prediction Unit der IA64 Prozessoren kann das ebenso.
Original geschrieben von zeckensack
Erinnert sich noch jemand an Daniel Vogel von Epic Games?
"ziemlich viel if( IsKyro ) in unserer Codebase ;)"
http://www.forum-3dcenter.org/vbulletin/showthread.php?postid=273444#post273444Was willst du uns damit sagen?
Original geschrieben von zeckensack
Moderne x86-Prozessoren sind auf solchen - sorry - Unsinn nicht angewiesen. Abhängigkeiten werden sowieso erkannt und entsprechend behandelt. Wo liegt hier der Vorteil der Compiler-basierten 'Lösung'?Der Vorteil liegt in der gezielten Bevorzugung einzelner Befehle, sollte es für die Abfolge der Ausführungen notwendig sein.

Wenn ich das Ergebnis einer Berechnung als Operand für viele nachfolgende parallel auszuführende Befehle brauche, dann ist es verdammt wichtig, dass dieser eine Befehl, von dem der Start der Ausführung abhängt, möglichst schnell fertig wird.

Eine Hardware kann so eine Optimierung nicht erkennen. Ein Compiler kann abwägen, ob es sich lohnt oder nicht.

BlackBirdSR

2004-01-31, 03:53:27

Original geschrieben von zeckensack
VLIW hat traditionell Stärken bei stream kernel processing. Das sei dem Itanium gegönnt. Ein Itanium 2 gibt mit Sicherheit einen grossartigen MP3-Encoder, respektive DivX-Kompressor ab. Und das 'gute' daran:
Man braucht die Software garnicht erst darauf optimieren, nein, man darf sie gleich komplett neu schreiben.

Als Desktop- oder gar Server-Prozessor kann mir das ganze dennoch gestohlen bleiben. Die Integer-Leistung ist eher langweilig, das P/LV* ist absolut mangelhaft, und ganz wichtig, was schon wieder alle zu vergessen scheinen:
Auf IA64 laufen keine "Windows-Applikationen"!
Es sei denn, man ist mit der Performance eines 1,5GHz Willamette zufrieden, dann kann man sich diesen "Umstieg" aber wirklich auch gleich schenken.

Sorry, aber wenn hier wieder mal die halbe Welt IA64 für einen geeigneten x86-Ersatz hält ...
Das ist alles längst durchgekaut, immer wieder die gleiche Leier. Ich erwarte von den meisten Leuten hier, dass sie durchaus wissen was Begriffe wie "ISA", "Binärkompatibel" etc bedeuten. Vor diesem Hintergrund kann ich dann wirklich nur noch den Kopf schütteln.

sorry, aber das war ein hübsches Selbstgespräch.
Was das allerdings mit meinem Post zu tun hat weiss ich nicht.
Aber es tut gut sich Luft zu machen, gelle? ;)

Mir geht es übrigens nicht daraum, IA64 als x86 Ersatz zu sehen.

zeckensack

2004-01-31, 04:17:09

Original geschrieben von GloomY
Ich hab's mir damals durchgelesen und nicht wirklich verstanden; Ich hab's mir jetzt nochmal durchgelesen und steige nicht komplett dahinter. :| Vielleicht liegt's auch an der Uhrzeit...

Ich werd's mir morgen nochmal anschauen.Einfacheres Beispiel
C:
int a=<...>;
int b=<...>;
int c=<...>;
int x;

if (c==0)
{
x=a;
}
else
{
x=b;
}

<=>
x86 (P6+):
MOV EAX,[c] ;c laden
TEST EAX,EAX ;untersuchen
CMOVE EAX,[a] ;wenn c==0, lade a
CMOVNE EAX,[b] ;wenn c!=0, lade b
MOV [x],EAX ;speichern

<=>
MMX:
MOVD mm0,[c] ;mm0 := c
PXOR mm7,mm7 ;mm7 := 0
PCMPEQD mm7,mm0 ;mm7 := / 0xFFFFFFFF wenn c==0
; \ 0 wenn c!=0
MOVQ mm6,mm7 ;Bitmaske kopieren

MOVD mm0,[a] ;mm0 := a
MOVD mm1,[b] ;mm1 := b

PAND mm0,mm7 ;mm0 := a & Maske
PANDN mm6,mm1 ;mm6 := b & (~Maske)
POR mm0,mm6 ;mm0 := / a wenn c==0
; \ b wenn c!=0

MOVD [x],mm0 ;speichern
IA64 muss nicht mit Predication arbeiten, auch wenn sie es größtenteils tut. Die Prozessoren haben ebenso eine ganz normale Branch Prediction Unit, wie jeder andere Prozessor auch. Ob eine Verzweigung mittels Predication aufgelöst wird oder wie sonst ganz normal mit der Branch Unit abgearbeitet wird, entscheided (wie üblich) der Compiler.Ja, IA64 hat auch eine branch unit inklusive branch prediction und speculative execution ahoi. Allerdings ist dies kein Performance-Pfad, die Ressourcen sind im Vergleich zu den x86-Kollegen eher begrenzt (siehe hier (ftp://download.intel.com/design/Itanium/Downloads/24547403.pdf), Sektion 6.1.3, und hier (ftp://download.intel.com/design/Itanium/manuals/245317.pdf), Sektion 4). Einschränkend wirkt hier auch die in-order-Natur von IA64.

Die normale Branch Prediction Unit der IA64 Prozessoren kann das ebenso.
Was willst du uns damit sagen?Ich wollte ein Beispiel für data dependent branches bringen, die nicht vom Compiler vorhersagbar sind, aber umso besser von der Hardware. Predication ist eine tolle Technik, aber wie das so üblich ist bei tollen Dingen, funktioniert sie nur bei recht spezifischen Fällen richtig gut.
Der Vorteil liegt in der gezielten Bevorzugung einzelner Befehle, sollte es für die Abfolge der Ausführungen notwendig sein.Das ist überhaupt nur deswegen nötig, weil es eben ein VLIW ist, und somit alle Befehle eines Bündels gleichzeitig ankommen, und auch gleichzeitig ausführbar sind. Die Befehle sind ja nicht anhand ihrer gewünschten zeitlichen Abfolge in ein Bündel verpackt. Und IA64 ist ja auch ausgelegt auf beliebig viele parallel ausführbare Bündel (Der Itanium 1 kann AFAIK schon 2 Bündel gleichzeitig ausführen, wenn die passende Instruktions-Mischung vorliegt). Wenn nun weniger Ausführungseinheiten frei sind als Instruktionen hereinkommen, muss man natürlich auswählen, welche zuerst ausgeführt werden sollen.

Ein serielles Code-Modell hat dieses Problem nicht. Die Scheduling-Information ergibt sich schlicht aus der Reihenfolge der Befehle. Daher kann man das auch nicht als Vorteil von IA64 werten. Es ist auf OOOE nicht-VLIW-Architekturen einfach nicht nötig.
Wenn ich das Ergebnis einer Berechnung als Operand für viele nachfolgende parallel auszuführende Befehle brauche, dann ist es verdammt wichtig, dass dieser eine Befehl, von dem der Start der Ausführung abhängt, möglichst schnell fertig wird.

Eine Hardware kann so eine Optimierung nicht erkennen. Ein Compiler kann abwägen, ob es sich lohnt oder nicht. Ja und jein. Ein 'wichtiges' Zwischenergebnis wird schon vom Compiler bevorzugt in einem Register abgelegt, und nicht im Speicher. Und selbstverständlich wird es ausgerechnet, bevor es gebraucht wird. Wenn Prozessoren das nicht könnten, wäre OOOE nicht möglich.

Zudem sind die Latenzen der meisten Arithmetik-Operationen fix. Compiler können also recht genau vorhersagen, wieviele Takte man eine Operation 'köcheln' lassen muss, bevor sie fertig ist. Wenn man nicht genug 'Füllstoff' hat, um während dieser Zeit etwas anderes zu tun, dann ist das natürlich ein Problem, aber das kann dir auch mit IA64 passieren.

Gast

2004-01-31, 11:15:45

Also ist das etwa so Bauer hat 10 Schweine und 9 Rüben. Also wird ein Schwein Hungerleiden und schreien (lahmliegen/nichts tun)!

Oder umgekehrter Fall.
Bauer hat 10 Schweine und 11 Rüben, quasi sind alle Schweine zufrieden und arbeiten daran ihre Rübe zu verdauen, oh Ne da ist ja nun noch das Schwein was 2 Rüben auf einmal zu verdauen hat. Es wird wohl ersticken oder doppelt so lang brauchen bis es fertig ist.
Oder wird die überschüssige Rübe einfach verworfen? Wohl kaum!
Und wenn ich dann noch sehe, das Schwein 5 Schwein 7 die Hälfte wegfrisst, müsste ich zurück zu Schwein 5, um Schwein 7 wieder zu versorgen. Oder gar zu Schwein 10 mit der quersteckenden Rübe(schonmal versucht nem schwein essen wegzunehme?

Stone2001

2004-01-31, 13:55:42

hmm, die Diskussion, was Intel nun endlich als 64bit-Desktop-Prozessor auf den Markt bringen will hat sich wohl erledigt. Leonidas weiss mal wieder mehr als wir: ;)
Bei Intel ist die Katze nun aus dem Sack: Nach einem Bericht seitens 3DChips hat Intel-Präsident Paul Otellini am Mittwoch ein Statement abgegeben, in welcher jener ein 64-Bit-Update für "bestehende" 32-Bit-Prozessoren ankündigte, welches wohl zur Jahresmitte soweit sein soll. Damit ist gemeint, daß sobald Microsoft sein Windows XP 64-Bit marktreif gemacht hat, man mit auf den 64-Bit-Zug aufspringen wird - und dies nicht mit dem Itanium 2, sondern mit gewöhnlichen Desktop-Prozessoren, sprich dem Pentium 4. Damit läßt sich nun definitiv sagen, daß im Prescott-Prozessor ein 64-Bit-Erweiterung existent ist ...
... Zudem wird diese Intel 64-Bit-Erweiterung aller Wahrscheinlichkeit nach kompatibel zu AMD´s 64-Bit-Erweiterung in den K8-Prozessoren sein, da von Microsoft kein extra Windows XP 64-Bit für Intel entwickelt wird und Intel somit nur "Windows XP AMD64" oder "Windows XP IA64" (für Itanium) zur Auswahl hat, was logischerweise in ersterer Variante resultieren sollte. Offen bleibt nur noch, ob eventuell und vielleicht nicht schon der Pentium 4 Northwood über jene 64-Bit-Erweiterungen verfügt. Eigentlich ist dies sehr sehr unwahrscheinlich - es spricht hier alleinig dafür, daß der Intel-Präsident explizit von "bestehenden 32-Bit Prozessoren" sprach, und der Prescott zumindestens offiziell noch nicht existiert.

Endorphine

2004-01-31, 13:57:41

Original geschrieben von Stone2001
hmm, die Diskussion, was Intel nun endlich als 64bit-Desktop-Prozessor auf den Markt bringen will hat sich wohl erledigt. Leonidas weiss mal wieder mehr als wir: ;) Leonidas spekuliert auch nur. Wie alle anderen auch -> http://www.heise.de/newsticker/meldung/44175

So logisch ist das nämlich überhaupt nicht, dass Intel AMD64 einsetzen wird. Ich sehe da überhaupt keine Logik, eher im Gegenteil, das halte ich für unlogisch.

Stone2001

2004-01-31, 14:05:08

hmm, aber für eine Spekulation hört sich der Satz,
Damit läßt sich nun definitiv sagen, daß im Prescott-Prozessor ein 64-Bit-Erweiterung existent ist
doch schon recht sicher an, oder?
Ich persönlich, würde noch kein Cent darauf verwetten, das der Prescott tatsächlich eine 64bit Erweiterung hat, bzw.pb wir die im Prescott jemals zu Gesicht bekommen. Dafür brodelt mir die Gerüchteküche noch zu stark.

Ok, zugegebenermaßen, der Prescott ist, meiner Meinung nach, der heißeste Anwärter.

HOT

2004-02-01, 02:32:32

Klar, Intel implementiert mal eben IA64 in den Tejas und Prescott, jetzt weiss ich auch warum die chips so warm werden :P :D
Nein, es ist absolut nicht logisch, dass intel was anderes als AMD64 Implementiert, denn ohne ein Windows kann intel die 64 Bit erweiterung einsargen lassen. Und IA64 können wir für den Prescott wohl eher getrost ausschliessen.

Tiamat

2004-02-01, 02:41:31

Original geschrieben von HOT
Klar, Intel implementiert mal eben IA64 in den Tejas und Prescott, jetzt weiss ich auch warum die chips so warm werden :P :D
Nein, es ist absolut nicht logisch, dass intel was anderes als AMD64 Implementiert, denn ohne ein Windows kann intel die 64 Bit erweiterung einsargen lassen. Und IA64 können wir für den Prescott wohl eher getrost ausschliessen.

Es gibt bereits ein WinXP 64 für IA64 ,wie oft noch ;D

Endorphine

2004-02-01, 04:45:22

Damit die Behauptungen endlich ein Ende haben, dass Intel mangels IA64-Support von Microsoft zu AMD64-Support gezwungen ist:
Microsoft Windows Server 2003 für IA64 und AMD64: http://www.microsoft.com/windowsserver2003/64bit/default.mspx
Microsoft Windows XP 64-Bit Edition, nur für IA64: http://www.microsoft.com/windowsxp/64bit/default.asp

IA64 hat einen deutlichen Zeitvorsprung in der (MS-) Softwareunterstützung. Wenn ich mich recht entsinne wird Microsoft Longhorn dann auch für AMD64 anbieten. Windows XP jedoch nicht mehr. Wer AMD64 mit Windows nutzen möchte muss derzeit auf die Betaversion von Windows Server 2003 ausweichen, selbst wenn es sich um eine Workstation mit Workstation-Anwendungen handelt.

Tigerchen

2004-02-01, 06:17:56

Tja.Die Hoffnung stirbt zuletzt....:eyes:

Gast

2004-02-01, 10:41:16

Original geschrieben von Endorphine
Damit die Behauptungen endlich ein Ende haben, dass Intel mangels IA64-Support von Microsoft zu AMD64-Support gezwungen ist:
Microsoft Windows Server 2003 für IA64 und AMD64: http://www.microsoft.com/windowsserver2003/64bit/default.mspx
Microsoft Windows XP 64-Bit Edition, nur für IA64: http://www.microsoft.com/windowsxp/64bit/default.asp

IA64 hat einen deutlichen Zeitvorsprung in der (MS-) Softwareunterstützung. Wenn ich mich recht entsinne wird Microsoft Longhorn dann auch für AMD64 anbieten. Windows XP jedoch nicht mehr. Wer AMD64 mit Windows nutzen möchte muss derzeit auf die Betaversion von Windows Server 2003 ausweichen, selbst wenn es sich um eine Workstation mit Workstation-Anwendungen handelt.
Aber amds 64 Bit Erweiterung läßt sich einfacher integrieren! Nebenbei seit wann interessieren Server os Erweiterungen den Desktop Markt?
Wenn das konsummer os longhorn amd 64 Dirne hat dann, rate mal was sich durchgesetzt hat.

Wobei das auch am logischsten ist da intel den itanium ja in anderen Segmenten sieht!

CrazyIvan

2004-02-01, 12:15:39

@ Endo

Wie kommst Du darauf, dass es kein Win XP mit AMD64 Unterstützung mehr geben wird?
Sicher, dass ganze sollte schon vor nem halben Jahr erscheinen - aber das ist man ja von M$ nicht anders gewohnt :chainsaw:

Das letzte Gerücht zu diesem Thema besagt übrigens, dass M$ das SP2 gleich in Win XP x86-64 integrieren will und dass es damit zeitgleich mit selbigem erscheinen soll.

Aber mit einer Sache hast Du in jedem Fall recht:
M$ lässt sich damit verdammt viel Zeit - zumal es ja angeblich net sooo schwer sein soll, eine Anwendung oder ein OS auf x86-64 zu portieren.
Ein Schelm, wer dabei böses denkt... ;D

Endorphine

2004-02-01, 13:25:25

Ich weiss es gar nicht genau, wie die Strategie von Microsoft für AMD64-Unterstützung ausserhalb Windows Server 2003 aussieht - WinXP 64-Bit Edition auch für AMD64? Das wäre mir neu.

Würde imho auch wenig Sinn machen, ein nun schon bald wieder 4 Jahre altes Betriebssystem noch auf eine weitere Architektur zu portieren, wenn 1 Jahr später der Nachfolger fertig sein soll.

Hat jemand gesicherte Erkenntnisse dazu (Quellen/Links, bitte kein "ich weiss, dass das so werden wird")? Wäre interessant. :)

BlackBirdSR

2004-02-01, 13:33:07

Original geschrieben von Endorphine
Ich weiss es gar nicht genau, wie die Strategie von Microsoft für AMD64-Unterstützung ausserhalb Windows Server 2003 aussieht - WinXP 64-Bit Edition auch für AMD64? Das wäre mir neu.

Würde imho auch wenig Sinn machen, ein nun schon bald wieder 4 Jahre altes Betriebssystem noch auf eine weitere Architektur zu portieren, wenn 1 Jahr später der Nachfolger fertig sein soll.

Hat jemand gesicherte Erkenntnisse dazu (Quellen/Links, bitte kein "ich weiss, dass das so werden wird")? Wäre interessant. :)

ich dachte bisher, es wird kein XP für AMD64 geben...

Endorphine

2004-02-01, 13:35:14

Original geschrieben von BlackBirdSR
ich dachte bisher, es wird kein XP für AMD64 geben... Ich auch... Was stimmt denn nun? :kratz2:

Stone2001

2004-02-01, 13:40:52

Original geschrieben von BlackBirdSR
ich dachte bisher, es wird kein XP für AMD64 geben...
hmm, ich dachte bisher, das es ein XP für AMD64 geben wird.
Original von www.tecChannel.de
Die finale Version von Windows XP 64 Bit Edition für AMD64-Prozessoren soll laut Microsoft in der ersten Jahreshälfte 2004 auf den Markt kommen. Zum Launch-Termin wird es voraussichtlich nur eine geringe Anzahl von 64-Bit-Programmen geben. Entscheidend ist somit auch die Performance bestehender 32-Bit-Anwendungen unter Windows XP 64 Bit. Der Prozessor soll laut AMD auch im 64-Bit-Modus 32-Bit-Code ohne Geschwindigkeitseinbußen ausführen können. Windows XP 64 Bit verwendet hierbei die WOW64-Technologie. Kostet dieses "Windows on Windows 64" Performance?

Hier mal den Link zum Artikel selber: http://www.tecchannel.de/hardware/1245/

BTW: Also das letzte, was ich über das SP2 von XP gehört habe ist, das es neben einigen Verbesserungen im Patch-Management, auch starke Verbesserungen für Athlons mit sich bringen wird. Aber von einer Erweiterung um AMD64 war bisher noch nie die Rede.

Endorphine

2004-02-01, 13:47:33

Original geschrieben von Stone2001
hmm, ich dachte bisher, das es ein XP für AMD64 geben wird.

Hier mal den Link zum Artikel selber: http://www.tecchannel.de/hardware/1245/

BTW: Also das letzte, was ich über das SP2 von XP gehört habe ist, das es neben einigen Verbesserungen im Patch-Management, auch starke Verbesserungen für Athlons mit sich bringen wird. Aber von einer Erweiterung um AMD64 war bisher noch nie die Rede. Also doch -> http://www.tecchannel.de/hardware/1245/

Thx. Dann haben wir ja auch hier Gleichstand, wenn auch IA64 den Zeitvorsprung verbuchen kann. Damit wären wir wieder am Ausgangspunkt dieses Threads...

Edit: du hast schneller editiert als ich auf den Zitatbutton klicken konnte. Nicht übel. ;)

Tigerchen

2004-02-01, 13:58:24

Heise hat mal gemeldet daß eine Art Box für 32 Bit Spiele für den 64 Bit Modus bereits funktionieren würde. Allerdings nur für D3D.
Und Endorphine! Longhorn kommt nicht vor 2006. Auch das kommt von Heise. Könnte es sein daß Longhorn für 32 Bit gar nicht mehr zur Debatte steht? Wäre zumindest eine Erklärung warum die 64 Bit Erweiterung so plötzlich kommt obwohl sie laut INTeL und Endorphine vor kurzem noch völlig überflüssig war.

haifisch1896

2004-02-01, 14:00:27

Das denke ich nicht, da bestimmt auch 32bit-Nutzer im Zielsegment vorhanden sind.

CrazyIvan

2004-02-01, 14:30:54

@ Stone2001

Meinte auch nicht, dass AMD64 ins SP2 integriert wird, sondern umgekehrt - Win XP AMD64 soll inklusive SP2 rauskommen. Da aber selbiges wohl nicht vor Juni fertig sein wird, siehts auch mit XP x86-64 so aus, als würde es nicht vor Juni kommen.

@ Tigerchen

Du meinst wohl WOW64. Ist so eine Art Middleware, die 32bit Apps unter Win XP64 (x86-64) ermöglichen soll. Genaueres dazu findest Du im von Stone verlinkten Tecchannel Artikel.

pippo

2004-02-01, 14:49:03

Versteh das jetzt nicht ganz. Es ist doch schon seit 1 Jahr die Rede, dass es ein WindowsXP-64 für AMD geben wird und das steht doch auch regelmässig in irgendwelchen News.

Ausserdem wird wohl kaum schon vor 2006 Windows "Longhorn" kommen.

BlackBirdSR

2004-02-01, 14:49:29

Original geschrieben von Tigerchen

Heise hat mal gemeldet daß eine Art Box für 32 Bit Spiele für den 64 Bit Modus bereits funktionieren würde. Allerdings nur für D3D.
Und Endorphine! Longhorn kommt nicht vor 2006. Auch das kommt von Heise. Könnte es sein daß Longhorn für 32 Bit gar nicht mehr zur Debatte steht? Wäre zumindest eine Erklärung warum die 64 Bit Erweiterung so plötzlich kommt obwohl sie laut INTeL und Endorphine vor kurzem noch völlig überflüssig war.

Longhorn ohne native 32 Bit Support?
Ich weiss nicht wie leicht für Transmeta ein Umstieg wäre. Aber VIA würde man damit doch aus dem Rennen werfen.

Klar, bis 2006 ist noch lange hin..
Trotzdem, interessante Idee.

Stone2001

2004-02-01, 15:04:33

Original geschrieben von BlackBirdSR
Longhorn ohne native 32 Bit Support?
Ich weiss nicht wie leicht für Transmeta ein Umstieg wäre. Aber VIA würde man damit doch aus dem Rennen werfen.

Klar, bis 2006 ist noch lange hin..
Trotzdem, interessante Idee.
Ich glaube, leicht wird so ein Umstieg für Transmeta auch nicht. Zumal das man davon ausgehen kann, das bis 2006 64bit-Prozessoren auch auf dem mobilen Sektor vertreten sein werden. AMD ist ja schon da, und wer weiss, viellicht gibt es ja auch bald eine 64bit Version des Pentium M!

@ CrazyIvan:
Du meinst wohl, dass die Errungenschaften aus dem SP2 für Windoes XP auch sofort in Win XP64 für AMD64 enthalten sein werden, oder?

CrazyIvan

2004-02-01, 15:46:47

@ Stone2001

Genau das wollte ich damit sagen :)

Zu Transmeta:

So schwer sollte das mit deren VLIW Architektur net sein...

Ob nun die Code-Morphing software aus IA32 Code ihre 256bit (Effecion) VLIWs macht, oder aus x86-64, sollte der relativ schnuppe sein. Mal von eventuellen Optimierungen abgesehen, sollte das sogar per Microcode Patch gehen ... oder zumindest durch geringfügige Änderungen an der Architektur.

Beim Pentium-M sieht das ganze schon wieder anders aus. Da der ja eher ein P3 als ein P4 zu sein scheint, kann man da auch nicht mal so einfach Yamhill dranklatschen - egal ob es nun IA64, x86-64 oder sonstwas sein wird...

Via hat die gleichen Probleme...

Juerg

2004-02-01, 17:25:01

Naja, vielleicht verschiebt jemand den Thread ins Spekulationsforum?

In den Header Dateien von VS.NET 2003 sind folgende Einträge:

typedef enum CV_CPU_TYPE_e {
CV_CFL_8080 = 0x00,
CV_CFL_8086 = 0x01,

...deleted alot of other CPU

CV_CFL_IA64 = 0x80, // merced??
CV_CFL_IA64_1 = 0x80, // mckinnley??
CV_CFL_IA64_2 = 0x81, // madison??

... deleted alot of other CPU

CV_CFL_X8664 = 0xD0,
CV_CFL_AMD64 = CV_CFL_X8664,
...
} CV_CPU_TYPE_e;

und weiter (msidefs.h):

// Hardware properties: set by installer at initialization
#define IPROPNAME_INTEL TEXT("Intel")
#if (_WIN32_MSI >= 150)
#define IPROPNAME_AMD64 TEXT("AMD64")
#define IPROPNAME_INTEL64 TEXT("Intel64")
#else // (_WIN32_MSI >= 150)
#define IPROPNAME_IA64 TEXT("IA64")
#endif // (_WIN32_MSI >= 150)

Dies sind sehr sehr starke Hinweise auf eine
AMD64 kompatible Version von 64-bit Extensions seitens Intel....

vor allem diese Zeilen belegen, dass der generische Ausdruck X8664 derselbe CPU-type ist wie AMD64 ist.

CV_CFL_X8664 = 0xD0,
CV_CFL_AMD64 = CV_CFL_X8664,

Diese Zeilen belgen, dass Intel64 != IA64 ist:
IPROPNAME_AMD64 TEXT("AMD64")
IPROPNAME_INTEL64 TEXT("Intel64")
IPROPNAME_IA64 TEXT("IA64")

Was meint Ihr dazu?

Stone2001

2004-02-01, 17:25:02

Original geschrieben von CrazyIvan
Zu Transmeta:

So schwer sollte das mit deren VLIW Architektur net sein...

Ob nun die Code-Morphing software aus IA32 Code ihre 256bit (Effecion) VLIWs macht, oder aus x86-64, sollte der relativ schnuppe sein. Mal von eventuellen Optimierungen abgesehen, sollte das sogar per Microcode Patch gehen ... oder zumindest durch geringfügige Änderungen an der Architektur.

Also durch einen einfachen Microcode-Patch wird sich AMD64 oder IA64 sicherlich nicht nachrüsten lassen. Die Ausführungseinheiten des Efficeon sind auf 32bit ausgelegt und nicht auf 64bit.
Und geringfügige Änderungen an der Hardware würde ich sowas auch nicht nennen. (Naja, mal eben die Register, die Ausführungseinheiten, die Busse, ... zu ändern, dürfte aber immer noch einfacher sein, als ein Prozessor von Grund auf neu zu designen, oder?) Da dürfte die Änderung der Code-Morphing-Software noch am einfachsten sein.

BTW: Kann mir jemand genau sagen, was für 8 Ausführungseinheiten der Efficeon hat?
Original geschrieben von CrazyIvan
Beim Pentium-M sieht das ganze schon wieder anders aus. Da der ja eher ein P3 als ein P4 zu sein scheint, kann man da auch nicht mal so einfach Yamhill dranklatschen - egal ob es nun IA64, x86-64 oder sonstwas sein wird...

Via hat die gleichen Probleme...
Warum geht beim Pentium M nicht, was beim P4 geht? Wenn Intel beim Prescott Ausführungseinheiten zusammenschalten kann (zumindest wurde das bei Yamhil vermutet, das man so 64bit ermöglicht), warum sollen sie das nicht auch beim Dothan machen? Vielleicht verzögert sich ja die Einführung des Dothan deswegen?

BlackBirdSR

2004-02-01, 17:37:03

Original geschrieben von Stone2001

Warum geht beim Pentium M nicht, was beim P4 geht? Wenn Intel beim Prescott Ausführungseinheiten zusammenschalten kann (zumindest wurde das bei Yamhil vermutet, das man so 64bit ermöglicht), warum sollen sie das nicht auch beim Dothan machen? Vielleicht verzögert sich ja die Einführung des Dothan deswegen?

hmm, wenn man überlegt, dass Dothan doppelt so viele Transen haben soll wie Banias (77 vs 144).
Dann könnte man ja die Milchmädchen-Rechnung durchführen.

2x so viel Cache, und 2x so viel Bit = 2x so viel Transistoren ;D

Avalox

2004-02-01, 17:49:25

Gut recherchiert. Warum aber überhaupt die Unterscheidung?

Was anderes. Spricht was gegen ein AMD64Bit Hyper Threading bei Intel?
In anbetracht des geringen Aufwandes des bisher von Intel realisierten SMT, wäre die Ausweitung auch auf dem AMD 64Bit Mode doch mehr als logisch.

Tigerchen

2004-02-01, 17:50:33

Original geschrieben von CrazyIvan
@ Tigerchen

Du meinst wohl WOW64. Ist so eine Art Middleware, die 32bit Apps unter Win XP64 (x86-64) ermöglichen soll. Genaueres dazu findest Du im von Stone verlinkten Tecchannel Artikel.

Genau das meinte ich!
Sowas entwickelt man doch nicht heute um es irgendwann mal in Longhorn zu verwenden. Das hofft allenfalls Endorphine um sich nicht von seinem heißgeliebten IA64 verabschieden zu müßen.

BlackBirdSR

2004-02-01, 17:56:39

Original geschrieben von Avalox
Gut recherchiert. Warum aber überhaupt die Unterscheidung?

Was anderes. Spricht was gegen ein AMD64Bit Hyper Threading bei Intel?
In anbetracht des geringen Aufwandes des bisher von Intel realisierten SMT, wäre die Ausweitung auch auf dem AMD 64Bit Mode doch mehr als logisch.

SMT und 64Bit sind 2 paar Schuhe.
Je nach Implementierung wird Hyperhtreading vielleicht neagtiv beeinflusst. Aber die beiden Features schließen sich nicht aus.

Avalox

2004-02-01, 18:02:45

Ja ist klar. Nun ist aber der Register Platz 4x so gross wie vorher.
Zwar immer noch gering. Könnte mir aber gut vorstellen, das Cache und Prefetch Probleme zunehmen.

Vielleicht wird ja eine der grössten Neuerungen eines neuen, überarbeitete HTs sein, dass man es Software gesteuert ausschalten kann.

CrazyIvan

2004-02-01, 18:52:18

@ Stone2001

1. Du kannst den Crusoe bzw. Effecion nicht mit nem anderen Prozessor vergleichen. Der compiliert sich quasi seinen Code per Code - Morphing zur Laufzeit. Intern arbeitet der eh mit 256 bit. Und ob der nun aus 32 oder 64 bit Code seine VLIWs bastelt, sollte dem schnuppe sein. Weiß jetzt nicht genau, ob die einzelnen Ausführungseinheiten auf 32 bit ausgelegt sind, oder ob die nich vielleicht mehr oder weniger variabel sind...

2. Von IA64 redete ich auch nicht. Das ist dann wieder ein ganz anderer Stiefel...

3. Bezüglich Deiner Frage kann ich mich an nen Artikel auf tecchannel.de erinnern. Aber entweder bin ich zu blöd zum Suchen, oder die haben das Ding in ihren Premium Abschnitt verschoben...

zum Pentium-M

Sicherlich kann man den auf die gleiche Art und Weise erweitern, wie den P4. Ich meinte jedoch, dass man nicht einfach per Copy & Paste Yamhill dort einbauen kann, sondern das ganze dann schon extra für den Dothan designed werden müsste. Wollte damit nur sagen, dass dies nochmals einen immensen Entwicklungsaufwand erfordern würde und nich so von heute auf morgen machbar ist.

Stone2001

2004-02-01, 19:54:50

Original geschrieben von CrazyIvan
@ Stone2001

1. Du kannst den Crusoe bzw. Effecion nicht mit nem anderen Prozessor vergleichen. Der compiliert sich quasi seinen Code per Code - Morphing zur Laufzeit. Intern arbeitet der eh mit 256 bit. Und ob der nun aus 32 oder 64 bit Code seine VLIWs bastelt, sollte dem schnuppe sein. Weiß jetzt nicht genau, ob die einzelnen Ausführungseinheiten auf 32 bit ausgelegt sind, oder ob die nich vielleicht mehr oder weniger variabel sind...

2. Von IA64 redete ich auch nicht. Das ist dann wieder ein ganz anderer Stiefel...

3. Bezüglich Deiner Frage kann ich mich an nen Artikel auf tecchannel.de erinnern. Aber entweder bin ich zu blöd zum Suchen, oder die haben das Ding in ihren Premium Abschnitt verschoben...

Der Efficeon ist ein 256 bit VLIW Prozessor mit 8 Ausführungseinheiten! So steht es zumindest auf Transmetas Homepage! ;) Auch die Bilder auf der Homepage lassen darauf schliesen, das er 8 32bit Befehle verarbeiten kann.
OK, die Frage ist jetzt, ob er das per Code-Morhping-Software hinbekommt, was Intel in Hardare realisieren will, also 2 32 bit Ausführungseinheiten zusammen als 64bit Ausführungseinheit laufen zu lassen. Ich persönlich bezwiefle aber, das das geht. (Zumindest würde ich ein solches Feature ganz groß an die Werbeglocke hängen ;) )
Einen TecChannel-Artikel vom Crusoe findest du hier: http://www.tecchannel.de/hardware/256/index.html
Und für den Efficeon hier: http://www.tecchannel.de/hardware/1264/2.html

Gast

2004-02-04, 09:46:59

Avalox

2004-02-04, 09:55:54

Das 64 Bit XP mit AMD64Bit Technik gibt es schon seit einer Weile für Developer.
Zumal ja W2K3 XP basierend ist.

Stone2001

2004-02-04, 17:12:43

Jetzt kann sich aber jeder A64 Besitzter eine Demo-Version von WinXP64 herunterladen. Die Version ist zwar auf 360 Tage beschränkt, aber besser als gar nichts. ;)

Siehe auch: http://www.chip.de/news/c_news_11426621.html

TheCounter

2004-02-09, 01:17:47

Hi

mich verwirrt etwas, und zwar folgende Sätze:

According to Nathan, the current Prescott, while it has 64-bit capabilities, doesn't have support for microinstructions compatible with AMD's X86-64 set.

He claims the Prescott's 64-bit extensions are different, and Intel won't implement it in this chip, but rather wait until the Tejas *T recension, which is supposed to arrive next year.

Heißt das nun dass die 64-Bit Erweiterung im Prescott nicht kompatibel zu AMD64 ist?

Die ganze News gibts hier: http://www.theinquirer.net/?article=14036

Coda

2004-02-09, 01:23:54

Wenn es stimmt, dann ja.
Aber beim Inquirer steht extrem viel Müll

TheCounter

2004-02-09, 01:27:24

Original geschrieben von Coda
Wenn es stimmt, dann ja.
Aber beim Inquirer steht extrem viel Müll

Ja das weis ich, aber ich wollte nurmal wissen ob das so wäre wenn es wirklich wahr wäre. Also Danke :)

Plasmafusion

2004-02-09, 10:12:30

Warum gibts eigentlich keinen IA64 Bit Emulator alá Vmware ? Mit massivem CPU Aufwand müsste dass doch gehen ?

TheCounter

2004-02-09, 10:21:49

Original geschrieben von Plasmafusion
Warum gibts eigentlich keinen IA64 Bit Emulator alá Vmware ? Mit massivem CPU Aufwand müsste dass doch gehen ?

Wo wäre da dann der Sinn dahinter? 64-Bit soll ja mehr Performence bringen bringen, aber durch den Emulator würde das doch wieder völlig zur nichte gemacht, das wäre dann ja noch langsamer oder?

Plasmafusion

2004-02-09, 12:35:32

Original geschrieben von TheCounter
Wo wäre da dann der Sinn dahinter? 64-Bit soll ja mehr Performence bringen bringen, aber durch den Emulator würde das doch wieder völlig zur nichte gemacht, das wäre dann ja noch langsamer oder?

Ja aber, für arme Programmierer wäre das durchaus gut.
Können Programme testen ob sie laufen (wohin auch immer) und müssen nicht in einen neuen Rechner intervestieren.

BTW, VMware kann das nicht.

CrazyIvan

2004-02-09, 20:03:33

AFAIK gibbet sowas...

nur halt nich für jedes erbärmliche dahergelaufene Menschlein... ;D

Weit vor der Präsentation des Itanium bzw. Merced, wie man ihn damals noch nannte, haben die solche SDKs an ausgesuchte Entwickler verteilt.

Avalox

2004-02-09, 20:31:06

In der aktuellen c't wird auch gemutmasst, dass Intel nicht Intel wäre, wenn diese nicht die AMD64 Bit Erweiterung erweitert/verändert hätten.

Tesseract

2004-02-09, 20:43:38

die 64bit lösung von intel hat sicher etwas mit AMD64 zu tun, sonst hätten sie sich nicht bei AMD die lizenz "erhandelt"

da M$ es aber ablehnt über IA64 und AMD64 hinauszugehen wird intel wohl AMD64 kompatibel bleiben müssen

IA64 halte ich für ausgeschlossen, da werden die anderen entwickler nicht mitspielen (nur wegen intels dickschädel werden nicht hunderte firmen - für irre summen - programme modifizieren/neuschreiben ohne das es etwas bringt abgesehen von massiven gewinneinbrüchen)
mal abgesehen davon das intel eigendlich noch kein 64bit für den massenmarkt vorsieht wenn nicht umbedingt nötig - da ist ein zu x86 inkompatibles IA64 ein ziemlicher wiederspruch

(alles nur mitmaßungen - bitte nicht haun :D)

reunion

2004-02-17, 19:28:21

Unsere Kollegen von tecCHANNEL gelangten noch vor der Eröffnung des Intel Developer Forum 2004 an bestätigende Informationen zur 64Bit Erweiterung für Intels x86-Prozessoren. So soll der Xeon-Prozessor noch in der ersten Jahreshälfte 2004 mit der 64Bit Erweiterung erscheinen.

Das Intel Developer Forum begann um 9:30 Uhr Ortszeit (17:30 Uhr MEZ) mit der Eröffnung durch Graig Barettes Keynote. Bereits vorher waren zwei Präsentationen zugänglich, zum einen von "Hewlett-Peckard: Future Directions in Servers for Industry Standard 64-Bit Computing" und zum anderen durch "NVIDIA und Intel: A Winning Combination for PCI Express". In beiden Präsentationen werden die 64Bit Erweiterungen werähnt. Intels Codename für die 64Bit Erweiterung lautet Clackamas Technology, kurz als Zusatz "CT" im Namen der Prozessoren.

Bei der Hewlett-Peckard Präsentation geht es um einen Xeon-Prozessor mit 64Bit Extensions-Technologie für die ProLiant-Server., Diese Erweiterungen sollen im Xeon-Nachfolger Nocona enthalten sein, der im zweiten Quartal 2004 erscheinen wird.

Bei der Präsentation von NVIDIA dreht sich alles um die Optimierung der eigenen Grafikprodukte auf Intels „IA32E Extended Technology“.

Intels offizielles Statement zu diesem Thema blieb bisher aus.

http://www.tweakpc.de/mehr.php?news_id=5351&s=0&s1=8

mfg
reu

Sk_Antilles

2004-02-17, 20:04:34

So, jetzt ist die Katze endgültig aus dem Sack. Also!

http://www.heise.de/newsticker/meldung/44719

Sk_Antilles

Gast

2004-02-17, 20:08:58

"Welcome in the World of AMD64", hehe

Pirx

2004-02-17, 20:17:49

Jubel! Freude!;D
Hoffentlich hat da AMD auch was von und wenns nur Imagegewinn ist.

Sir Integral Wingate Hellsing

2004-02-17, 20:24:05

Heute hatte der CEO von AMD sicherlich was zu Lachen ;)

reunion

2004-02-17, 20:34:37

Original geschrieben von Sk_Antilles
So, jetzt ist die Katze endgültig aus dem Sack. Also!

http://www.heise.de/newsticker/meldung/44719

Sk_Antilles

Interresant...
Das dürfte wohl die Bankrotterklärung für den Itanium sein.
Andererseits ist damit ein großer Vorteil von AMD Prozessoren dahin.

RLZ

2004-02-17, 20:47:58

Erst mal Performance abwarten. Ob der Vorteil von AMD damit dahin ist, würd ich mal nicht sagen. Schliesslich kriegt man deren 64 Bitter an jeder Straßenecke. Könnte ganz profitabel für AMD sein, da es ein sehr gutes Verkaufsargument ist, dass die Technologie so gut ist, dass Intel nachziehen muss.
Ausserdem Mitte des Jahres Xeons bedeutet erstens nicht, dass sie dann auch wirklich lieferbar sind (wir kennen ja Intel ;) ) und zweitens, dass auch Desktops damit rauskommen...

Stone2001

2004-02-17, 20:54:35

Original geschrieben von reunion
Interresant...
Das dürfte wohl die Bankrotterklärung für den Itanium sein.
Andererseits ist damit ein großer Vorteil von AMD Prozessoren dahin.
Das dürfte mitnichten eine Bankrotterklärung für den Itanium sein. Der wird weiterhin schön die Server-Welt und Co bedienen, nur auf den Desktop-Markt wird er jetzt wahrscheinlich nicht mehr kommen.

Und, meiner Meinung nach, ist der einzigste Vorteil, den AMD verliert der, das die jetzt nicht mehr mit der 64bit-Erweiterung werben können. Andererseits können sie jetzt damit werben, das der Riese sie kopiert hat... .
Wenn jetzt AMD noch HyperThreading integriert, dann haben wir wieder die Situtation, wie vor über einem Jahr.

Endorphine

2004-02-17, 20:57:06

Original geschrieben von Stone2001
Das dürfte mitnichten eine Bankrotterklärung für den Itanium sein. Der wird weiterhin schön die Server-Welt und Co bedienen, nur auf den Desktop-Markt wird er jetzt wahrscheinlich nicht mehr kommen. Das ist der Gnadenschuss für IA64, sehe ich genau so wie reunion. Wenn überhaupt, dann wird IA64 in die Ecke der HPC-Unixrechner abgedrängt. In den Massenmarkt wird IA64 so niemals kommen.

Wahnsinn...

Sk_Antilles

2004-02-17, 21:13:21

Das Gute ist, dass bei der Entwicklung von 64bit Software endlich mehr Klarheit geschaffen wurde. Da nun Intel diese Technik unterstützt werden bestimmt viele Softwareentwickler den Weg zu 64bit schneller beschreiten.

Im Endeffekt ist die Nachricht gut für uns alle!

Sk_Antilles

Edit: Hier ein kurzer Ausschnitt von einem theinquirer.net Artikel:

"...What about the Multi-Processor versions? Those will follow in mid-2005. Looks like the quote of 64-bits being introduced, "When it is needed," has changed to: "When AMD kicks our ass hard enough". I know, the spin will be: "it is needed now," probably because HP customers were demanding it, and Dell was getting pissy."

;D

Endorphine

2004-02-17, 21:19:33

Original geschrieben von Sk_Antilles
Das Gute ist, dass bei der Entwicklung von 64bit Software endlich mehr Klarheit geschaffen wurde. Da nun Intel diese Technik unterstützt werden bestimmt viele Softwareentwickler den Weg zu 64bit schneller beschreiten.

Im Endeffekt ist die Nachricht gut für uns alle!

Sk_Antilles Naja. Dass die Entscheidung jetzt fallen würde war ja von vorn herein klar (hab ich zumindest lange genug vorher angekündigt). Es war nur die Frage, für welchen Weg Intel sich entscheiden würde. Hätten sie sich für IA64 entschieden hätte auch Klarheit bestanden.

So ist es natürlich noch besser, da es gar nicht erst zu einem Architekturkrieg kommt (den AMD allein verloren hätte).

pippo

2004-02-17, 21:27:46

Original geschrieben von Endorphine
Das ist der Gnadenschuss für IA64, sehe ich genau so wie reunion. Wenn überhaupt, dann wird IA64 in die Ecke der HPC-Unixrechner abgedrängt. In den Massenmarkt wird IA64 so niemals kommen.

Wahnsinn...

Sehe ich auch so. Bin ja schon gespannt, ob er dort überleben kann. Die Entwicklungskosten wollen ja auch bezahlt werden. Auf die Verkaufszahlen wird sich diese Nachricht sicherlich nicht positiv auswirken

Sk_Antilles

2004-02-17, 21:29:00

Original geschrieben von Endorphine
...
So ist es natürlich noch besser, da es gar nicht erst zu einem Architekturkrieg kommt (den AMD allein verloren hätte).

Umso erstaunlicher ist es, dass Intel sich dazu durchgerungen hat AMD's 64bit Erweiterung zu übernehmen, obwohl sie auch ihr eigenes "Ding" hätten durchsetzen können. Ich glaube im Endeffekt, hat ein es eine ziemlich große Rolle gespielt, dass Microsoft nicht gewillt war ein anderes 64bit OS zu machen und das es ein 64bit Linux für AMD's Erweiterung schon seit längeren gab.
Ich denke mal auch, dass Intel ganz einfach die Sache abwarten wollte wie sie sich entwickelt....

Sk_Antilles

Endorphine

2004-02-17, 21:36:41

Original geschrieben von Sk_Antilles
Ich glaube im Endeffekt, hat ein es eine ziemlich große Rolle gespielt, dass Microsoft nicht gewillt war ein anderes 64bit OS zu machen und das es ein 64bit Linux für AMD's Erweiterung schon seit längeren gab. Windows für IA64 gibt es schon wesentlich länger als Windows für AMD64, bei Linux ebenso. Das war nicht der Grund.

Sk_Antilles

2004-02-17, 21:42:00

Das stimmt schon, aber es gab sag ich mal salopp kein kompatibles MS Office & Co. für den IA64. Ich will also damit sagen, dass man nicht ohne weiteres ein heutiges (also 32bit) MS Office auf ein Windows IA64 zufriedenstellend zum laufen bringen kann.

Sk_Antilles

pippo

2004-02-17, 21:45:09

Genau gesehen gibt es noch kein Windows für AMD64 ;)
Microsoft wird nun wohl auch nichtmehr lange auf sich warten lassen und hoffentlich bald Windows2003 für AMD64 herausbringen.

Mich würde zugerne die Zahl der unentschlossenen Firmen interssieren, die nur gewartet haben, wofür sich Intel entschließt und ob AMD64 Zukunftssicher ist.

Endorphine

2004-02-17, 21:46:15

Original geschrieben von Sk_Antilles
Das stimmt schon, aber es gab sag ich mal salopp kein kompatibles MS Office & Co. für den IA64. Ich will also damit sagen, dass man nicht ohne weiteres ein heutiges (also 32bit) MS Office auf ein Windows IA64 zufriedenstellend zum laufen bringen kann. IA64 ist binärabwärtskompatibel zu IA32. MS Office läuft auf Windows für IA64 ohne Einschränkungen. Gleiches gilt für AMD64.

Stone2001

2004-02-17, 21:56:35

Original geschrieben von Endorphine
Das ist der Gnadenschuss für IA64, sehe ich genau so wie reunion. Wenn überhaupt, dann wird IA64 in die Ecke der HPC-Unixrechner abgedrängt. In den Massenmarkt wird IA64 so niemals kommen.

Wahnsinn...
Du meinst also, dass Intel den Itanium zugunsten des neuen Xeon einstellen wird? Also das Intel jetzt Xeon-Systeme dort einsetzten will, wo heute noch Itanium-Systeme eingesetzt werden?

BTW:
Wie Barret betonte, ist mit der 64-Bit-Erweiterung aber keinesfalls eine Abkehr von Intels eigenen 64-Bit-Prozessoren der Itanium-Reihe verbunden. Diese sollen für größere Server im Enterprise-Bereich insbesondere mit acht und mehr Prozessoren ihren Marktanteil gegen die dort vorherrschenden RISC-CPUs weiter ausbauen.
Für den Itanium wird also sich recht wenig ändern.
Die Xeons und die Itanium werden weiterhin zwei verschiedene Märkte bedienen. Deswegen dürfte die Nachricht keineswegs den Gnadenschuss für die Itanium-Reihe sein.

Gast

2004-02-17, 22:01:10

Lustig, ihr träumt immer noch von der "schönen" IA64 Platform, die die Entwickler im Massenmarkt längst abgelehnt hatten :D

Darkstar

2004-02-17, 22:56:32

Original geschrieben von Endorphine
IA64 ist binärabwärtskompatibel zu IA32. MS Office läuft auf Windows für IA64 ohne Einschränkungen. Gleiches gilt für AMD64. IA64 ist überhaupt nicht kompatibel mit IA32. Intel hat dem Itanium (und Nachfolgern) beide Architekturen in Hardware spendiert. Deswegen kann MS Office ohne Änderungen auf einem Rechner mit solch einer CPU laufen. Demnächst soll die IA32-Implementierung per Software emuliert werden. Damit wäre es dann möglich, auf die Hardware-IA32-Implementierung zu verzichten.

Das wurde in diesem Thread übrigens schon einmal erläutert: Link (http://www.forum-3dcenter.org/vbulletin/showthread.php?s=&postid=1531081#post1531081).

Gast

2004-02-17, 23:22:21

Original geschrieben von Sk_Antilles
Umso erstaunlicher ist es, dass Intel sich dazu durchgerungen hat AMD's 64bit Erweiterung zu übernehmen, obwohl sie auch ihr eigenes "Ding" hätten durchsetzen können. Ich glaube im Endeffekt, hat ein es eine ziemlich große Rolle gespielt, dass Microsoft nicht gewillt war ein anderes 64bit OS zu machen und das es ein 64bit Linux für AMD's Erweiterung schon seit längeren gab.
Ich denke mal auch, dass Intel ganz einfach die Sache abwarten wollte wie sie sich entwickelt....

Sk_Antilles

Sie hatten gar keine andere Wahl. M$ hat Ihnen schon vor über einem Jahr klipp und klar zu verstehen gegeben, dass sie nicht gewillt sind ein weiteres OS außer die IA64 und AMD64 Version anzubieten.
IA64 hatte auf dem Desktop Markt aber keine Chance. Die Entwickler haben es abgelehnt und das Konzept ist zur Zeit mit den heutigen Mitteln auch nicht massentauglich. Es ist schlichtweg sowohl bei der Hardware als auch der Software zu teuer für so einen kritischen Markt, wo die Margen nur sehr gering sind.
Eine weitere Variante bringen konnten sie auch nicht, da es davon von M$ keinen Support gegeben hätte. Also bleib nur AMD64 und Intel hat sich dann eben schweren Herzens dazu durchgerungen.
M$ auf der anderen Seite hat Ihnen die Entscheidung vereinfacht, indem sie Intel zuliebe die WindowsXP AMD64 Version nach besten Wissen und Gewissen rausgezögert haben. So entsteht für AMD kein grosser Vorsprung und Intel kanns gelassen sehen.

Das ist genau das, was ich bereits vor paar Wochen gesagt habe. So ists abgelaufen. Darauf kann man einen lassen. Um ehrlich zu sein kotzt es mich irgendwo an. Es wäre wirklich mal Zeit wenn solche Spielchen unterbunden würden. Eigentlich würde ich es M$ gönnen, dass sie für ihre Hinhaltetaktik mal vernünftige Marktanteile an Linux verlieren. Leider nur ein Wunschtraum. So bleibt der Trost, dass möglichst viele sich ihr XP auf anderem Wege besorgen als im Geschäft.

Endorphine

2004-02-17, 23:32:50

Endorphine

2004-02-17, 23:38:02

haifisch1896

2004-02-17, 23:43:14

@Endo
Stress auf Arbeit? Oder warum wirst Du in letzter Zeit so leicht reizbar?

Quasar

2004-02-18, 00:33:53

Mal abseits der technischen Seite finde ich es moralisch angemessen, daß, nachdem die erste FP-SIMD Erweiterung so gnadenlos plattgedrückt bzw. ignoriert wurde, AMD nun auch mal in den Genuß der Technologieführerschaft kommt.

Intel wird's schon verschmerzen können. So eine Titanic wie den Itanium hätte man sich auf dem Desktop-Markt kaum erlauben können - Man überlege nur mal der "Pentium FX" führt herkömmliche, i.e. 32Bit-Software, nur mit der Geschwindigkeit eines Pentium200 aus und nur mit zwei oder drei Programmen pro Jahr, die speziell auf ihm entwickelt wurden, kann er seine Möglichkeiten ausspielen.

Gast

2004-02-18, 08:15:54

Original geschrieben von reunion
Interresant...
Andererseits ist damit ein großer Vorteil von AMD Prozessoren dahin.

Genau das Gegenteil wird passieren. Alle Software-Firmen wissen jetzt, das AMD64 _die_ Zukunft ist und werden sich mit aller Macht darauf stürzen.

+ Da Intel die 64bit Erweiterung nur bei Servern anbietet werden zumindest im nächsten Jahr (vielleicht sogar bie Ende 2005) alle X86-64bit-Programme auf AMD-Prozessoren entwickelt. AMD gewinnt also extrem viel an Reputation dazu.

HOT@Work

2004-02-18, 09:57:12

...Und in jedem zukünfitgen x86 Prozessor der was taugen soll gibt es dann die AMD64 Technologie, egal ob AMD oder Intel.
Dieser Schlag hat gewaltige Folgen für den Prozessormarkt, weil AMD damit auf einmal den Ruf des ewigen 2. und Nachbauers endgültig loswird.

Ich rall sowieso net, warum hier einige Leute immernoch der Auffassung waren, es hätte eine Chance bestanden, der neue würde IA64 unterstützen *kopfschüttel*, diese Technologie ist vollkommen ungeeignet für den Massenmarkt. Chips sind zu gross, nur durch Chipinterne Emulation abwärtskompatibel usw. Ausserdem würde Intel seine Takt = Leistung Rechnung aufgeben ;)

ShadowXX

2004-02-18, 10:16:06

Original geschrieben von HOT@Work
...Und in jedem zukünfitgen x86 Prozessor der was taugen soll gibt es dann die AMD64 Technologie, egal ob AMD oder Intel.
Dieser Schlag hat gewaltige Folgen für den Prozessormarkt, weil AMD damit auf einmal den Ruf des ewigen 2. und Nachbauers endgültig loswird.

Aber nur wenn Sie endlich mal anfangen vernünftige Werbung zu machen, sonst schafft es Intels Marketing, schneller als du "64-Bit-Prozessor" sagen kannst, es so darzustellen, das es "Ihr" Baby ist....

Schon mal die Pressemitteilungen von M$ und Co. gelesen??
Da steht überall was von 64Bit und das es ja sooooo tol ist, das Intel 64Bit vorstellt...Da steht aber nirgendwo irgendetwas von AMD...

Anders gesagt: Wenn ich nur diese Pressemitteilungen lesen würde und sonst relativ uninformiert wäre, dann würde es mir durchaus so vorkommen, als wenn Intel was völlig neues vorstellt und AMD nix, aber auch gar nix, damit zu tun hat...

Ich bin mal gespannt, welche Antwort die Leute geben, wenn man Sie in ca. 3 Jahren mal fragt, wer den 64Bit in den Desktopmarkt eingeführt hat.......Ich glaube, dass wir dann alle die Antwort der meisten "Normalanwender" kennen...leider...

J.S.Shadow

Gast

2004-02-18, 11:14:49

Wie sich manche freuen hier oder in anderen Foren das Intel jetzt AMD Technology in ihrem Prozessor hat ist mir schleierhaft.

Im endefeckt ist es scheiss egal wer als erstes 64Bit implementiert hatte.

Fact ist einfach das Intel Marktführer ist und auch bleiben wird. Den dem Otto Normal Verbraucher der nunmal die Mehrheit darstellt und mehr Geld bringt als die paar Fanboys und Technikfreaks ist es egal wer zuerst 64Bit hat jeder will einfach nur die größtmögliche Leistung.

Und da nehmen sich die Amd´s und die Intel Prozessoren nicht viel. Der eine ist da schneller der ander da schneller.

Und da wir eh eine so große Fülle an 64 Bit Software haben ...

Wer jetzt glaubt das nur weil AMD zuerst die 64 Bit Technologie in ihrem Prozessor implementiert hat sich die Marktanteile groß verändern werden ist ein Illusionist oder ein Fanboy.

Ich bezweifle nicht das AMD Marktanteile gewinnen wird aber das liegt nicht am 64 Bit Befehlssatz sondern an einem run um guten Produkt.

Bokill

2004-02-18, 11:32:58

Liebesbeziehungen & Tiefe Einblicke
Ich denke vieles ist jetzt klarer geworden... aber diejenigen, die nun leichtfertig sagen "Hab ich doch gleich gesagt", machen es sich zu leicht.

IA64 Fällt nun definiv heraus aus dem Desktop-Markt. Die Zukunft wird zeigen, wie weit x86 den Worstation/Server Markt noch Kanibalisieren wird.

Intel hat sich dankenswerterweise defínitiv gegen eine eigene Variante von IA64x86 entschieden. Im Vorfeld waren da ja noch einige Nebelkerzen...

Aber dieses liegt sicherlich auch daran, dass MS bestimmt nicht für umsonst ein OS für den Itani(c)um entwickelte. Auch jetzt noch sind die Stückzahlen des Itani(c)ums sehr begrenzt, und wer sagt denn dass alle Itani(c)umsysteme mit einem MS-OS bestückt waren? Die mangelnden Stückzahlen für das MS-OS für IA64 waren bestimmt ein ganz starker Grund eben doch die Karte AMD64 zu ziehen.
Es geht um Geld nicht um Liebe!

Reinheit der AMD64 Plattform?
Aber so pur ist die Intellösung auch nicht... SSE3 ist drin!

Aber warum will Intel zuerst nur die Xeon-Variante damit beglücken? Und so ideal scheint es auch nicht zu sein, denn trotz vergleichbarer Stromspartechnik hat AMD "zufällig" nun den Opteron mit deutlich reduziertem Stromhunger vorgestellt AMD stellt Low-Power Opterons vor (http://www.planet3dnow.de/cgi-bin/newspub/viewnews.cgi?category=1&id=1077014275) 30W und 50W, je nach Modellreihe, maximaler Strombedarf.

Selbst bei einem Leistungsunentschieden schlägt so das Pendel Richtung AMD aus.

Die Desktopmodelle sollen aber deutlich später freigeschaltet werden?! Dies bedeutet: Wer nun für AMD64 programmiert, und zwar gegen Geld, der wird primär auf AMD Plattformen programmieren. Sie sind schon jetzt verfügbar. Die Intellösungen sind bisher nur angekündigt.

SSE3 ist zwar eine Waffe, aber sie wird wegen des Zeitfaktors unwichtiger werden.
Vermutlich darf AMD dies dann deutlich zeitverzögert implemetieren (Was teilweise leicht sein wird, da SSE3 in Teilen erst jetzt zu 3DNOW! aufgeschlossen hat, in anderen Bereichen ist SSE3 aber schon eine echte Neuerung).

Dies bedeutet, dass SSE3 auf der 64Bit Ebene fast Zeitgleich von AMD und Intel gebracht werden. Vermutlich wird auf 32Bit-Ebene SSE3 nie den Stellenwert bekommen, wie SSE2 vorher... der 64Bit-Zug zeigt auch jetzt schon seine Schubkraft.

MFG Bokill

PS: Erstaunlich, wie leichtfertig einige den Begriff Fanboy benutzen... ???

PPS: Wo sind die Intelbenches über die Leistungskraft ihrer x86 64 Bit-Lösung ?!

Endorphine

2004-02-18, 12:44:14

http://developer.intel.com/technology/64bitextensions/faq.htm
Q9: Is it possible to write software that will run on Intel's processors with 64-bit extension technology, and AMD's 64-bit capable processors?
A9: With both companies designing entirely different architectures, the question is whether the operating system and software ported to each processor will run on the other processor, and the answer is yes in most cases. However, Intel processors support additional features, like the SSE3 instructions and Hyper-Threading Technology, which are not supported on non-Intel platforms. As such, we believe developers will achieve maximum performance and stability by designing specifically for Intel architectures and by taking advantage of Intel's breadth of software tools and enabling services.

Mehr Info: http://developer.intel.com/technology/64bitextensions/

Gast

2004-02-18, 12:50:00

Original geschrieben von Endorphine
http://developer.intel.com/technology/64bitextensions/faq.htm

Mehr Info: http://developer.intel.com/technology/64bitextensions/

Warum verlinkst du uns irgendein Intel-Marketing-Geblubber(tm) ?(

Endorphine

2004-02-18, 12:55:14

Original geschrieben von Gast
Warum verlinkst du uns irgendein Intel-Marketing-Geblubber(tm) ?( Statt zu spammen hättest du auch einfach lesen können. Dort steht nämlich, dass CT zu AMD64-Code kompatibel ist (und umgekehrt). Um diese konkrete Aussage drückt sich Intel nämlich auf dem IDF. Damit ist es aber offiziell.

Ausserdem sind das keine Marketinginformationen, sondern Entwicklerinformationen. Du solltest erst mal lesen, und _dann_ ein Urteil fällen.

Ich dachte eigentlich, dass ich nicht alles immer kommentieren muss, sondern dass das Forum selbständig in der Lage ist, Informationen auszuwerten...

reunion

2004-02-18, 12:59:30

So wie ich dass sehe hat Intel die einzig richtige entscheidung getroffen...

Der Itanium braucht vielzuviel Cache ist in 32-bit viel zu langsam und kostet ein halbes Vermögen. Hingegen sehe ich keinen einzigen Vorteil von IA64 im Vergleich zu AMD64, Intel könnte nie 500Mio Transitorenchips in den Massenmarkt drücken die auf heutiger Software schneckenlangsam wären während AMD sowohl 32 als auch 64 bit voll in Hardware bescheunigt und dass bei wesentlich weniger aufwand.

Den einzigen Nachteil den Intel dadurch hat ist dass man den sowieso unwirtschaftlichen Itanium begraben kann bzw. weiterhin nur ein Nischenprodukt bleiben wird.

mfg
reu

ShadowXX

2004-02-18, 13:27:28

Weiss eigentlich einer von euch, wer sich diemal den Codenamen dafür "Ausgedacht" hat?? (man sollte eigentlich verbrochen sagen...)

"Clackamas Technology" (dafür steht das CT) ist ja nun wirklich ein Zungenbrecher...und hört sich mehr wie ein Ort in Schottland als ein Vorort in den USA an...

J.S.Shadow

Sk_Antilles

2004-02-18, 14:01:46

Original geschrieben von ShadowXX
Weiss eigentlich einer von euch, wer sich diemal den Codenamen dafür "Ausgedacht" hat?? (man sollte eigentlich verbrochen sagen...)

"Clackamas Technology" (dafür steht das CT) ist ja nun wirklich ein Zungenbrecher...und hört sich mehr wie ein Ort in Schottland als ein Vorort in den USA an...

J.S.Shadow

http://www.theinquirer.net/?article=14187

The presentation was left lying around in cyberspace, and Daniel says the code name for the project is Clakamass, or crack in my ass as AMD jokingly describes it.

;D :asshole:

Sk_Antilles

Stone2001

2004-02-18, 14:38:39

Original geschrieben von Endorphine
Statt zu spammen hättest du auch einfach lesen können. Dort steht nämlich, dass CT zu AMD64-Code kompatibel ist (und umgekehrt). Um diese konkrete Aussage drückt sich Intel nämlich auf dem IDF. Damit ist es aber offiziell.

Es war klar, das Intel es nicht an die große Glocke hängen würde, das die 64bit-Erweiterung kompatibel zu AMD64 ist. Wenn sie es getan hätten, hätte das mich mehr als nur überrascht.
Und ich bin mir sicher, das Intel diese Informationen auf der normalen Homepage auch nicht erwähnt, oder?

Endorphine

2004-02-18, 15:01:10

Original geschrieben von Stone2001
Es war klar, das Intel es nicht an die große Glocke hängen würde, das die 64bit-Erweiterung kompatibel zu AMD64 ist. Wenn sie es getan hätten, hätte das mich mehr als nur überrascht.
Und ich bin mir sicher, das Intel diese Informationen auf der normalen Homepage auch nicht erwähnt, oder? Genau deshalb habe ich die Info ja hier geposted. Das ist ja sozusagen nur "Kleingedrucktes", welches sich in einer FAQ ganz unten versteckt und mit dem Hinweis auf SSE3 abgemildert werden soll.

In Zukunft werde ich wohl wieder alles kommentieren...

ShadowXX

2004-02-18, 15:04:11

Original geschrieben von Endorphine
Genau deshalb habe ich die Info ja hier geposted. Das ist ja sozusagen nur "Kleingedrucktes", welches sich in einer FAQ ganz unten versteckt und mit dem Hinweis auf SSE3 abgemildert werden soll.

In Zukunft werde ich wohl wieder alles kommentieren...

Wie ich schon erwähnte...in spätestens 6 Monaten denkt jeder Intel wäre der erste gewesen und AMD baut "wieder" mal einen Clone....

AMD sollte Ihr Marketing mal überdenken....Und lauter mit den Säbeln rasseln...

J.S.Shadow

TheCounter

2004-02-18, 15:20:56

Was mich interessieren würde, hätte AMD vertraglich verlangen/vorschreiben können das Intel auf den Verpackungen der 64-Bit Prozessoren den Aufdruck "With AMD64-Technology" (Oda so) drucken muss?

Wär doch sicherlich witzig ;D

Hab davon jetzt nicht so viel Ahnung, deswegen frag ich.

Danke :)

SuperHoschi

2004-02-18, 15:56:08

Dann hätte Intel bei SSE & SSE2 das gleiche machen können.
Ergo hebt sich das wieder auf.

Gast

2004-02-18, 15:59:41

Original geschrieben von SuperHoschi
Dann hätte Intel bei SSE & SSE2 das gleiche machen können.
Ergo hebt sich das wieder auf.

Das wäre doch Werbung für AMD gewesen ;)

Gast

2004-02-18, 16:42:05

Was einigen scheinbar total entgeht ist:
intel redet vom Xeon für Servers!
Vom Desktop ist überhaupt keine Rede =)
AMD hat das große Glück endlich mal einen volltreffer zu landen. Der gerade erst angekündigte CG-core könnte da noch eins drauf setzen und locker 3400-3600 möglich machen.
Was noch wichtiger ist: bis jetzt ist kein dramatischer Bug im A64/Opteron aufgetaucht und damit hat er die Feuerprobe bestanden. Beeindruckend!
ISSE3 kann intel jetzt auch nicht mehr AMD verweigern, wovon übrigens ausgegangen wurde!

up

CrazyIvan

2004-02-18, 19:41:53

Wenn ich das mit SSE3 richtig verstanden habe, dann ist es doch seinen Namen eh fast net wert.

Frage mich allerdings auch, ob AMD nich M$ und intel irgendwie rechtlich dazu zwingen kann, "AMD64" auf die Verpackungen zu schreiben. Befürchte halt das gleiche, wie SchadowXX. AFAIR war das ja bei intel mit MMX und SSE so, dass die net wollten, dass AMD das draufschreibt. In diesem Fall wäre es für den Urheber aber willkommene Publicity...

Aber mal davon abgesehen:
Glaubt ihr, dass der Prescott von 64bit Software ähnliche Vorteile haben wird, wie der K8? Ich meine, Kompatibilität != Leistung.

Stone2001

2004-02-18, 19:56:54

Original geschrieben von CrazyIvan
Wenn ich das mit SSE3 richtig verstanden habe, dann ist es doch seinen Namen eh fast net wert.
In Laufe der Zeit, wird SSE3 etwas Wert sein. Zur Zeit gibt es keine Programme, die SSE3 verwenden, also ist SSE3 zur Zeit nutzlos!
Original geschrieben von CrazyIvan
Frage mich allerdings auch, ob AMD nich M$ und intel irgendwie rechtlich dazu zwingen kann, "AMD64" auf die Verpackungen zu schreiben. Befürchte halt das gleiche, wie SchadowXX. AFAIR war das ja bei intel mit MMX und SSE so, dass die net wollten, dass AMD das draufschreibt. In diesem Fall wäre es für den Urheber aber willkommene Publicity...

Ich glaube kaum, das AMD Microsoft und Intel dazu zwingen kann. Anderesrum, wieviel Intel steckt in einem AMD-Prozessor, wahrscheinlich wesentlich mehr, oder?
Original geschrieben von CrazyIvan
Aber mal davon abgesehen:
Glaubt ihr, dass der Prescott von 64bit Software ähnliche Vorteile haben wird, wie der K8? Ich meine, Kompatibilität != Leistung.
Gegenfrage: Warum sollte er sie nicht haben?

Avalox

2004-02-18, 20:26:45

Mal ein ungewöhnlicher Link für ein Prozessor Forum.

Der Spiegel berichtet über die IDF, oder über den interessantesten Teil davon ;).

"Intel trabt AMD hinterher"

http://www.spiegel.de/netzwelt/netzkultur/0,1518,286855,00.html

@Stone2001

Gegenfrage: Warum sollte er sie nicht haben?

Zwar auch wieder eine Frage, aber:
Warum gibt es noch keine Benchmarks, wenn der Chip schon präsentiert wurde?

Stone2001

2004-02-18, 21:07:13

Original geschrieben von Avalox
Zwar auch wieder eine Frage, aber:
Warum gibt es noch keine Benchmarks, wenn der Chip schon präsentiert wurde?
Weil es noch keinen Benchmarks gibt, bei dem man sehen kann, das 64bit viel besser als 32bit ist?
Und außerdem sind die entsprechenden Plattformen noch unausgereift, was auch nicht gerade leistungsförderlich ist.
Intel wird sich hüten Benchmarks vorzuführen, bei denen man nicht ganz klar die Vorteile der neuen Features sehen kann.

CrazyIvan

2004-02-18, 21:18:57

Original geschrieben von Stone2001
In Laufe der Zeit, wird SSE3 etwas Wert sein. Zur Zeit gibt es keine Programme, die SSE3 verwenden, also ist SSE3 zur Zeit nutzlos!

Von der Integration rede ich gar nicht. Ich meine, dass im Speku-Forum vor kurzem mal SSE3 analyisiert worden war. Nur wenige neue Befehle mit wenig Mehrnutzen. Auch c't 04/'04 meinte das. Insofern auch keine große Neuerung und auch nicht der Inkrementierung der Versionszahl würdig.

Ich glaube kaum, das AMD Microsoft und Intel dazu zwingen kann. Anderesrum, wieviel Intel steckt in einem AMD-Prozessor, wahrscheinlich wesentlich mehr, oder?

1. Wieso nicht, wenn sie das patentiert haben, dann dürfen die doch bestimmt auch Urheberrechtsansprüche stellen...
2. Habe nichts gegenteiliges behauptet. Der Punkt ist nur der, dass intel kein MMX, SSE, SSE2 auf Prozessor-Stickern der Konkurrenz sehen wollte und dies auch teilweise juristisch durchsetzte.
Für AMD hingegen wäre es Publicity und somit begrüßenswert.

Gegenfrage: Warum sollte er sie nicht haben?

Weil der K8 im 64-bit Modus mehr Register hat und der Prescott AFAIK nicht?

CrazyIvan

2004-02-18, 21:30:50

Original geschrieben von Stone2001
Intel wird sich hüten Benchmarks vorzuführen, bei denen man nicht ganz klar die Vorteile der neuen Features sehen kann.

Oder zumindest nur bei der Konkurrenz... ^^

Weil es noch keinen Benchmarks gibt, bei dem man sehen kann, das 64bit viel besser als 32bit ist?

Soso. (http://www.anandtech.com/systems/showdoc.html?i=1961&p=3)

Und außerdem sind die entsprechenden Plattformen noch unausgereift, was auch nicht gerade leistungsförderlich ist.

Meinst Du damit auch Linux64???

Avalox

2004-02-18, 21:33:07

@Stone2001

Es geht ja nicht gleich um bunti 3d Marks.

Es handelt sich ja mit dem Xeon CPUs ausschliesslich um professionelle Anwender. Da sollten doch schnell ein paar Spec int oder Spec fp zaubern lassen, zumal man davon ausgehen sollte, dass der geeignete Leser diese auch ein wenig interpretieren kann.
Das wichtigste Ergebnis wäre ja, dass alte 32Bit Software auf einem 64Bit OS (Linux?) immer noch performant ausgeführt werden kann. Ganz im Gegensatz zum IA-64.

Bei IA-64 hatte Intel übrigens ja auch sehr schnell Benches parat.

Es könnte aber sehr gut sein, wie du es auch sagst, dass die 64Bit Benches einfach nicht gut aussehen. Der gerne gezogenen Intel SMT Vergleich mit der Einführung in früheren Xeons, ist da ein wenig doppeldeutig.
HT durchlief ja auch erst evolutionäre Schritte bis es hinreichend funktionierte um es bei Desktops einzuführen.

Alles halt Spekulation. Wenn die ersten aussagekräftigen Benches erscheinen, oder jemand objektives solch einen Xeon in die Hände bekommt, werden wir mehr wissen.

Bin schon auf den Test des Xeon mit AMD64Bit Erweiterung bei Toms Hardware gespannt. Ich bin mir sicher auf den Xeon hat die Welt gewartet.

GloomY

2004-02-18, 21:39:03

Original geschrieben von CrazyIvan
Weil der K8 im 64-bit Modus mehr Register hat und der Prescott AFAIK nicht? Wenn der Prescott kompatibel sein soll, dann muss er diese Register auch besitzen. Wie soll man denn sonst auf ihm x86-64 Code ausführen, der diese Register vorraussetzt?

Übrigends halte ich die Diskussion für relativ :zzz:

pippo

2004-02-18, 21:49:13

Original geschrieben von Stone2001
In Laufe der Zeit, wird SSE3 etwas Wert sein. Zur Zeit gibt es keine Programme, die SSE3 verwenden, also ist SSE3 zur Zeit nutzlos!

Es gibt zur Zeit schon 2 Programme, die SSE3 nutzen. An der Performance änderte sich jedoch nichts

Stone2001

2004-02-18, 21:52:46

Original geschrieben von CrazyIvan
Soso. (http://www.anandtech.com/systems/showdoc.html?i=1961&p=3)
Wo steht in dem Artikel, das 64bit wesentlich besser ist als 32 bit? Die 64bit Version hängt bei den Games erschreckend weit zurück. (BTW: Das sind benches eines FX-51, wer weiß, wie die Zahlen bei Intel wären...)

Original geschrieben von CrazyIvan
Meinst Du damit auch Linux64???
Ich weiß nicht genau, auf wieviel Prozent der Xeon-Workstations Linux läuft... . Hat da irgendjemand Zahlen?

Stone2001

2004-02-18, 21:56:25

@GloomY: Ich denke auch, das die Diskussion hier gerade wenig ergiebig ist und eher ist Spekulationsforum gehört (naja zumindest ein Til der letzten Postings ist doch arg spekulativ).

@pippo: Schon 2 Programme, ok.
Naja, ich bin sicher, das es irgendwann Programme geben wird, die von SSE3 deutlisch profitieren.

Gast

2004-02-18, 22:13:58

Original geschrieben von CrazyIvan
[...]2. Habe nichts gegenteiliges behauptet. Der Punkt ist nur der, dass intel kein MMX, SSE, SSE2 auf Prozessor-Stickern der Konkurrenz sehen wollte und dies auch teilweise juristisch durchsetzte.
Für AMD hingegen wäre es Publicity und somit begrüßenswert.
[...]
Da war die Benennung in AMD64 genau richtig.

PS: Der aktuelle Linux-Kernel ist schon SSE3 fähig, auch wenn nicht so viel bringt wie AMD64.*eg*

PPS:Barrett zufolge ist die neue Intel-Technologie, die unter dem Namen Nocona vermarket werden soll, zu AMDs 64-Bit-Extensions-Technologie "kompatibel". Gemäß Nathan Brookwood, Analyst bei Insight 64 in Saratoga, ist das eine sehr "schöne Formulierung" dafür, dass der Halbleiter-Goliath Intel nun einfach kurzerhand die Technologie des kleinen Silicon-David AMD "nachbaut". (http://www.spiegel.de/netzwelt/netzkultur/0,1518,286855,00.html)Intel wird das wenn, dann als CT aber wohl kaum als Codename für ne Server CPU vermarkten. Immer diese n00b's...;D

Coda

2004-02-18, 22:43:32

http://developer.intel.com/technology/64bitextensions/30083401.pdf

Wurde das schon gepostet? Damit sind wohl sämtliche Zweifel erledigt. Es ist ein 1 zu 1 Kopie von AMD64 + "SSE3"

Ich glaube kaum, das AMD Microsoft und Intel dazu zwingen kann. Anderesrum, wieviel Intel steckt in einem AMD-Prozessor, wahrscheinlich wesentlich mehr, oder?
Bis auf den Befehlssatz haben sie sowieso nichts gemein. Und jetzt "klaut" Intel den Befehlssatz von AMD, also ist das auch nicht besser ;)

Und um x86 reisen würde sich eh niemand, wenn da nicht diese "leichte" Marktdurchdringung wäre

Stone2001

2004-02-18, 22:51:41

Original geschrieben von Coda
http://developer.intel.com/technology/64bitextensions/30083401.pdf

Wurde das schon gepostet? Damit sind wohl sämtliche Zweifel erledigt. Es ist ein 1 zu 1 Kopie von AMD64 + "SSE3"

Nicht direkt! Endo hat ein Link gepostet, der zu diesen PDFs führt. Und damit wir den Guide komplett haben hier noch den 2. Teil: http://developer.intel.com/technology/64bitextensions/30083501.pdf

Coda

2004-02-18, 23:42:14

Ich weiß nicht, aber wenn ich das so durchlese, dann spüre ich so richtig das Zähneknirschen von Intel ;D

drmaniac

2004-02-20, 17:31:17

und heute zu lesen, dass intel 64bit erst fuer 2006 auf dem consumer markt sieht :D die wissen auch nicht ob hue oder hot...

Tigerchen

2004-02-20, 18:24:49

Original geschrieben von drmaniac
und heute zu lesen, dass intel 64bit erst fuer 2006 auf dem consumer markt sieht :D die wissen auch nicht ob hue oder hot...

Na INTeL hat auch mal RAMBUS für den Desktop propagiert. Oder MMX für Spiele. Sollte man also nicht so ernst nehmen was die so alles zu sehen glauben.

BlackBirdSR

2004-02-22, 10:11:07

Original geschrieben von Coda
http://developer.intel.com/technology/64bitextensions/30083401.pdf

Wurde das schon gepostet? Damit sind wohl sämtliche Zweifel erledigt. Es ist ein 1 zu 1 Kopie von AMD64 + "SSE3"

die neueren Steppings (machen wir Versionen draus) der K8 CPUs werden wohl auch SSE3 haben.

Bokill

2004-02-22, 10:51:28

@BlackBirdSR
Jepp! Auf Seite 7

Und da du schon hier bist BlackBirdSR... kennst du schon die Erklärung für die sagenumwobenen 31 Stufen der Pipeline vom Prescott?

Oder noch besser einen Vergleich vom Nordholz zum Prescott?

Da ist mir immer noch nichts weiter bekannt. Von daher neige ich immer noch deiner Theorie zu, dass die Zählweise des Prescotts eine ganz andere ist, als die des Vorgängers!?

Demnach nicht 11 Stufen mehr sondern "lediglich" 4-7 Stufen mehr (Ja nach Ansicht und Zählweise).

Nun ja Marketing...

Flunkern, Lüge, Statistik, Marketing

MFG Bokill

BlackBirdSR

2004-02-22, 11:09:19

Original geschrieben von Bokill
@BlackBirdSR
Jepp! Auf Seite 7

Und da du schon hier bist BlackBirdSR... kennst du schon die Erklärung für die sagenumwobenen 31 Stufen der Pipeline vom Prescott?

Oder noch besser einen Vergleich vom Nordholz zum Prescott?

Da ist mir immer noch nichts weiter bekannt. Von daher neige ich immer noch deiner Theorie zu, dass die Zählweise des Prescotts eine ganz andere ist, als die des Vorgängers!?

Demnach nicht 11 Stufen mehr sondern "lediglich" 4-7 Stufen mehr (Ja nach Ansicht und Zählweise).

Nun ja Marketing...

Flunkern, Lüge, Statistik, Marketing

MFG Bokill

Seite 7 wo?

Was die Pipelinestufen angeht.
Ich hab noch keine Ahnung. Muss aber jetzt dann Essen gehen.
Vielleicht lässt sich nachher was ausgraben. Aber ohne zu wissen was genau noch enthalten ist (IA32e, DMT, LaGrande) ist es wohl unmöglich genaue Aussagen zu machen.

PS: 81507646 meine ICQ# falls du mal lust hast.

Stone2001

2004-02-22, 13:04:39

Original geschrieben von BlackBirdSR
Seite 7 wo?

Würde mich auch mal interessieren.

Benedikt

2004-02-22, 13:59:43

Wird Intel's IA32e(AMD64)-Chip eigentlich HT und 64Bit gleichzeitig unterstützen? Das ist doch in AMD64 nicht festgelegt, oder?

MFG,
BW

CrazyIvan

2004-02-22, 14:17:44

@ Benedikt

Ja, wird er. Spricht auch nix dagegen, da beide Sachen im Grunde nix mit einander zu tun haben.

Bokill

2004-02-22, 19:09:41

Argrg...

Ging um die Bemerkung:

Wurde das schon gepostet? Damit sind wohl sämtliche Zweifel erledigt. Es ist ein 1 zu 1 Kopie von AMD64 + "SSE3"

Intel hat AMD64 Kompatible gebaut, die zusätzlich SSE3 haben... zur Bedeutung von SSE3 habe ich ebenso meine Gedanken formuliert...

MFG Bokill

smasher

2004-02-22, 19:43:12

Moin,
habe ich das jetzt richtig verstanden (kurze zusammenfassung):
1. intel hat eine "eigene" 64 bit erweiterung.
2. diese ist kompatibel zu amd 64bit.
3. diese erweiterung wird in allen neuen intel prozessoren enthalten sein.
4. diese ist schon im prescott enthalten (?)
5. und muß nur noch von intel freigeschaltet werden (?)

ich frage, weil 64 bit der einzige grund wären einen neuen prozessor für mein S478 Board (P4P800Dlx) zu kaufen.

Gruß
Smasher

Bokill

2004-02-22, 19:54:08

1. intel hat eine "eigene" 64 bit erweiterung.
A: Nein. Intel bewirbt zusätzlich SSE3 und SMT (Hyperthreading)

2. diese ist kompatibel zu amd 64bit.
A: Prescotts verstehen AMD64 (wenn freigeschaltet)

3. diese erweiterung wird in allen neuen intel prozessoren enthalten sein.
A: Gilt für den Prescott. Der Itani(c)um ist eine vollständig andere Geschichte.

4. diese ist schon im prescott enthalten (?)
A: Ja!

5. und muß nur noch von intel freigeschaltet werden (?)
A: Ja! (Aber dies wird vermutlich nicht eine simple BIOS-Option sein... siehe Hyperthreadingeinführung von intel)

BlackBirdSR

2004-02-22, 20:01:36

Original geschrieben von Bokill
Argrg...

Ging um die Bemerkung:

Intel hat AMD64 Kompatible gebaut, die zusätzlich SSE3 haben... zur Bedeutung von SSE3 habe ich ebenso meine Gedanken formuliert...

MFG Bokill

Naja, ich schätze mit den 90nm K8 wird auch AMD mit SSE3 an den Start gehen.

Aqualon

2004-02-22, 20:49:01

@smasher:

Von Intel gibt es IA64, das nicht kompatibel zu x86-Code ist und zur Zeit nur von den Itanium-Serverprozessoren verstanden wird. Die 64Bit-Erweiterung, die schon im Prescott schlummern soll, ist zu AMD64 kompatibel (allgemein kann man von x86-64 reden). Die ersten Intel-Prozessoren, die x86-64 offiziell unterstützen werden, sind die Xeon-Prozessoren "Nocona", die im 2. Quartal 2004 auf den Markt kommen sollen (mehr dazu unter http://www.heise.de/newsticker/meldung/44719).

Wann Desktop-Prozessoren von Intel mit x86-64 Unterstützung erscheinen werden, ist soweit noch nicht absehbar und ob Intel den Prescott noch 64Bit-tauglich macht oder die Erweiterung erst mit dem Tejas-Core 2005 freischalten wird, kann auch noch nicht gesagt werden.

Ob es also jemals x86-64 für den Sockel 478 geben wird, steht afaik noch in den Sternen.

Aqua

smasher

2004-02-22, 22:13:21

danke für die antworten.
also für mich heist das erst mal: abwarten und tee trinken....
Gruß
Smasher

Stone2001

2004-02-22, 23:10:57

Original geschrieben von Aqualon
Ob es also jemals x86-64 für den Sockel 478 geben wird, steht afaik noch in den Sternen.

Ich glaube kaum, das dieser Sockel noch eine CPU mit 64bit-Erweiterungen sehen wird. Wenn man bedenkt, das der Sockelwechsel schon mitte des Jahres ansteht. Und es Gerüchte gibt es Intel nicht vor 2005 64bit für den Consumer-Markt anbieten will.

Seraf

2004-02-28, 09:44:22

Hat doch einen Vorteil.

Intel liefert hochoptimierte Compiler für AMD64!
Da der A64 bald alles kann was der Prescott kann (ausser HT) wäre dieser Schritt bestimmt positiv zu sehen.

Tigerchen

2004-02-28, 14:50:19

Original geschrieben von Seraf
Hat doch einen Vorteil.

Intel liefert hochoptimierte Compiler für AMD64!
Da der A64 bald alles kann was der Prescott kann (ausser HT) wäre dieser Schritt bestimmt positiv zu sehen.

Unterschätze INTeL nicht. Deren jetzige Compiler sind so gestrickt daß damit compilierte Programme auf AMD Rechnern kein SSE/SSE2 nutzen! Das wird vielleicht noch "verbessert" weil einige findige Leute das rausgekriegt haben und diese AMD-Sperre auch umgehen können.

CrazyIvan

2004-02-28, 15:10:41

Zumal man nicht behaupten kann, dass zwei CPUs von nem Compiler gleich sstark profitieren, bloß weil beide die gleichen Befehlssätze haben.

Schon allein die unterschiedliche Pipeline-Länge lässt doch den Schluss zu, dass intel in der Hinsicht anders optimieren wird, als AMD.

pippo

2004-02-28, 17:55:08

Original geschrieben von Tigerchen

Unterschätze INTeL nicht. Deren jetzige Compiler sind so gestrickt daß damit compilierte Programme auf AMD Rechnern kein SSE/SSE2 nutzen! Das wird vielleicht noch "verbessert" weil einige findige Leute das rausgekriegt haben und diese AMD-Sperre auch umgehen können.

War das nicht so, dass die auf AMD-Rechnern nichtmal gestartet sind? Glaub kaum, dass da SSE/SSE2 nicht genutzt wird. In bisherigen Benchmarks ist es ja auch genutzt worden

pippo

2004-02-28, 17:57:14

Original geschrieben von Stone2001

Ich glaube kaum, das dieser Sockel noch eine CPU mit 64bit-Erweiterungen sehen wird. Wenn man bedenkt, das der Sockelwechsel schon mitte des Jahres ansteht. Und es Gerüchte gibt es Intel nicht vor 2005 64bit für den Consumer-Markt anbieten will.

Benötigt man für eine CPU-interne 64bit Erweiterung zusätzliche Pins? Für was ?

Stone2001

2004-02-28, 18:04:11

Original geschrieben von pippo
Benötigt man für eine CPU-interne 64bit Erweiterung zusätzliche Pins? Für was ?
Ob man für eine 64bit Erweiterung zusätzliche Pins braucht kann ich nicht beantworten. Die zusätzlichen Pins die Intel mit dem nächsten Sockel einführen will, dienen aber hauptsächlich zur Spannungsversorgung. Irgendjemand hier hat mal behauptet, das die Hälfte der Pins auf Masse gehen.
Und das Intel den Sockel wechseln wird, ist nun schon länger bekannt. Und da Intel sich noch nicht entschlossen hat 64bit für den Desktop-Markt zu bringen, glaube ich nicht, das der Sockel 478 noch 64bit Prozessoren sehen wird. (Ich lass mich aber auch gerne eines Besseren belehren ;) )

GloomY

2004-02-28, 18:38:27

Original geschrieben von CrazyIvan
Zumal man nicht behaupten kann, dass zwei CPUs von nem Compiler gleich sstark profitieren, bloß weil beide die gleichen Befehlssätze haben.

Schon allein die unterschiedliche Pipeline-Länge lässt doch den Schluss zu, dass intel in der Hinsicht anders optimieren wird, als AMD. Jup. Imho entrollt (*) der Intel Compiler Schleifen extensiv (wenn möglich), um die bedingten Sprünge zu vermeiden, weil diese bei einer langen Pipeline tendentiell mehr Performance kosten. Das ist imho übrigends auch der Grund, warum die komplilierten Binaries des Intel Compilers größer sind als z.B. die des GCCs. Die Größe des Codes nimmt einfach durch das Entrollen deutlich zu.

Auch sonst gibt es noch viele andere Unterschiede, wo die Compiler die unterschiedlichen Architekturen von Intel und AMD berücksichtigen müss(t)en.

(*) Was zum Henker ist das deutsche Äquivalent zu "Loop-Unrolling"? :|

mrdigital

2004-02-28, 18:43:42

Schleifenaufdröselung? ;D

zeckensack

2004-02-28, 18:47:24

IMO "abrollen". Der gleiche Terminus ist auch im Klopapier-Sektor offiziell anerkannt ;)

HellHorse

2004-02-28, 18:58:05

Original geschrieben von GloomY
Jup. Imho entrollt (*) der Intel Compiler Schleifen extensiv (wenn möglich), um die bedingten Sprünge zu vermeiden, weil diese bei einer langen Pipeline tendentiell mehr Performance kosten. Das ist imho übrigends auch der Grund, warum die komplilierten Binaries des Intel Compilers größer sind als z.B. die des GCCs. Die Größe des Codes nimmt einfach durch das Entrollen deutlich zu.
<snip/>

-funroll-loops (http://gcc.gnu.org/onlinedocs/gcc-3.3.3/gcc/Optimize-Options.html#Optimize%20Options)?

GloomY

2004-02-29, 03:36:19

Original geschrieben von HellHorse
-funroll-loops (http://gcc.gnu.org/onlinedocs/gcc-3.3.3/gcc/Optimize-Options.html#Optimize%20Options)? Ja, der GCC kann das natürlich auch, jedoch ist die Frage wie stark er dies tut. Der Intel Compiler, der speziell für den P4 entwickelt wird, macht das imho deutlich stärker. Der GCC ist mehr so der Allround Compiler, der zwar prinzipiell auch optimieren kann, aber nicht von vorne herein auf den P4 ausgelegt ist.

Ok, das Klo-Papier-Argument überzeugt ;)

Gast

2006-12-05, 13:18:26

> Da sich nichts wesentliches bei den Athlons
> getan hat, rennen die Chips erst einmal weiter
> hinter den Core 2 Duo hinterher.

Aber nur wenn man die Athlons kastriert (d.h. im 32 bit-Modus) betreibt. Merke die Athlons sind 64bit-CPUs mit einem 32bit "Emulations-Modus", die Intels Core2 sind 32bit-CPus mit 64bit-Erweiterung.

Bis dann

http://www.ppcnux.de/modules.php?name=News&file=article&sid=6717

Absoluter Schwachsinn oder?

BlackBirdSR

2006-12-05, 13:56:50

http://www.ppcnux.de/modules.php?name=News&file=article&sid=6717

Absoluter Schwachsinn oder?

Absoluter Schwachsinn!

Beides sind reinrassige 64Bit CPUs (mit gleicher ISA, nähmlich (ja in bin blöd :D) x86-64), die auch mit vollständiger Kompatibilität im 32Bit Modus betrieben werden können.

Coda

2006-12-05, 14:03:49

Das technische Verständnis der breiten Masse was 64-bit angeht ist immer wieder beachtlich :rolleyes:

MegaManX4

2006-12-05, 14:18:08

Unterschätze INTeL nicht. Deren jetzige Compiler sind so gestrickt daß damit compilierte Programme auf AMD Rechnern kein SSE/SSE2 nutzen! Das wird vielleicht noch "verbessert" weil einige findige Leute das rausgekriegt haben und diese AMD-Sperre auch umgehen können.

Nutzt den irgendwer den Intel Compiler? Oder ist da eher die Microsoft Schiene angesagt?

Tigerchen

2006-12-05, 14:48:57

Nutzt den irgendwer den Intel Compiler? Oder ist da eher die Microsoft Schiene angesagt?

Wenn ich mich recht erinnere wurde der INTEL Compiler "damals" als ich das schrieb gerne genommen um in Benchmarks die blaue Seite ins rechte, strahlend helle Licht zu rücken. Wie es heute ist weiß ich nicht so genau. Nachdem was man so hört sind aber MS-Compiler angesagt.

Gast

2006-12-05, 15:07:39

Bei Intel ist es in der Tat komplett anders.

EMT64 ist nur eine Erweiterung von PAE (Physical Address Extension oder so :-), was selbst wiederum ein ziemlich übler Hack ist.

Siehe hierzu

http://techreport.com/forums/viewtopic.php?t=25433

quelle: http://www.ppcnux.de/modules.php?name=News&file=comments&op=showreply&tid=9046&sid=6717&pid=9045&mode=&order=&thold=#9046

Heeee???

Gast

2006-12-05, 15:24:14

Bei Intel ist es in der Tat komplett anders.

EMT64 ist nur eine Erweiterung von PAE (Physical Address Extension oder so :-), was selbst wiederum ein ziemlich übler Hack ist.Hast du den verlinkten Thread denn mal komplett gelesen oder nur das Anfangsposting angesehen?

Coda

2006-12-05, 15:36:14

EMT64 ist nur eine Erweiterung von PAE (Physical Address Extension oder so :-), was selbst wiederum ein ziemlich übler Hack ist.

So ein Blödsinn.

Ganon

2006-12-05, 15:52:22

So ein Blödsinn.

Die Person da hat einfach nur das gelesen was ihm gefallen hat. Also so die ersten 1-5 Posts ;) Den letzten hat er wohl "übersehen" ;)

Coda

2006-12-05, 15:58:40

Was ist das eigentlich für eine grässliche Webseite? Linux- und PPC-Fanboys in einem Zwinger, oder was?

Massenverblödung für lau?

Gast

2006-12-05, 16:09:01

Ja dort versammeln sich die letzten "Widerstandskämpfer" und verbreiten ihren Schwachsinn. Ab und an verpesten sie noch irgendwelche Blocks... und wenn dann ihre falsche Weltansicht Stück für Stück auseinandergepflückt wird, kommen so Sätze wie:

"Das sind teilweise Professoren die das laut dir von einander abschreiben!!!"
Offensichtlich weist Du auch nichts über den Wissenschaftsbetrieb.
Abschreiben ist da an der Tagesordnung und auch Mittel der Wahl (allerdings muss man die Quelle angeben, sonst gibts Ärger, wenn das rauskommt). Außerdem werden solche Texte eh nicht von den Professoren selbst verfasst, sondern von Studenten, im besten Falle Doktoranden und unter dem Namen des Professors veröffentlicht (der dann, wenn etwas neues drin steht den Ruhm dafür kassiert).

"Oder willst du oder Dirk jetzt ernsthaft behaupten, dass die Professoren keine Ahnung haben und falsch voneinander abschreiben."
Kennst Du die Geschichte mit dem Eisen im Spinat? Da wurde 100 Jahre lang behauptet, dass Spinat das meiste Eisen von allen Gemüsen hat, weil ein Professor mal einen Kommafehler gemacht hat und jeder andere Professor von diesem abgeschrieben hat. Bis dann mal jemand nicht abgeschrieben, sondern nachgemessen hat.

Sorry, aber man braucht eigentlich nur ein wenig Grundlagen-Wissen und ein kleines bisschen Menschenverstand, um zu erkennen, dass ein die Bezeichnung "RISC/CISC-Hybride" völlig absurd und logisch unmöglich ist. Und dass die vereinfachende Bezeichnung "RISC-Befehle" für die Mikro-Operationen in x86er-Kernen völlig daneben und irreführend ist.
Diese irreführende Bezeichnung der Befehle hat zu der absurden Bezeichnung des Prozessortyps geführt. Was wiederum Leute, die gar nichts vom Thema verstehen, dazu veranlasst, zu behaupten, ein x86 sei kein CISC.
http://www.fscklog.com/2006/11/wer_wird_der_nc.html

Gast

2006-12-05, 16:10:16

PS:

Ich sag dazu nur "Was nicht passt, wir passend gemacht"

Ganon

2006-12-05, 17:00:17

Was ist das eigentlich für eine grässliche Webseite? Linux- und PPC-Fanboys in einem Zwinger, oder was?
Massenverblödung für lau?

Ja, so ungefähr. Sie bashten Apple (als damaligen einzigen günstigen PPC-Hersteller). Jetzt nach dem switch bashen sie Apple noch mehr. Und x86 wird sowieso in jeder News runter gemacht. ;)

Achja. Die Playstation 3 ist bei denen ja jetzt das NonPlusUltra da man ja Linux drauf installieren kann UND es ein PPC-Kern ist. ;)

Die Seite bekommt eigentlich meine Empfehlung. Da kann man immer schön ablachen :D

Gast

2006-12-06, 16:55:55

Wie kommst du darauf das es bei Intel anders sein könnte?

Daher vielleicht:

http://www.intel.com/design/processor/manuals/253668.pdf
Seite 9-14 (S.392), Kapitel 9.8.5 Initializing IA-32e Mode.

9.8.5 Initializing IA-32e Mode
On IA-32 processors that support Intel EM64T, the IA32_EFER MSR is cleared on system reset.
The operating system must be in protected mode with paging enabled before attempting to
initialize IA-32e mode. IA-32e mode operation also requires physical-address extensions with
four levels of enhanced paging structures (see Section 3.10, “PAE-Enabled Paging in IA-32e
Mode”).
Operating systems should follow this sequence to initialize IA-32e mode:
1. Starting from protected mode, disable paging by setting CR0.PG = 0. Use the MOV CR0
instruction to disable paging (the instruction must be located in an identity-mapped page).
2. Enable physical-address extensions (PAE) by setting CR4.PAE = 1. Failure to enable PAE
will result in a #GP fault when an attempt is made to initialize IA-32e mode.
3. Load CR3 with the physical base address of the Level 4 page map table (PML4).
4. Enable IA-32e mode by setting IA32_EFER.LME = 1.
5. Enable paging by setting CR0.PG = 1. This causes the processor to set the
IA32_EFER.LMA bit to 1. The MOV CR0 instruction that enables paging and the
following instructions must be located in an identity-mapped page (until such time that a
branch to non-identity mapped pages can be effected).
64-bit mode paging tables must be located in the first 4 GBytes of physical-address space prior
to activating IA-32e mode. This is necessary because the MOV CR3 instruction used to initialize
the page-directory base must be executed in legacy mode prior to activating IA-32e mode
(setting CR0.PG = 1 to enable paging). Because MOV CR3 is executed in protected mode, only
the lower 32 bits of the register are written, limiting the table location to the low 4 GBytes of
memory. Software can relocate the page tables anywhere in physical memory after IA-32e mode
is activated.
The processor performs 64-bit mode consistency checks whenever software attempts to modify
any of the enable bits directly involved in activating IA-32e mode (IA32_EFER.LME, CR0.PG,
and CR4.PAE). It will generate a general protection fault (#GP) if consistency checks fail. 64-bit
mode consistency checks ensure that the processor does not enter an undefined mode or state
with unpredictable behavior.
64-bit mode consistency checks fail in the following circumstances:
• An attempt is made to enable or disable IA-32e mode while paging is enabled.
• IA-32e mode is enabled and an attempt is made to enable paging prior to enabling
physical-address extensions (PAE).
• IA-32e mode is active and an attempt is made to disable physical-address extensions
(PAE).
• If the current CS has the L-bit set on an attempt to activate IA-32e mode.
• The TR must contain a 16-bit TSS.
http://cache-www.intel.com/cd/00/00/14/93/149307_149307.pdf

Intel kann das auch auf Deutsch bzw. Englisch sagen:

"Note that entering IA-32e mode requires enabling PAE."

"For IA-32 processors that support Intel EM64T, paging data structures include a new table in the page-translation hierarchy. The table is called the Page Map Level 4 (PML4) table. The PML4 table sits above the Page Directory Pointer (PDP) table in the page-translation hierarchy. It is used in page translation only when IA-32e mode is activated. It is not used when IA-32e mode is disabled, regardless of whether or not PAE is enabled."

"Intel EM64T expands Physical Address Extension (PAE) paging structures to potentially support mapping a 64-bit linear address to a 52-bit physical address. In the first implementation of Intel EM64T, PAE paging structures are extended to support translation of a 48-bit linear address to a 40-bit physical address. The page-translation hierarchy is shown in Figure 1."

Aber Itel's 64-Bit-Prozessoren haben mit PAE natürlich rein gar nix zu tun.

http://www.ppcnux.de/modules.php?name=News&file=comments&op=showreply&tid=9063&sid=6717&pid=9045&mode=&order=&thold=#9063

Coda

2006-12-06, 17:09:33

Wenn du nichts davon verstehst dann quote so einen Käse auch nicht. PAE ist manuelles Paging. Um in den x86-64-Modus zu wechseln muss vorher zwar PAE aktiviert sein, das wird aber nicht verwendet.

Man sieht einen stinknormalen flachen 64-Bit-Addressraum ohne irgendwelchen Paging-Müll ala PAE.

Gast

2006-12-06, 17:12:43

Ich poste es, weil ich wissen will wie es läuft, damit ich es verstehe! Ist ja nicht mein Mist, den ich gequotet habe. Danke!

Coda

2006-12-06, 17:46:55

Das kommt von ut. Was erwartest du?

Gast

2006-12-06, 18:18:40

Das kommt von ut. Was erwartest du?
ich kenne den nicht so gut.

Um in den x86-64-Modus zu wechseln muss vorher zwar PAE aktiviert sein, das wird aber nicht verwendet.
Wieso muß das über PAE bei Intel laufen im Gegenatz zu AMD?

Ganon

2006-12-06, 18:52:29

Zumal da ja ausdrücklich vom IA32-Modus gesprochen wird... das hat mit dem 64bit-Modus ja wohl nicht viel zu tun. ;)

Coda

2006-12-06, 19:31:05

Nein, da ist schon von x86-64 die Rede (IA-32e wird das bei Intel idiotischerweise manchmal genannt).

Wieso muß das über PAE bei Intel laufen im Gegenatz zu AMD?

Muss es auch bei AMD.

Ganon

2006-12-06, 19:33:16

Ah. Hab das e übersehen... Manchmal schon komisch diese Bezeichnungen ;)

Gast

2006-12-07, 18:36:50

Warum man PAE anknippsen muss, bevor man in den 64 Bit Modus schaltet, lässt sich aus der oben zitierten Reihenfolge sehr schön ablesen. Kurz gesagt: Das Page-Table Layout des 64 Bit Modus ist eine Erweiterung des PageTable Layouts im 32 Bit Modus mit angeschaltetem PAE.

Dieses Layout unterscheided sich erheblich vom dem im 32 bit Modus ohne PAE.
Ein PT Eintrag ist ohne PAE vier Byte groß. Aufgrund der zusätzlichen Addressbits für die größere physikalische Addresse bei PAE reicht dieser Platz aber nicht aus und die Größe eines PT Eintrags mit PAE wächst deshalb von vier auf acht Byte. (Nicht dass davon alle verwendet würden; aber man möchte doch gerne Zweierpotenzen als Größen haben).

Das zieht eine ganze Reihe von Änderungen in der Hierarchie der Page-Tables mit sich. Eine Seite (4kiB) kann nun nur noch 512 statt bisher 1024 PT Einträge enthalten. Genauso die PageDirectory Einträge: Da passen nur noch 512 Stück statt bisher 1024 rein.
Man kann also mit dem bisherigen 2-Level Layout (Directory, Page Table) nur noch ld(512) + ld(512) = 9 + 9 = 18 virtuelle Bits für die Seitennummer verwenden; Man hätte aber gerne wieder alle 2^20 Seitennummern, um den vollen 32 Bit Addressraum benutzen zu können (eine 4kiB Page braucht 12 bits; 32 - 12 = 20). Deswegen hat man bei PAE eine dritte Ebene der Paging-Hierarchie eingeführt (nun also PageDirectoryPointer, PageDirectory und Page Table). Diese dritte Ebene hat aber nur 2^2 = 4 Einträge und ist damit noch nicht voll (512 könnten hinein). Erst im 64 Bit Modus, wo der virtuelle Addressraum nun echt größer als 32 Bit ist, werden die restlichen Einträge der dritten Ebene genutzt (und darüber hinaus noch eine vierte, um den riesigen Addressraum zu füllen).Und bevor jetzt wieder jemand ruft, dass der 64 Bit Modus scheisse sei, wegen der vermeintlichen Nähe zu PAE, der soll sich mal klar machen, dass das einzige, was gleich ist, das Layout der PageTables ist. So Sachen wie mehr Speicher benutzen als virtuelle Addressen vorhanden sind (PAE im 32 bit Modus) mitsamt dem notwendigen Umschalten und dessen Verzögerung wird selbstverständlich im 64 bit Modus nicht verwendet.

GloomY