Archiv verlassen und diese Seite im Standarddesign anzeigen : Sinn und Unsinn von WindowsXP-64
Matti
2004-07-02, 16:13:21
Original geschrieben von zeckensack
Leider wird auch das 64Bit-Windows XP 3DNow nicht mehr unterstützen (und gleichzeitig auch die x87-FPU und Teile von SSE1 über Bord werfen). Einige bejubeln das als "modern", nur mir will sich der dadurch entstehende Mehrwert nicht ganz erschliessen.
...aber ohne FPU läuft fast kein 32-Bit-Programm. Eigentlich müßten 32-Bit-Programme die FPU weiterhin nutzen können, nur 64-Bit-Programmen könnte man es verbieten. Ist dazu schon näheres bekannt?
wxp-64 kann keine 16-Bit-Programme mehr ausführen. Allerdings wird es in den nächsten Jahren weiterhin mehr 16-Bit als 64-Bit-Programme geben.
Und überhaupt habe ich Zweifel am Sinn von 64-Bit. 64-Bit Adressraum ist bei Servern in manchen Fällen sinnvoll, aber ein Privat-Nutzer wird es kaum brauchen. Letztendlich werden viele Programmierer nur dazu verleitet, immer unoptimaler zu programmieren. Diese Tendenz ist ja in den jetzten Jahren schon zu beobachten: Obwohl die Rechner ca 10x schneller sind als vor 5 Jahren, laufen die Programme fast genau so lahm, weil sie immer mehr sinnlos aufgeblasen sind.
Aber zurück zu den 64-Bit: 64-Bit-Berechnungen werden nur äußerst selten benötigt. Abgesehen von den 64-Bit hat AMD die General-Register-Anzahl beim A64 erhöht, was sinnvoll ist und mehr Performance bringt, allerdings sind die neuen Register nur von 64-Bit-Programmen nutzbar. Aber mit SSE2 kann man die 8 SSE-Register auch für INT-Berechnungen (außer Adressierungen) verwenden, womit der letzte bedeutende Grund für 64-Bit auch noch hinfällig ist.
ilPatrino
2004-07-02, 17:20:06
bei 64bit stehen ja auch nicht die 64bit-berechnungen im vordergrund, sondern einige erweiterungen, die durchaus sinn machen
der erweiterte adressraum ist schon sinnvoll, da größere datenmengen (seinen es spiele, berechnungen, simulationen oder cad) nicht mehr auf platte ausgelagert werden müssen. und solche datenmengen haben meist nicht sooo viel mit ineffizienter programmierung zu tun.
mehr register bedeuten auch mehr flexibilität (und damit indirekt auch eine höhere geschwindigkeit aufgrund weniger sortier- und verschiebeoperationen). gpr sind nicht wirklich mit sse-registern zu vergleichen...
echte 16-bit software spielt (zumindest bei mir) keine rolle mehr. win98se ist bei mir (und vielen kumpels) vor jahren von der platte verschwunden. der umstieg von 32- auf 64bit soft ist eigentlich nur ein neuer compilerdurchlauf, wenn einige regeln beachtet wurden - 16bit soft ist entweder ursteinalt oder so speziell, daß der einsatz von 64 bit betriebssystemen sowieso sinnlos wäre. notfalls gibts noch vmware
zum thema fpu - soweit ich das mitgekriegt hab, werden fpu-aufrufe vom system auf die sse-einheiten umgemappt - für bestehende software dürfte sich nix ändern, neue sollte gleich auf sse(2,3,wasweißich) optimiert werden - der simd-ansatz macht bei gegenwärtigen problemen auf jeden fall sinn
p.s. wieso sollte man versuchen, die neuen register trotz aller inkompatibilität (sieht irgendwie komisch aus, das wort) zum standard programmen zugänglich zu machen? zwei 32bit-systeme, die untereinander keine programme austauschen können? macht nicht wirklich sinn, oder? und ein neues os wäre auch so fällig, also fällt dein argument flach
ok, und jetzt zu leuten, die sich mit sowas auskennen :)
BlackBirdSR
2004-07-02, 17:51:22
Original geschrieben von Matti
...
Alle Aufgaben der x87 werden von SSE2 Skalar übernommen.
32Bit Programme werden eh von WOW64 behandelt, und laufen dann auch darauf.
Die Registerzahl wurde nicht auf 8 sondern 16 verdoppelt.
Also 16 GPR für Integer, 16 SSE2 für FPU/SIMD
Im 64Bit Modus liegt der Performancegewinn aller Vorraussicht nach hauptsächlich an der höheren Registerzahl, eventuell ein bischen an SSE2, und ein paar Mal an den Möglichkeit, die 64Bit breite Register eröffnen.
In Sachen Adressierung wird sich zu Beginn wohl wenig tun.
Also Sinn macht es alle Mal, finde ich.
zeckensack
2004-07-02, 19:20:52
Original geschrieben von Matti
<...> Aber mit SSE2 kann man die 8 SSE-Register auch für INT-Berechnungen verwenden, womit der letzte bedeutende Grund für 64-Bit auch noch hinfällig ist.Ach? :|
Dann schreib' doch bitte einen SSE2-Ersatz für
MOV RAX,[RSI+4*RBX]
nemesiz
2004-07-03, 02:09:26
16bit software spielt bei dir keine rolle mehr.. muhaaaa
darf ich mal? ja? :asshole:
mein gudschda.. gugst du disch mal dein XP 2K oder sonst was aus der MS Reihe an und gugschd du mal wieviel von deiner Software / Freeware / Shareware do noch mit 16bit rumschrubblt.
ich wes is schwer zu glauben aber do gibts so viel
selbst teile von office und mein geliebter NAV2004 und.. jup 2005 Beta haben noch lieblich 16bit Teile (liveupdate z.B.)
grakaman
2004-07-03, 07:52:10
Original geschrieben von nemesiz
mein gudschda.. gugst du disch mal dein XP 2K oder sonst was aus der MS Reihe an und gugschd du mal wieviel von deiner Software / Freeware / Shareware do noch mit 16bit rumschrubblt.
16Bit Software läuft unter >= Windows 2000 in einer VM. Deswegen verstehe ich auch nicht, warum man das nicht weiterhin unter WinXP 64Bit emulieren sollen kann.
ich wes is schwer zu glauben aber do gibts so viel
selbst teile von office und mein geliebter NAV2004 und.. jup 2005 Beta haben noch lieblich 16bit Teile (liveupdate z.B.)
Welche Teile von Office >= 2000 sind denn in 16Bit und welche Beta 2005 meinst du?
StefanV
2004-07-03, 08:48:02
Original geschrieben von Matti
64-Bit Adressraum ist bei Servern in manchen Fällen sinnvoll, aber ein Privat-Nutzer wird es kaum brauchen.
Das ist ein Irrglaube, siehe z.B. Morrowind als Beispiel...
Adressraum != installierter Speicher.
Bedenke bitte auch den Virtuellen Speicher auf der Festplatte, der auch addressiert werden muss...
Win64 Bit hat, wenn es funktioniert wie es soll, nur Vorteile und kann daher theoretisch bedenkenlos eingesetzt werden. Der Thread macht einfach keinen Sinn finde ich...
Zum 2.Mal bringt ein Prozessorhersteller endlich mal mehr Register und andere Tiefgreifenden Änderungungen, die nur Vorteilhaft sein können in die x86 Welt und dann wird soch auchnoch darüber beschwert...
eXistence
2004-07-03, 13:03:02
Selbst wenn die Vorteile von 64bit gegenüber 32bit noch nicht sooo gravierend sind: 64bit ist die Zukunft, später wird es defintiv von nöten sein.
Irgendwann muss man halt anfangen umzusteigen. Und dank AMD kann man (wenn man denn wirklich noch kein 64bit will) weiterhin ein reines 32bit-System fahren.
Ich sehe da einfach keinen Nachteil, ganz im Gegenteil: es ist sicherlich einer der besten Wege, eine neue Technologie einzuführen, da sich niemand vor den Kopf gestoßen zu fühlen braucht.
GloomY
2004-07-03, 13:03:37
Original geschrieben von Matti
...aber ohne FPU läuft fast kein 32-Bit-Programm. Eigentlich müßten 32-Bit-Programme die FPU weiterhin nutzen können, nur 64-Bit-Programmen könnte man es verbieten. Ist dazu schon näheres bekannt?Ja. (s.u.)
Original geschrieben von Matti
Ich bin immer offen für sinnvolle Neuerungen, aber im Fall von A64 und wxp-64 wurden nur sinnlos Inkompatibilitäten geschaffen. Was mich an wxp-64 stört, habe ich schon genannt, und beim A64 stört mich, daß man die 64-Bit-Register nicht unter einem 32-Bit-Betriebssystem nutzen kann. Wahrscheinlich sind hier Schmiergelder von MS Schuld, denn die wollen ja wieder ein neues Windows verkaufen. Wie soll denn ein 32 Bit OS, das zumal noch älter ist als der Athlon 64, die 64 Bit breiten Register benutzen? Außerdem wenn es das machen würde, wäre es ja im Übrigen kein 32 Bit OS mehr...
Original geschrieben von ilPatrino
zum thema fpu - soweit ich das mitgekriegt hab, werden fpu-aufrufe vom system auf die sse-einheiten umgemappt - für bestehende software dürfte sich nix ändern, neue sollte gleich auf sse(2,3,wasweißich) optimiert werden - der simd-ansatz macht bei gegenwärtigen problemen auf jeden fall sinnEs geht darum, dass WinXP 64 im 64 Bit Modus die x87 Register bei einem Kontextswitch nicht mehr sichert bzw. wiederherstellt. D.h. wenn in der Zwischenzeit ein anderer Thread die Werte dort verändert, fährt das Programm mit diesen geänderten Werten in den FPU Registern fort. Das kann natürlich dazu führen, dass das Programm falsch rechnet oder sogar abstürzt.
Da jeder Programmierer und Compiler dies verhindern will, darf x87 Code im 64 Bit Modus nicht mehr genutzt werden. Statt dessen soll/kann man die Berechnungen über SSE(2) machen, was ja jeder 64 Bit Prozessor unterstützt. In wie weit das sinnvoll ist, überlasse ich mal den Assembler Experten.
Was jedoch an der Situatution ziemlich unsinnig ist, ist die Ausführung von 32 Bit Software bei WinXP 64 (mit Hilfe von WOW). Hier werden - aus Kompatibilitätsgründen - die x87 Register nun doch wieder gesichert/wiederhergestellt (eben genau so wie bei allen bisherigen Betriebssystemen). Das heisst also, dass auch zukünftige Prozessoren die x87 Befehle nicht weglassen können, wenn sie weiterhin für ältere 32 Bit Software kompatibel bleiben wollen.
Die Idee, x87 durch SSE(2) zu ersetzen, ist rückt damit in weite Ferne. Auch nach dem Umstieg auf 64 Bit wird es weiterhin jede Menge 32 Bit Software geben, welche ausgeführt werden können muss (das ist ja u.a. gerade der Vorteil an x86-64).
edit: Es geht hier im übrigen nicht um SIMD. Das kann x87 sowieso nicht. Es geht um skalares SSE(2) als Ersatz für x87 Befehle.
Matti
2004-07-03, 15:47:39
Original geschrieben von GloomY
Wie soll denn ein 32 Bit OS, das zumal noch älter ist als der Athlon 64, die 64 Bit breiten Register benutzen? Außerdem wenn es das machen würde, wäre es ja im Übrigen kein 32 Bit OS mehr...
beim Umstieg von 16 auf 32 Bit ging's doch auch. 16-Bit-Programme unter einem 16-Bit-Betriebssystem konnten auch die 32-Bit-Register nutzen! ...gut, ist dann zwar kein richtiges 16-Bit-Programm mehr, aber man hat jedenfalls kein 32-Bit-Betriebssystem benötigt.
...oder irre ich mich da???
BlackBirdSR
2004-07-03, 16:02:27
Original geschrieben von Matti
beim Umstieg von 16 auf 32 Bit ging's doch auch. 16-Bit-Programme unter einem 16-Bit-Betriebssystem konnten auch die 32-Bit-Register nutzen! ...gut, ist dann zwar kein richtiges 16-Bit-Programm mehr, aber man hat jedenfalls kein 32-Bit-Betriebssystem benötigt.
...oder irre ich mich da???
Ein Programm, dass für einen 16Bit Rechner geschrieben wurde, kann keine 32Bit Register ausnutzen.
Klar, beim 386 hat man die bestehenden Register einfach verbreitert.
Aber statt EAX wird eben nur AX (16Bit) angesprochen.
Die oberen 16bit fließen nicht mit ein.
Von was du wahrscheinlich sprichts, sind die z.B DOS Extender, mit der man vom Real in den Protected Mode wechseln konnte.
Bei AMD64 kommt aber noch dazu, dass man nicht nur doppelt so breite Register hat, man hat auch noch doppelt so viele.
In IA32 sind nur 8GPRs definiert, und man kann nicht mehr nutzen. Die Breite der Register ist gar nichtmal so der Performancefaktor. Wäre also ziemlich sinnlos, und eh nur ein "Hack" ;)
Matti
2004-07-03, 23:07:59
hab's grad nochmal ausprobiert: 16-Bit-Programme können auf einem 32-Bit-Prozessor definitiv auch die 32-Bit-Register nutzen. Hier das Test-Programm:
.MODEL TINY
.386
.CODE
mov eax,1000000h
shr eax,24
cmp eax,1
jne ende
loop1:jmp loop1
ende:
end
diese Zeilen durch'n TASM geschoben ergibt ein echtes DOS-Programm, das mit einem DOS-Extender nichts zu tun hat. Wenn man die 32-Bit-Register nutzen kann, bleibe es in einer Endlos-Schleife, wenn nicht, beendet es sofort...
...und es blieb in einer Endlos-Schleife!
Was AMD beim A64 fabriziert hat, ist also absichtliche Inkompatibilität! Nur Programme die 64-Bit-Adressraum brauchen, brauchen ein 64-Bit-OS, aber es gibt keine technische Notwendigkeit unter einem 32-Bit-OS die Benutzung der 64-Bit-Register zu sperren!
Das ist dann aber ganz einfach kein 16-bit Program mehr.
Was AMD beim A64 fabriziert hat, ist also absichtliche Inkompatibilität! Nur Programme die 64-Bit-Adressraum brauchen, brauchen ein 64-Bit-OS, aber es gibt keine technische Notwendigkeit unter einem 32-Bit-OS die Benutzung der 64-Bit-Register zu sperren!
Quatsch mit Soße.
Wir sind inzwischen (gott sei dank) bei einem "richtigen" Betriebsystem angekommen, das Multitasking unterstützt.
Wenn du 64 bit breite Register benützen willst muss Windows davon wissen sonst kann es die Register nicht entsprechend bei den Task switches speichern.
Außerdem:
Die 64 bit Breiten Register interessieren für Berechnungen eh keinen. "int" in C/C++ ist z.B. weiterhin 32 bit breit, weil es für 64 bit einfach keine Verwendung gibt.
Es ist und bleibt der 64-bit Addressraum, der notwendig wird und deshalb braucht man auch die breiteren Register um darin Speicheraddressen zu halten.
Ein Betriebssystem von hinten aufzubohren macht doch M$ schon sein Ewigkeiten. Anno 1993/4 Gab es die Win32s für Win 3.11 um dort 32bit Feautures zu nutzen. Win9x ist auch nur ein 16Bit Dos mit 32Bit Aufsatz. WindowsXP 64 wird eben das 32Bit OS mit 64Bit Aufsatz.
BlackBirdSR
2004-07-04, 09:44:12
Original geschrieben von Zool
Ein Betriebssystem von hinten aufzubohren macht doch M$ schon sein Ewigkeiten. Anno 1993/4 Gab es die Win32s für Win 3.11 um dort 32bit Feautures zu nutzen. Win9x ist auch nur ein 16Bit Dos mit 32Bit Aufsatz. WindowsXP 64 wird eben das 32Bit OS mit 64Bit Aufsatz.
Soweit ich das sehe wird das ein 64Bit Windows mit 32Bit Aufsatz (WOW64)
Win9x ist auch nur ein 16Bit Dos mit 32Bit Aufsatz.
Legende. Der Prozessor läuft im Protected-Mode also kann vom 16-bit Modus fast nichts mehr übrig sein (außer paar Speicherbereiche)
Matti
2004-07-04, 16:28:34
Original geschrieben von Coda
Wenn du 64 bit breite Register benützen willst muss Windows davon wissen sonst kann es die Register nicht entsprechend bei den Task switches speichern.
Und wieso geht's bei SSE? ...da hat man auch zusätzliche Register, von denen Windows nichts weiß. Auch unter win95 kannste SSE nutzen und damals hat MS von SSE garantiert noch nichts gewußt.
zeckensack
2004-07-04, 17:01:33
Original geschrieben von Matti
Und wieso geht's bei SSE? ...da hat man auch zusätzliche Register, von denen Windows nichts weiß. Auch unter win95 kannste SSE nutzen und damals hat MS von SSE garantiert noch nichts gewußt. SSE braucht Windows 98.
GloomY
2004-07-04, 18:38:41
Original geschrieben von zeckensack
SSE braucht Windows 98.Jup. 3DNow! geht auch auf Win 95 (oder früher), da die 3DNow!-Register auf die FPU Register gemappt werden. Wenn das OS die FPU Register sichert/wiederherstellt, werden dabei automatisch auch die Inhalte der 3DNow!-Register mitgesichert/hergestellt :)
Matti
2004-07-05, 10:46:46
gut, aber was haltet ihr von der Idee, die SSE-Register auch als General-Register nutzen zu können? ...dann hätte man sogar einen 128-Bit-Rechner, und man könnte 128-Bit-Berechnungen auch unter einem 32-Bit-Betriebssystem machen!
...müßte sich jetzt nur ein Prozessor-Hersteller finden, der das umsetzt :D Hätte Intel eigentlich schon längst auf die Idee kommen können, denn so hätten sie dem A64 die Show gestohlen...
BlackBirdSR
2004-07-05, 10:55:08
Original geschrieben von Matti
gut, aber was haltet ihr von der Idee, die SSE-Register auch als General-Register nutzen zu können? ...dann hätte man sogar einen 128-Bit-Rechner, und man könnte 128-Bit-Berechnungen auch unter einem 32-Bit-Betriebssystem machen!
...müßte sich jetzt nur ein Prozessor-Hersteller finden, der das umsetzt :D Hätte Intel eigentlich schon längst auf die Idee kommen können, denn so hätten sie dem A64 die Show gestohlen...
Wenn du die SSE Register als GPR nutzt, kannst du kein SSE mehr nutzen.
So einfach ist das.
Bei Benutzung von SSE, dann der CPU GPRs wegnehmen ist ne ziemlich dumme Idee :)
128Bit Berechnungen gibt es auch mit den SSE Registern nicht, da die ALUs eben nur 32Bit bzw 64Bit breit sind.
Es bliebe dabei mit 32 oder 64Bit Werten zu arbeiten und diese dann zusammenzurechnen.
Wenns nur so einfach wäre.. wärs langweilig.
Matti
2004-07-05, 11:18:47
Original geschrieben von BlackBirdSR
128Bit Berechnungen gibt es auch mit den SSE Registern nicht, da die ALUs eben nur 32Bit bzw 64Bit breit sind.
Es bliebe dabei mit 32 oder 64Bit Werten zu arbeiten und diese dann zusammenzurechnen.
es wäre aber kein Problem, für die SSE-Register eine 128-Bit-ALU zu machen...
mrdigital
2004-07-05, 11:22:24
Original geschrieben von Matti
es wäre aber kein Problem, für die SSE-Register eine 128-Bit-ALU zu machen...
Die wird riesig ;)
Man kann schon, es ist auch die Frage, was diese ALU alles können soll. Wenn die in einem Takt zwei 128Bit Werte multiplizieren können soll, dann wird sie ziemlich riesig, wenn die ALU aber nur ADD und SUB und CMP kann, dann wird es machbar
BlackBirdSR
2004-07-05, 11:27:44
Original geschrieben von Matti
es wäre aber kein Problem, für die SSE-Register eine 128-Bit-ALU zu machen...
Und warum?
Für welche Aufgaben brauchst du 128Bit Genauigkeit?
Für welche Aufgaben brauchst du 128Bit Werte?
Definiere erstmal so einen Datentyp.
Dann sag der CPU sie soll 128Bit Daten und keine 4x32 / 2x64 in die Register packen.
Dann brauchst du eine 128Bit ALU, natürlich am besten mehrere damit man ausser ADD auch MUL benutzen kann.
Die Datenpfade müssen 128Bit breit werden, und für meine 64Bit Werte/Register liegen die oberen 128Bit der ALUs brach, toll.
SEE kann ich dann nicht mehr nutzen, also könnte ich gleich die GPRs auf 128Bit aufstocken, und alle ALUs und Datenpfade in der CPU 128Bit breit machen.
Wobei wir wieder bei der heiligen Frage wären:
Für was brauche ich 128Bit Datentypen und für was muss ich jedes Atom im Universum adressieren? (ca 2^128)
Es lohnt sich auch auf lange Zeit hinaus nicht.
Darum kam noch keiner auf diese Idee ;)
Matti
2004-07-05, 16:36:41
Dann brauchst du eine 64Bit ALU, natürlich am besten mehrere damit man ausser ADD auch MUL benutzen kann.
Die Datenpfade müssen 64Bit breit werden, und für meine 32Bit Werte/Register liegen die oberen 32Bit der ALUs brach, toll.
...bitte nimm mir diesen Post nicht übel ;)
BlackBirdSR
2004-07-05, 16:57:37
Original geschrieben von Matti
Dann brauchst du eine 64Bit ALU, natürlich am besten mehrere damit man ausser ADD auch MUL benutzen kann.
Die Datenpfade müssen 64Bit breit werden, und für meine 32Bit Werte/Register liegen die oberen 32Bit der ALUs brach, toll.
...bitte nimm mir diesen Post nicht übel ;)
Warum sollte ich dir das übel nehmen? ;)
Nur für die 64Bit lohnt sich der ganze Aufwand.
Für 128Bit lohnt es sich nicht nur, es wird auch überproportional kostspielig.
Original geschrieben von BlackBirdSR
Warum sollte ich dir das übel nehmen? ;)
Nur für die 64Bit lohnt sich der ganze Aufwand.
Für 128Bit lohnt es sich nicht nur, es wird auch überproportional kostspielig.
128Bit.... warten wir mal 10-20 Jahre ;)
Dann vielleicht.
Brillus
2004-07-05, 19:36:11
Geh ehe mal von einer Millarde Jahre aus.
Es geht bei dem BiTerhöhung um die Erhöhung des MAximalen Arbitsspeicher und der wächst bei der erhöhung der Bit-Breite Exponential.
Ich bin mir sicher das man mit 64 bit allen Ram auf der Welt eindeutig Adressieren kann.
mrdigital
2004-07-05, 19:43:16
Original geschrieben von HOT
128Bit.... warten wir mal 10-20 Jahre ;)
Dann vielleicht.
wie SSR schon gesagt hat, es gibt zu wenige Probleme, bei denen 128bit benötigt werden, deswegen lohnt es nicht dafür CPUs zu bauen. Für die wenigen Spezialfälle wirds dann (teure) Spezialchips geben.
Wie gesagt, die 128bit SSE haben nicht viel mit einer 128bit CPU zu tun.
BlackBirdSR
2004-07-05, 19:44:53
Original geschrieben von Brillus
Geh ehe mal von einer Millarde Jahre aus.
Es geht bei dem BiTerhöhung um die Erhöhung des MAximalen Arbitsspeicher und der wächst bei der erhöhung der Bit-Breite Exponential.
Ich bin mir sicher das man mit 64 bit allen Ram auf der Welt eindeutig Adressieren kann.
Und dann sag den leuten ins Gesicht, dass der K8 sogar nur 40Bit Speicher physikalisch adressieren kann, und sie steinigen dich ;)
vBulletin®, Copyright ©2000-2024, Jelsoft Enterprises Ltd.