Archiv verlassen und diese Seite im Standarddesign anzeigen : Laufen 64Bit Optimierungen auch auf einem 32Bit OS?
klumy
2003-12-29, 12:01:13
Laufen 64Bit Optimierungen auch auf einem 32Bit OS?
z.B. eine Art 64bit optimiertes DivX Encoding welches dann auf einem WInXP 32Bit läuft.
Geht das? Oder benötigt man unbedingt ein 64Bit OS.
zeckensack
2003-12-29, 12:18:25
Nein. Geht nicht.
Man kann weder die grösseren Register, noch die sonstigen K8-spezifischen Veränderungen ohne OS-Support nutzen.
klumy
2003-12-29, 13:07:37
OK danke für die Antwort
umgekehrt läuft ein 64bit win-xp auch nicht auf 32bit plattformen oder?
wie sieht es mit 32bit software (auf einem 32bit sys kompiliert) auf einem 64bit os aus?
mapel110
2003-12-30, 12:33:34
Original geschrieben von cos
umgekehrt läuft ein 64bit win-xp auch nicht auf 32bit plattformen oder?
wie sieht es mit 32bit software (auf einem 32bit sys kompiliert) auf einem 64bit os aus?
1.nein, win-xp "64bit edition" wird auch auf 32bit maschinen laufen.(abwärtskompatibel)
2.läuft(abwärts.....) ;)
Original geschrieben von cos
umgekehrt läuft ein 64bit win-xp auch nicht auf 32bit plattformen oder?
wie sieht es mit 32bit software (auf einem 32bit sys kompiliert) auf einem 64bit os aus?
zu 2. laeuft... aber vermutlich langsamer als auf dem gleichen BS als 32 Bit
StefanV
2003-12-30, 13:02:15
Original geschrieben von Odal
zu 2. laeuft... aber vermutlich langsamer als auf dem gleichen BS als 32 Bit
Nö, da die Treiber ja im 64bit Modus laufen können und nur die Anwendungen im 32bit Modus laufen, was theoretisch schon das eine oder ander Prozentchen an Leistung freischaffen könnte...
GloomY
2003-12-30, 17:32:33
Original geschrieben von cos
wie sieht es mit 32bit software (auf einem 32bit sys kompiliert) auf einem 64bit os aus? Läuft genau so wie auf 32 Bit Hardware.
Original geschrieben von mapel110
1.nein, win-xp "64bit edition" wird auch auf 32bit maschinen laufen.(abwärtskompatibel)Das glaube ich nicht. Wie soll denn die 32 Bit CPU Code ausführen, der vorraussetzt, dass die Register doppelt so breit sind? :???:
WinXP für x86-64 wird nur auf x86-64 Prozessoren laufen (können). Alle 32 Bit Prozessoren müssen das mormale WinXP nehmen.
StefanV
2003-12-30, 17:54:44
Original geschrieben von GloomY
WinXP für x86-64 wird nur auf x86-64 Prozessoren laufen (können). Alle 32 Bit Prozessoren müssen das mormale WinXP nehmen.
Was vorraussetzt, daß M$ nicht beide 'Versionen' in den Code quetscht...
GloomY
2003-12-30, 19:31:40
Original geschrieben von Stefan Payne
Was vorraussetzt, daß M$ nicht beide 'Versionen' in den Code quetscht... Selbst wenn sie es machen, dann ist es für 32 Bit Maschinen aber immer noch 32 Bit und nicht 64 Bit Code.
Imho ist das aber auch eine Platzfrage. Man kann nicht jeden Code doppelt auf der Platte hinterlegen, zumal solche Sachen wie WOW64 (Windows on Windows64) bei 32 Bit ja auch keinen Sinn ergibt...
mapel110
2003-12-30, 21:43:46
Original geschrieben von GloomY
Selbst wenn sie es machen, dann ist es für 32 Bit Maschinen aber immer noch 32 Bit und nicht 64 Bit Code.
Imho ist das aber auch eine Platzfrage. Man kann nicht jeden Code doppelt auf der Platte hinterlegen, zumal solche Sachen wie WOW64 (Windows on Windows64) bei 32 Bit ja auch keinen Sinn ergibt...
gloomy, ich denke doch sehrwohl, dass m$ beides in einer 64bit edition supporten wird.
sicher läuft dann auf der 32bit maschine der 32bit code, das ist klar.
Demirug
2003-12-30, 21:55:57
Das hat MS früher nicht gemacht und das werden sie wohl kaum jetzt machen. Die 64 Bit und 32 Bit Version passen auch gar nicht zusammen auf eine CD.
StefanV
2003-12-30, 21:59:58
Original geschrieben von Demirug
Das hat MS früher nicht gemacht und das werden sie wohl kaum jetzt machen. Die 64 Bit und 32 Bit Version passen auch gar nicht zusammen auf eine CD.
Hmmm....
Windows NT4?? ;)
Gabs da nicht mehrere Versionen auf einer CD?? (oder wars zuletzt NT3.51
Bokill
2003-12-30, 22:03:09
32Bit unter 64Bit OS ist bei MS begrenzt.
Schade... aber wenn hier die Suchfunktion aktiv wäre, dann käme unter dem Stichwort Hä?64 so einiges zu Tage.
Leider bewegen sich solche Mitteilungen immer noch auf Alpha und Beta Status...
MS soll aber mitgeteilt haben, dass diesese Mittlersoftware WOW64 zwischen 64Bit OS und 32Bit Programmen nicht mehr 3DNOW! unterstützen soll... dies zeigt dass nicht alles gemacht wird, was machbar ist.
AMD liegt voll auf dem Kurs, da sie seit geraumer Zeit Bibliotheken in das Netz gestellt haben, um SSE2 voll auszunutzen... Langfristig deutet sich so der langsame Tod der X86 FPU an... ganz langsam...
Jedenfalls lauern da bestimmt noch einige hübsche Überraschungen im Programmcode...
MFG Bokill
Demirug
2003-12-30, 22:17:13
Original geschrieben von Stefan Payne
Hmmm....
Windows NT4?? ;)
Gabs da nicht mehrere Versionen auf einer CD?? (oder wars zuletzt NT3.51
Also Multibinary CDs habe ich immer nur als Promo/Evalual - Version gesehen. Im Handel waren die AFAIK nie zu bekommen.
Die letzte Version die noch mehr als X86 konnte war AFAIK NT4.
Original geschrieben von Bokill
AMD liegt voll auf dem Kurs, da sie seit geraumer Zeit Bibliotheken in das Netz gestellt haben, um SSE2 voll auszunutzen... Langfristig deutet sich so der langsame Tod der X86 FPU an... ganz langsam...
Jedenfalls lauern da bestimmt noch einige hübsche Überraschungen im Programmcode...
MFG Bokill
Tod der X86-FPU? Transzendente Berechnungen lassen sich mit SSE1/2/3 kaum durchführen. Irgendwo werden immer Winkel und Exponentialfunktionen gebraucht. Und deren Umschreiben auf SSE-Code bringt nicht die Leistung derX86-FPU
Endorphine
2004-01-13, 08:51:27
Original geschrieben von Demirug
Also Multibinary CDs habe ich immer nur als Promo/Evalual - Version gesehen. Im Handel waren die AFAIK nie zu bekommen. Im Handel nicht, aber beispielsweise über das MSDN. :) Hab hier noch eine MSDN-AA CD von w2k rumfliegen, w2k workstation/server/AS.
Desti
2004-01-13, 14:11:51
Original geschrieben von Demirug
Das hat MS früher nicht gemacht und das werden sie wohl kaum jetzt machen. Die 64 Bit und 32 Bit Version passen auch gar nicht zusammen auf eine CD.
Die Erfindung der DVD sollte doch auch schon bei Microsoft angekommen sein?
Bokill
2004-01-13, 14:23:39
@Zool
Ich schrieb ja auch gaaaanz langsam.
Wer weiss schon was in SSx steckt?
Wäre nett, wenn ein "Codingpapst" etwas zu transzendenten Zahlen SSE und Bibliotheken etwas sagen könnte.
Ich vermute laienhaft, dass so etwas auch über SSE geht... wenn gelungene Bibliotheken drin sind womöglich sogar doch schneller als klassisch über die x86 FPU.
Lasse mich aber gerne belehren, was Mathe angeht habe ich im Häkelkurs gesessen statt Formeln zu lernen ;)
MFG Bokill
zeckensack
2004-01-13, 14:58:48
Ich darf doch?
Sin/Cos kann man selbstredend auch auf Einheiten nachbilden, die nur MUL und ADD können. AFAIK machen die x87-FPUs intern auch nichts anderes. Google fragen: "Taylor series". Jedoch halte ich das Wegfallen derselben für total unnütze Verschlimmbesserung eines funktionierenden Systems.
a)eine explizite Taylor-Serie verbraucht unnötig (sichtbare) Register. Das kann die CPU intern effizienter Regeln.
b)einen Microcode-Sequencer braucht sowieso jede aktuelle x86-CPU, bei weitem nicht nur für die FPU. Warum soll man den nicht auch nutzen?
c)jener MCS hat womöglich Zugriff auf speziell für solche Serien gedachte interne Opcodes und Lookups, die für die Software-Lösung nicht verfügbar sind, und die man auch garnicht verfügbar machen möchte.
Im Grunde genau mein olles Steckenpferd: eine optimale Implementierung wird erst durch umfassende Semantik überhaupt möglich. "Sinus" ist hier die Semantik, und es wäre IMO ein Schuss ins Knie, diese aus reinem Modernitätswahn zu entfernen.
Demirug
2004-01-13, 15:58:21
Der R3XX nutzt zum Beispiel Taylor für Sinus und Cosinus. Denoch gibt es im Shaderassembler eine explizite Sinus/Cosinus Anweisung.
Es gibt fast keine anderen CPUs außer x86 die Operationen wie sin, cos, exp oder ähnliches überhaupt als Instruction haben.
Kann alles durch Bibliotheksfunktionen nachgebildet werden
Übrigens nochmal zu dem Thema. Alle MMX Ops funktionieren auch mit den SSE Registern, also kein Grund zur Sorge
zeckensack
2004-01-14, 10:13:42
Original geschrieben von Coda
Es gibt fast keine anderen CPUs außer x86 die Operationen wie sin, cos, exp oder ähnliches überhaupt als Instruction haben.
Kann alles durch Bibliotheksfunktionen nachgebildet werdenNa und? Microcode und HW-Konstanten sind effizienter als externer Speicher. Wen kümmert's, was andere machen?
Übrigens nochmal zu dem Thema. Alle MMX Ops funktionieren auch mit den SSE Registern, also kein Grund zur Sorge Es gibt SSE-Instruktionen, die nur mit MMX-Registern laufen.
CVTPS2PI
CVTPS2PI
CVTPS2DQ. 4 Werte anstatt 2 ist wohl kaum schlechter
zeckensack
2004-01-14, 17:37:30
Original geschrieben von Gast
CVTPS2DQ. 4 Werte anstatt 2 ist wohl kaum schlechter Das ist SSE2. Soll das nun bedeuten, dass SSE1 ganz wegfällt (und damit fast die gesamte single precision-Fähigkeit), oder dass man nur noch 'ausgewählte' SSE1-Instruktionen nutzen darf, ohne die Multitasking-Sicherheit zu gefährden?
Wie will ein OS das forcieren? Eine SSE-fähige CPU wirft ganz sicher keine "invalid opcode"-Exception, wenn sie auf CVTPS2PI stösst. Ein Albtraum für den Support ...
Und wie geht man mit 'Legacy'-Software um, die auf diese Register angewiesen ist? Kompromisslose Abwärtskompatibilität ist doch die Stärke der AMD64-Architektur.
Gibt's abgesehen von "irgendwie geht's auch ohne" auch ein vernünftiges Argument für diese Änderung? Der gesamte FPU-Kontext (respektive MMX, respektive 3DNow) kostet 82 Byte pro Taskswitch. Die restlichen Register (abzuglich CRs) kosten auf IA32 6*4+8*4+8*16=184 Byte, auf AMD64 4*4+16*8+16*16=400 Bytes. Ganz tolle Idee, hier 82 Bytes einzusparen.
Nein, aber AMD64 hat sowieso SSE2. Und darum geht es ja.
Windows x86-64 hat keinen Support mehr für x87 und MMX; dafür steht dann SSE und SSE2
Sorry für den Doppelpost
Wie will ein OS das forcieren? Eine SSE-fähige CPU wirft ganz sicher keine "invalid opcode"-Exception, wenn sie auf CVTPS2PI stösst. Ein Albtraum für den Support ...
Die x87 Register werden beim task switch nicht mehr gesichert.
Und wie geht man mit 'Legacy'-Software um, die auf diese Register angewiesen ist? Kompromisslose Abwärtskompatibilität ist doch die Stärke der AMD64-Architektur.
Im 32 bit Modus funktioniert x87 noch, das ist kein Problem
Der Grund ist ganz einfach das x87 Steinzeit ist. Das hat bei der Entwicklung einer guten FPU für Intel CPUs lange Zeit Steine in den Weg gelegt. SSE2 ist für Compiler leichter zu optimieren, weil der Stack wegfällt
Ich denke es gab einfach keinen Grund mehr es drinzulassen
zeckensack
2004-01-14, 21:26:57
Original geschrieben von Gast
Die x87 Register werden beim task switch nicht mehr gesichert.
Im 32 bit Modus funktioniert x87 noch, das ist kein ProblemAuf dem 64-bittigen Windows sollen doch aber 32 Bit-Applikation laufen können. Also irgendwie ... ist das ein Widerspruch in sich.
Der Grund ist ganz einfach das x87 Steinzeit ist. Das hat bei der Entwicklung einer guten FPU für Intel CPUs lange Zeit Steine in den Weg gelegt. SSE2 ist für Compiler leichter zu optimieren, weil der Stack wegfälltNatürlich ist SSE angenehmer zu programmieren, als x87. Trotzdem gibt's einen Haufen Software dafür, und die gängigen Compiler produzieren halt standardmässig x87-Code.
SSE2 ist auch für sich gesehen kein vollständiger FPU-Ersatz, es ist ja konzipiert als Ergänzung zu einer vollwertigen FPU - die dann eben nur noch die ganzen Spezialitäten ala LOG, EXP, SIN erledigt.
Und ich bleibe dabei: ein Opcode, auch wenn er intern als Microcode expandiert wird, ist um Welten effizienter als eine Software-Implementierung. Die Sinus-Funktion ist das Paradebeispiel für diese These. Implementier die erstmal in SSE2, inklusive korrektem Handling über den kompletten Wertebereich, nicht nur in [0...2*PI]. So einfach wie oben geschildert ist das nun auch wieder nicht.
Ich denke es gab einfach keinen Grund mehr es drinzulassen Und ich denke es gibt keinen Grund, es sich böswillig verrechnen zu lassen, obwohl die Hardware voll funktionsfähig ist.
Welches Problem wird hier gelöst? Wenn ich scharf drauf bin, meine komplette Software wegschmeissen zu können, kaufe ich mir einen Mac.
Natürlich ist SSE angenehmer zu programmieren, als x87. Trotzdem gibt's einen Haufen Software dafür, und die gängigen Compiler produzieren halt standardmässig x87-Code.
Der MS x86-64 Compiler nicht, wo ist das Problem? GCC kann es auch...
auch wenn er intern als Microcode expandiert wird, ist um Welten effizienter als eine Software-Implementierung
Das ist nicht wahr.
Welches Problem wird hier gelöst? Wenn ich scharf drauf bin, meine komplette Software wegschmeissen zu können, kaufe ich mir einen Mac.
Wie gesagt, du must deine Software nicht wegschmeißen. Im x86 32 bit Modus funktioniert x87 noch. Und da AMD64 sowieso komplett neuen Code braucht, hat man x87 bei Gelegenheit gleich beerdigt
Hier mal ein Auszug aus der AMD64 Porting FAQ von AMD:
Can x87 instructions still be used by 64-bit applications?
64-bit applications cannot use x87 instructions because 64-bit operating systems are not required to preserve the x87 stack across interrupts and context switches. AMD has gone to great lengths to ensure that SSE/SSE2 math library performance and accuracy exceeds that of the x87 instruction set. We anticipate no need to use x87 instructions in 64-bit applications.
vBulletin®, Copyright ©2000-2024, Jelsoft Enterprises Ltd.