Archiv verlassen und diese Seite im Standarddesign anzeigen : Frage zu zukünftigen XtensionSets für 64 Bit CPUs?
TITAN>Steel
08.01.2007, 22:38
Hi @all,
Die sog. "Xtension Set" erweiterungen, sind, wenn ich es richtig verstanden habe, bestimmte CPU bereiche, die schon unter 32 Bit Prozessing zum Teil auch 64 Bit Befehle abarbeiten können, allerdings nur ergänzend zum 32 Bit Code, um etwa die schwache ProMegaHerzLeistung des Pentium4 zu "kompensieren"...
Wenn das stimmt... Dann werden doch die SSE & Co. Xtension Sets, durch Vista mittel- und langfristige bedeutungslos, weil sie unter "64Bit only Computing" keine Verwendung mehr finden...
Wenn meine Theorie richtig ist, dann werden wohl auch wichtige Marketing Instrumente wegfallen, deshalb jetzt meine Frage:
Wie werden dann die XtensionSets der 64 Bit CPUs aussehen?
mfg TITANsteel
Hiho,
schick mal nen erklärenden Link zu den sog. "Xtension Sets" mit. Hab das noch nie gehört. Hab den schweren Verdacht, dass das Marketing Geblubber ist.
Bis ich erst mal weiss was das ist behaupte ich mal, dass echtes 64bit besser ist als irgendwas emuliertes unter 32 ;-)
ciao
Alex
Wie werden dann die XtensionSets der 64 Bit CPUs aussehen?
Die kommen in 2*128 Bit wie die SSE-Anbindung beim K8L.
Oder eben unendlich Bit, wie bei DSL und Flatrate, da sind die Bits letzlich unendliche lange, die man so durchs Kabel reinsaugen kann.
Besser ist natürlich SSE5 - da wird die Quadratwurzel aus PI fest verdrahtet sein und der 'große Fermat' in Hardware realisiert sein.
mtb][sledgehammer
09.01.2007, 23:10
Also so wie ich das verstehe gehts bei den Xtension Sets (auch noch nie bewusst gelesen) um SIMD Erweiterungen wie MMX/3Dnow!/SSE(x). Diese SIMD Erweiterungen nutzen 64 bzw. 128 Bit Register und können darauf sogenannte Vektoroperationen durchführen. Das heißt mit einer Operation wird ein ganzer Vektor gleichartig behandelt. z.B. zwei 64 Bit FP Adds oder 4 32 Bit FP Muls oder 8 16 Bit Integer Adds oder .... parallel. Der klare Vorteil ist, dass wenn die Daten so verarbeitet werden können, dass es durch die "parallele" Vektorarbeitsweise sehr schnell ist.
Eine 64 Bit CPU kann Operationen bis zu 64 Bit Genauigkeit durchführen (bezieht sich eigentlich nur auf die ALU), dabei kann sie dort alle ALU Befehle bearbeiten, einige davon gibts in SIMD nicht. Außerdem bedeutet 64 Bit auch eine 64 Bit Adressierung des Speichers, was SIMD Units auch nicht beeinflussen. Ergo: beides hat gewsisse Vorteile und damit wird es in Zukunft sowohl SIMD als auch 64 Bit geben.
TITAN>Steel
11.01.2007, 00:55
[sledgehammer;3028198']Also so wie ich das verstehe gehts bei den Xtension Sets (auch noch nie bewusst gelesen) um SIMD Erweiterungen wie MMX/3Dnow!/SSE(x). Diese SIMD Erweiterungen nutzen 64 bzw. 128 Bit Register und können darauf sogenannte Vektoroperationen durchführen. Das heißt mit einer Operation wird ein ganzer Vektor gleichartig behandelt. z.B. zwei 64 Bit FP Adds oder 4 32 Bit FP Muls oder 8 16 Bit Integer Adds oder .... parallel. Der klare Vorteil ist, dass wenn die Daten so verarbeitet werden können, dass es durch die "parallele" Vektorarbeitsweise sehr schnell ist.
Eine 64 Bit CPU kann Operationen bis zu 64 Bit Genauigkeit durchführen (bezieht sich eigentlich nur auf die ALU), dabei kann sie dort alle ALU Befehle bearbeiten, einige davon gibts in SIMD nicht. Außerdem bedeutet 64 Bit auch eine 64 Bit Adressierung des Speichers, was SIMD Units auch nicht beeinflussen. Ergo: beides hat gewsisse Vorteile und damit wird es in Zukunft sowohl SIMD als auch 64 Bit geben.
Thanx..., sehr fundiert und informativ...
Das die SIMD befehle nicht so weitreichend sind, das der Speicher mit 64 Bit Adressiert werden kann, ergibt sich bei mir auch aus der Tatsache, dass 32 Bit CPUs + SIMD Erweiterung nicht mehr als 4 Gigabyte RAM Adressieren können...
Nun, ich bin kein Programmierer... allerdings habe ich von ALU, Add, Mul bereits bei Grafikkarten Chips gelesen...
danach sind die Register Add, Mul jeweils dafür verantwortlich Vectoren zu Addieren und Skalare zu Mulitplizieren und das Skalarprodukt resultiert immer aus einer Multiplikation, wobei ganze Vectoren lediglich addiert werden können, richtig? ... und das parallel.
...wobei 64 bit Additionen, 128 Bit Multiplikationen, sowie 128 Bit Integer Additionen in SIMD Registern Stattfinden können...
so gesehen, währen dann diese SIMD Register eigentlich Geometrieeinheiten? Welche die Vektoren zwischen den Punkten eines Polygone-Objektes beschleunigt berechnen können? Deren Flächen dann von der Grafikkarte Texturiert werden?
oder bin ich jetzt total auf dem Holzweg?
i_hasser
11.01.2007, 02:29
Also mit den XMM (SSE) und MMX Regs kann man sehr wohl 64bit adressieren, die Register haben nix mit Speicherzugriffen am Hut. SSE2 ist außerdem umfassend genug die x86 FPU (welche 80bit hat) vollständig zu ersetzen, zumindest was single und double precision angeht (32 und 64bit Werte), schon auf IA32. Nur long doubles (80bit) gehen damit afaik nicht.
Die ADD und MUL Sachen bei GPUs sind was völlig anderes, da geht es um ganze Pipelinestufen.
PS Das Wort XtensionSets hör ich so auch zum ersten mal.
TITAN>Steel
11.01.2007, 03:28
i_hasser;3029851SSE2 ist außerdem umfassend genug die x86 FPU (welche 80bit hat) vollständig zu ersetzen, zumindest was single und double precision angeht (32 und 64bit Werte).
Das muss man sich mal überlegen :-) Als intel das SSE2 entwickelt hat, mußte die FPU des P4 extrem schwach gewesen sein. Denn eigentlich ist es ja so, dass sich der CPU an vorhandener Software Orientieren sollte und nicht die Software am CPU.
Kann man generell sagen, das mit einer erhöhung der Rechengenauigkeit immer Leistungseinbußen verbunden sind, die dann durch paralellisierung "kompensiert"
werden?
(meint: mit einem Leistungszuwachs, der die Einbußen durch die erhöhte Genauigkeit ausgleicht und darüber hinaus den Zuwachs theoretisch verdoppelt)
@i_hasser, ich glaube du hattest mal einen Hoch interessanten Artikel über Prozessorarchitektur hier im Forum geschrieben, kann das sein? Muss schon ne ganz weile her sein. Wenn ich mich recht entsinne, war das hier im Forum gepostet, wenn du das warst, oder weißt wer das war, kannst du mir mal den Link posten.
mfg TITANsteel
i_hasser
11.01.2007, 11:22
Meinst du den Artikel zum NX-Bit? http://www.planet3dnow.de/cgi-bin/newspub/viewnews.cgi?category=1&id=1097359873
Das die x86 FPU über kurz oder lang ein Klotz am Bein ist, müsste eigentlich allen Herstellern bekannt gewesen sein. Sprich die Ablösung durch SSE2 (der Unterschied zu SSE1 und 3DNow ist im grunde genommen auch nur, dass SSE2 auch Double Precision kennt, SSE1 und 3DNow nur Single Precision) war wirklich nötig.
Die Spezifikation der x86 CPU stammt noch aus Zeiten, wo Transistoren sauteuer waren und FPUs über 1000DM gekostet haben. Entsprechend hat man damals auch keinen Transistor dafür verschwendet, dass das Ding bequem zu proggen war - hauptsache man konnte die Leistung halbwegs ausnutzen.
TITAN>Steel
11.01.2007, 12:57
Meinst du den Artikel zum NX-Bit? http://www.planet3dnow.de/cgi-bin/newspub/viewnews.cgi?category=1&id=1097359873
Nein. Das war damals ein allgemeiner Artikel zur Architektur des Athlon64 und er war nicht von Nero24 geschrieben, sondern von einem Foren-Member/User, ich dacht du währst das gewesen.
mtb][sledgehammer
12.01.2007, 19:20
Ich schätze, dass der Artikel des Herrn "D'Espice" ;) gemeint ist. Einfach mal in der Sektion CPU oder sonstige Artikel suchen.
SSE2 ist außerdem umfassend genug die x86 FPU (welche 80bit hat) vollständig zu ersetzen, zumindest was single und double precision angeht (32 und 64bit Werte), schon auf IA32. Nur long doubles (80bit) gehen damit afaik nicht.
Die 80bit-Genauigkeit ist ja auch eine Spezialität der x87-Architektur und in den üblichen IEEE-Standards nicht vorgeschrieben. Und war es nicht so, dass in Vista (zumindest 64bit) die x87 nicht mehr genutzt wird, sondern nur noch SSE2?
Die 80bit-Genauigkeit ist ja auch eine Spezialität der x87-Architektur und in den üblichen IEEE-Standards nicht vorgeschrieben. Und war es nicht so, dass in Vista (zumindest 64bit) die x87 nicht mehr genutzt wird, sondern nur noch SSE2?
Problem ist ja nicht Vista, sondern ältere Software, die x87 oder MMX noch aufruft.
Vista muss dies also beim Taskwechsel berücksichtigen.
Treiber oder das OS selbst düften bei Vista sich an modernen CPUs orientieren, da nur die auch sinnvoll für Vista geeignet sind.
Allerdings spricht M$ von CPUs ab 1 GHz, da war SSE2 noch nicht allgemein gültig - http://www.wcm.at/story.php?id=9927
Bin zu faul zum Nachschaun, aber ists nicht wirklich so, dass es x87 unter nativem long-Mode von AMD64 nicht mehr gibt, also alles mit SSEX läuft?
Bin zu faul zum Nachschaun, aber ists nicht wirklich so, dass es x87 unter nativem long-Mode von AMD64 nicht mehr gibt, also alles mit SSEX läuft?
Vista ist kein 64 Bit OS - außer in der speziellem 64 Bit Edition, die aber 2007 nur eine Randbedeutung hat - s. http://uk.theinquirer.net/?article=36938
Aber auch unter dem 64 Bit Vista müssen ältere Programme laufen, also eine Registerrettung so etwas berücksichtigen.
Vista ist kein 64 Bit OS - außer in der speziellem 64 Bit Edition, die aber 2007 nur eine Randbedeutung hat - s. http://uk.theinquirer.net/?article=36938
Aber auch unter dem 64 Bit Vista müssen ältere Programme laufen, also eine Registerrettung so etwas berücksichtigen.
??? Schön, dass wir dauernd aneinander vorbeireden. Das nur die 64bit-Edition von Vista auch 64bit ist, ist mir auch klar.....*lol*
Darum ging es mir aber nicht. Mir gings darum, dass ich meine mal gelesen zu haben, dass im 64bit-long-Modus der AMD64-Prozessoren überhaupt keine x87-Einheit mehr existiert. Dementsprechend können reine 64bit-Programme auch keine x87-Befehle mehr haben, nur noch SSE2. Und das hätte ich gerne von den Prozessor/Compiler-Cracks hier bestätigt bekommen.
Im Kompatibilitäts-Modus, den z.B. Vista64 für 32-bit Programme anschmeißt, gibts natürlich auch noch eine x87, insofern kein Problem.
edit: hab grad mal ein wenig in den AMD-Papers rumgeschaut. Also es gibt weiterhin x87 im 64bit-long-mode, wie man hier http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/24592.pdf auf z.B. Seite 237 (seite 269 des pdf) sehen kann. Dann ists wohl doch nur so, dass MS bei 64bit auf x87 verzichtet. Und eine Registerrettung muss eh vollständig ablaufen, wenn man den 32bit-compatibility-mode im long-mode nutzt.
.
EDIT :
.
Das muss man sich mal überlegen :-) Als intel das SSE2 entwickelt hat, mußte die FPU des P4 extrem schwach gewesen sein.
Das eine hat mit dem anderen erstmal nichts zu tun. Hauptvorteil der SIMD-Instruktionen ist, dass ein Befehl gleichzeit auf, im Falle von SSE, 4 Datensätze losgelassen werden kann. Nichts anderes heißt ja Single Instruction Multiple Data! Das ist eine grundsätzlich andere Herangehensweise als die FPU. Wenn die einzelne Addition bzw. Multiplikation in der SIMD-Unit und der FP-Unit gleich schnell laufen, dann ist SIMD viermal so schnell, sofern man halt 4 Datensätze hat, auf die man die Operation ansetzt.
Wie in meinem obigen Post geschrieben, wird bei vielen 64bit OS sogar die x87 langfristig durch SSE komplett ersetzt, was auch die Empfehlung von AMD ist.
Dementsprechend können reine 64bit-Programme auch keine x87-Befehle mehr haben, nur noch SSE2.
...
Wie in meinem obigen Post geschrieben, wird bei vielen 64bit OS sogar die x87 langfristig durch SSE komplett ersetzt, was auch die Empfehlung von AMD ist.
ALLE x64 CPUs haben auch SSE2 ff., also benötigt man keine x87 im 64 Bit Modus mehr.
Aber alle CPUS müssen noch x87 im 32 Bit Modus auführen können wg. Kompatibilität.
Im Prinzip könnte man sicherlich die x87 Befehle einfach (ggf. langsamer) emulieren und diese Hardware zukünftig einsparen.
Aber so ein Umsetzen bedeutet Ingenieur- und Teststunden für ein kaum noch genutztes Feature einsetzen.
raven-666
17.01.2007, 22:48
Aber so ein Umsetzen bedeutet Ingenieur- und Teststunden für ein kaum noch genutztes Feature einsetzen.
so wird ingenieur und teststunden halt für die immer "noch notwendige" implementierung ausgegeben.... .was ist sinnvoller/besser?
so wird ingenieur und teststunden halt für die immer "noch notwendige" implementierung ausgegeben.... .was ist sinnvoller/besser?
Auf x87 kann zumindest AMD definitiv nicht verzichten.
So wurde sogar im virtuellen Modus eine 16 Bit Umgebung in Hardware definiert, die natürlich auch mit x87 Anweisungen rechnen muss. http://www.tecchannel.de/technologie/prozessoren/432777/index10.html
Die x87 Hardware kann also nur verschwinden, wenn sie als Emulation z.B. in der SSE landet. AMD hat zwar beim K8L an dem FPU-Design gearbeitet, aber letzlich 'nur' eine zweite SSE integriert. Vielleicht mutiert aber 2008 im Zuge der kompletten Virtualisierung von I/O auch gleich die frühere exteren Unit zu einer virtuellen und emulierten x87.
Auf jeden Fall werden und sollten die Ingenieure gnadenlos auf Kompatibilität achten.
Es gibt im Fundus von AMD sicherlich zig Killer-Applikationen, die die einzelnen Komponenten jeweils brutal fordern. Wenn eine CPU jene kompatibel übersteht klappts auch im Alltag.
Ich tippe mal, jener 'Paged Real Mode' ist auch nur deshalb entstanden, da man so alte Härtetest-Software für die CPU-Innereien auch unter einem komplexen OS zum laufen bekommt.
Ich wollte doch die x87 überhaupt nicht abschaffen! Der Threadersteller fragte, ob nicht SSE und co unter 64bit-System bedeutungslos wird, und ich wollte das Gegenteil zeigen. Dass man, insbesondere für "Legacy-Programme" zumindest eine logische x87-Einheit (wie auch immer die in Hardware aussieht) auch in 10 Jahren noch finden wird, ist schon klar.
HenryWince
18.01.2007, 11:19
@larsbro
hab grad mal ein wenig in den AMD-Papers rumgeschaut. Also es gibt weiterhin x87 im 64bit-long-mode, wie man hier http://www.amd.com/us-en/assets/cont...docs/24592.pdf auf z.B. Seite 237 (seite 269 des pdf) sehen kann. Dann ists wohl doch nur so, dass MS bei 64bit auf x87 verzichtet.
Für den Verzicht auf x87/MMX/3dNow gibt es aus Betriebssystemsicht einen sehr guten Grund: Die Rettung der FPU/MMX Register benötigt unnötig viel Zeit beim Kontextwechsel. Durch SSE2 kann man funktional auf die FPU verzichten.
MS verbietet zwar die Nutzung dieser Features, sichert aber zumindest unter XP64 den x87 Kontext auch für native x64 Applikationen weiterhin. Wie lange das noch so bleibt steht in den Sternen. Im Kernel Mode geschieht das definitv nicht! D.h. ein x64 Treiber der x87 Code enthielte brächte das System zum Absturz.
Unter Linux 64 Bit ist die x87 FPU längst schon Geschichte.
edit: Das gesagte gilt nur für native 64 Bit. Für 32 Bit Systeme bzw Andwendugen die im Compatibility Mode laufen ändert sich nix.
MS verbietet zwar die Nutzung dieser Features, sichert aber zumindest unter XP64 den x87 Kontext auch für native x64 Applikationen weiterhin. Wie lange das noch so bleibt steht in den Sternen. Im Kernel Mode geschieht das definitv nicht! D.h. ein x64 Treiber der x87 Code enthielte brächte das System zum Absturz.
Microsoft dürfte hier an Software gedacht haben, die einfach als Source-Core neu für 64 Bit compiliert wird.
Wenn da im Code doch noch x87 verwendet wird (in irgendeiner uralten sub) muss das eben auch berücksichtigt werden.
Ist aber letzlich Pfusch, denn so muss man sich um die Register wieder kümmern.
Inwieweit diese Einheiten unter vista 64 noch verwendung finden wäre wirklich interessant. Gibts da Progs mit denen ich das mal testen könnte? Habe nämlich Vista64 in Betrieb und 16bit Anwendungen scheinen nicht mehr zu funktionieren. Zumindest gibt es dementsprechende Fehlermeldungen...
gruß
cumec
HenryWince
18.01.2007, 20:07
Yep, Vista ist nicht 16 Bit Kompatibel. Der OS Kompatibilitäts-Layer (WoW64 = Windows on Windows64) unterstützt nur 32 Bit Anwendungen. Technisch wäre 16 Bit Kompatibilität machbar.
Yep, Vista ist nicht 16 Bit Kompatibel. Der OS Kompatibilitäts-Layer (WoW64 = Windows on Windows64) unterstützt nur 32 Bit Anwendungen. Technisch wäre 16 Bit Kompatibilität machbar.
Was soll das denn? hab selbst noch ein oder 2 wichtige 16bit programme hier am laufen!
Habe nämlich Vista64 in Betrieb und 16bit Anwendungen scheinen nicht mehr zu funktionieren. Zumindest gibt es dementsprechende Fehlermeldungen...
gruß
cumec
Das ist aber schon länger bekannt, dass 16 Bit DOS, Windows oder OS/2 Anwendungen unter 64 Bit Windows nicht mehr laufen.
http://www.planet3dnow.de/artikel/diverses/wow64/index.shtml
16 Bit Real Mode Programme (DOS) laufen generell nicht im 64 Bit Mode, 16 Bit Protected Mode Anwendungen (Win16) währen zwar möglich, wird von M$ aber nicht unterstützt.
http://www.planet3dnow.de/artikel/diverses/64bitpreview/index.shtml
http://www.planet3dnow.de/artikel/diverses/64bitpreview/images/hammer_modi.png
.
EDIT :
.
Was soll das denn? hab selbst noch ein oder 2 wichtige 16bit programme hier am laufen!
Es ist zumindest so dokumentiert, dass das nicht mehr gehen soll. Es gibt ja einen gewissen 16 Bit Support (wegen ein, zwei weitverbreiteter 16 Bit Setup-Programme), aber eben undokumentiert. Wahrscheinlich, um sich den Kundensupport an dieser Stelle zu sparen.
Sind das Konsolen-Programme?
nö... grafisch.
16 Bit Windows Programme sollen nicht laufen. Tatsächlich tun es manche offensichtlich doch.
Dafür soll es (gerüchteweise) 32 Bit Programme geben, welche dagegen wirklich nicht laufen. ;)
Was soll das denn? hab selbst noch ein oder 2 wichtige 16bit programme hier am laufen!
Wo ist das Problem? Dafür lässt man ein XP oder früher auf einer Partition und gut ist. Die Kompatibilität wird eh schon viel zu weit getrieben IMHO.
lol das is keine Endanwendung! das programm unterstützt mich beim spielen übers internet, bzw. befähigt mich erst dazu.
16 Bit Windows Programme sollen nicht laufen. Tatsächlich tun es manche offensichtlich doch.
Dafür soll es (gerüchteweise) 32 Bit Programme geben, welche dagegen wirklich nicht laufen. ;)
a) 16 Bit - hier war Microsoft einfach zu faul einen Emulator zu programmieren. Wahrscheinlich wollte man somit die Weiterexistenz von DOS wieder unterlaufen, denn es gibt noch (zuviele für M$ ) viele DOS-Anwendungen in freier Wildbahn.
b) Wenn ein 32 Bit Programm nicht funktioniert, dann entweder wg. irgendwelchen 16 Bit Altlasten inside oder haarsträubenden Verstößen gegen Programmierregeln.
Kandidaten für Inkompatibilitäten sind sicherlich ältere Microsoft Officeprodukte, da Microsoft sich nie an eigene Designregeln hielt sondern fleißig patchte.
Bei Office 97 auf x64 könnte ich mir zig Ansätze für einen Crash vorstellen, da soviel bei einer Office 97 Installation verändert wird, daß x64 schon mangels brauchbare dll untergeht.
Generell sollte M$ natürlich für umfassende Kompatibilität sorgen. Dafür wäre aber eine gute Emulation wichtiger als die Abbildung weiterer Inkonsistenzen in 64 Bit.
Man sollte sich Windows aber weniger als strukturiertes Design, denn als die größte Bastelkiste im Universum vorstellen. Was von außen betrachtet machbar erscheint kann in jenem Chaos-OS an hunderten von Patch-Punkten Probleme bereiten.
Microsoft hat auch geradezu die Inkompatibilität gepflegt um Emulatoren Dritte für Windows auch so zu blockieren.
lol das is keine Endanwendung! das programm unterstützt mich beim spielen übers internet, bzw. befähigt mich erst dazu.
Was ist das denn für ein Krampf? Sicher dass das ein 16 Bit Windows-Programm ist?
@rkinet
Ein Beispiel für solch eine schlampige Programmierung ist z.B. Skype. Bekomme beim starten eine Fehlermeldung bzgl. 16bit. Aber funktionieren tut es trotzdem. Warscheinlich funktioniert einfach eine bestimmte komponente nicht...
gruß
cumec
Was ist das denn für ein Krampf? Sicher dass das ein 16 Bit Windows-Programm ist?
ja.. eigentlich schon... (also nich von windows, sondern für windows)
allerdings hab ich grad gesehn, dass es seit kurzem ne 32bit version gibt.
Die kommen in 2*128 Bit wie die SSE-Anbindung beim K8L.
Oder eben unendlich Bit, wie bei DSL und Flatrate, da sind die Bits letzlich unendliche lange, die man so durchs Kabel reinsaugen kann.
Besser ist natürlich SSE5 - da wird die Quadratwurzel aus PI fest verdrahtet sein und der 'große Fermat' in Hardware realisiert sein.
walljumper
25.01.2007, 17:33
oder man baut gleich ne Vector CPU als coprozessor ein.
Besser ist natürlich SSE5 - ....
Noch besser SSE6 - in der Paris Hilton Sonderedition.
Dann werden Spine-Funktionen in echt weicher Hardware umgesetzt.
SSE war schon immer sehr wichtig - wie der 'gigantische' Vorsprung des SSE3 Prescott Heizlüfte vor diesen lauwarmen K8-Cores.
oder man baut gleich ne Vector CPU als coprozessor ein.
Natürlich sinnvoll. aber Microsoft würde die genauso lasch unterstützen wie 64 Bit.
------
Windows Vista - lauffähig ab Pentium 1 mit 64 MB RAM, 1 GB-USB-FlashStick und 10 GB-Festplatte ... oder ?
vBulletin® v3.8.7, Copyright ©2000-2012, vBulletin Solutions, Inc.