Windows XP x64, SIMAp app in 64 bit, wird aber nur in 32bit gerechnet??

Dr.Joe

Vice Admiral Special
Mitglied seit
25.03.2007
Beiträge
503
Renomée
0
Standort
Radebeul (bei Dresden)
  • Spinhenge ESL
Hi,

habe bei mir auf dem Quad jetzt "dank" 4GB RAM auch ein 64bit OS.

Er hat sich auch ganz brav von SIMAP die 64bit Applikation runtergeladen, im Taskmanager sieht man dahinter aber immer noch das *32 stehen.

Weiß jemand woran das liegen könnte?
 
Hab ich mich auch schon gefragt. bei mir das gleiche
 
Also zumindest gibt es eine simap_5.10_windows_x86_64.exe

ob die aber 32 Bit oder 64 nutzt kann ich nicht sagen...
 
Also zumindest gibt es eine simap_5.10_windows_x86_64.exe

ob die aber 32 Bit oder 64 nutzt kann ich nicht sagen...


Das siehst du im Taskmanager, wenn hinter dem Prozessnamen ein "*32" steht, dann wirds als 32bit Prozess ausgeführt.
 
Könnt ihr denn einen Unterschied in der Berechnungszeit feststellen?

Wenn die App doch 64bit ist wird sie schneller sein, falls doch 32bit langsamer sein als eine 32bit App auf einem 32bit-System.
 
Moin
ist unter win 64 langsamer als mit win 32
beim quad mit 3,2 ghz ~ 2-3 credits std/core weniger
 
Moin
ist unter win 64 langsamer als mit win 32
beim quad mit 3,2 ghz ~ 2-3 credits std/core weniger

Gilt auch für den Phenom. Ist zwar bei SIMAP immer schwer zu vergleichen, aber im Schnitt 2CR/Kern weniger würde ich auch sagen. Daher wird SIMAP jetzt wieder mit XP gecruncht ;).

Irgendwie find ich das aber schon merkwürdig. Die meisten Projekte laufen bei mir ja gleichschnell (XP 32-bit / Vista64). Spinhenge läuft bei mir mit Vista64 tendenziell etwas schneller (ca 60sek/WU), ebenso Rosetta. Bei QMC konnte ich keine großen Unterschiede ausmachen. Bei SIMAP würde ich mal sagen, daß der Malus mit Vista 64 knapp 10% gegenüber XP beträgt. Verstehe das, wer will.

BTW: Gibts eigentlich ein Projekt, welches mit Vista64 besonders gut läuft?

Gruß,

Rangoon
 
@Caipi & Rangoon

Ihr vergleicht hier aber Vista mit XP...
 
Ihr vergleicht hier aber Vista mit XP...

Nö, es geht um den Vergleich 32 vs. 64bit. Vista (32-bit) und XP (32-bit) sind bei BOINC gleich schnell.

Anders ist das bei 64-wbit Betriebssystemen. 32-bit Applikationen (somit auch BOINC) werden hier ja nur simuliert - über den Interpreter WoW (Windows over Windows). Genau genommen ist Vista 64 ein vollständig anderes BS als Vista 32. Das gleiche gilt analog auch für XP (64bit und 32bit). Somit ergeben sich natürlich auch Unterschiede bezüglich der Performance. Grundsätzlich sind 64-bit-Anwendungen natürlich immer schneller als 32-bit-Programme (sofern sie ordentlich compiliert werden ;-)).. Auf einem 64-bit OS lauft 32-bit Software allerdings ingesamt gesehen etwas langsamer als auf einem nativen 32-bit BS. Der Interpreter (Übersetzer) benötigt ja auch etwas Zeit. Allerdings gibt es auch einige wenige (32-bit) Anwendungen die auf einem 64-bittigem BS schneller laufen. Das liegt daran, daß ein 64-bittiges Kernel grundsätzlich schneller arbeitet als ein 32-bittiges. Das ganze Windows-Handling ist bei Vista 64 ja auch schneller als bei Vista 32.

Somit ergeben sich meiner Meinung nach auch die (insgesamt gesehen) marginalen Unterschiede bezüglich der Performance der BOINC WUs zwischen 64-bit und 32-bit. Gerade bei SIMAP fällt es jedoch recht stark auf, daß ein 64bit BS (entgegen dem allgmeinen Trend) gegenüber einem 32-bit OS recht stark abfällt. Wobei die Frage ist, ob knapp 10% wirklich soviel sind.

Gruß, Rangoon
 
Zuletzt bearbeitet:
Anders ist das bei 64-wbit Betriebssystemen. 32-bit Applikationen (somit auch BOINC) werden hier ja nur simuliert - über den Interpreter WoW (Windows over Windows).
FALSCH!
WoW macht nichts weiter, als einige bestimmte Aufrufe von API-Funktionen auf andere DLLs umzuleiten um z. B. 32Bit-Anwendungen mit 32Bit-System-DLLs zu versorgen und 32Bit-Anwendungen andere Registry-Bereiche und andere Systemverzeichnisse vorzusetzen. Interpretiert wird da gar nichts, der Code läuft nativ auf der CPU.
Grundsätzlich sind 64-bit-Anwendungen natürlich immer schneller als 32-bit-Programme (sofern sie ordentlich compiliert werden ;-)).
Diese Aussage ist viel zu pauschal.
Auf einem 64-bit OS lauft 32-bit Software allerdings ingesamt gesehen etwas langsamer als auf einem nativen 32-bit BS.
Es würde mich wundern, wenn WoW (übrigens heißt das eigentlich WOW32 und steht für Windows on Windows 32) einen Einfluss auf die Geschwindigkeit hat, der über den Bereich der Messungenauigkeiten hinaus geht.
Der Interpreter (Übersetzer) benötigt ja auch etwas Zeit.
Nö, da WOW32 kein Interpreter, Emulator o. ä. ist.
Das liegt daran, daß ein 64-bittiges Kernel grundsätzlich schneller arbeitet als ein 32-bittiges.
Auch das ist mir zu pauschal. Ein Geschwindigkeitsvorteil ergibt sich weniger daraus, dass die Register doppelt so breit sind, sondern eher daraus, dass die Anzahl der Register größer geworden ist und einige Optimierungen an der Architektur der CPU vorgenommen worden. Das ist aber eher Beiwerk und nicht das was 64 Bit ausmacht und namensgebend ist.
 
Hallo TiKu!

Vielen Dank für deine ausführlichen Erläuterungen ;). Dennoch möchte ich noch einiges hinzufügen.

FALSCH!
WoW macht nichts weiter, als einige bestimmte Aufrufe von API-Funktionen auf andere DLLs umzuleiten um z. B. 32Bit-Anwendungen mit 32Bit-System-DLLs zu versorgen und 32Bit-Anwendungen andere Registry-Bereiche und andere Systemverzeichnisse vorzusetzen. Interpretiert wird da gar nichts, der Code läuft nativ auf der CPU.

Na ja, wenn gewisse Befehle der CPU - wie du sagst - umgeleitet werden, dann läuft das ganze schon mal nicht mehr nativ. Weil es dann ja in meinem Falle (AMD 64) bzw. bei Intel-Prozessoren (EMT64) nicht mehr im eigentlichen Modus läuft ;).

64-bit Anwendungen laufen - wie ich schon sagte - "grundsätzlich" schneller als 32-bittige. Mit diesem "grundsätzlich" meinte ich eben, daß diese auch dementsprechend optimiert sind. Das ist ja vor allem das Problem bei 32-bit-Anwendungen. Diese belegen ja denselben Speicherplatz wie als wenn sie 64-bit Anwendungen wären. Weil eben die zusätzlichen benötigten Restiger mit Nullen vollgemüllt werden Müssen. Genaus aus diesem Grunde belegen ja auch 32-bit-Tasks mit einem 64-bit BS mehr RAM als auf einem nativen 32-bit-BS. Pauschal kann man sagen, daß auch ein 32-bit-Taks auf einem 64-bit-BS ca. 40% mehr RAM belegt. Ich muß hier immer etwas schmunzeln, wenn argumentiert wird, daß man mit einem 32-bit-BS nur 3GB nutzen kann. Nominal gesehen ist das zwar richtig: Real allerdings bedeuten 4GB unter einem 64-bit-BS in etwa dasselbe wie 3GB unter einem 32-bit BS. Ganz einfach deshalb, weil auch 32-bit-Anwendungen (über ein 64-bit-BS) mehr RAM benötigen. Bei 8GB RAM ist das ganze natürlich kein Thema mehr ;).

Was die Geschwindigkeit unter Vista64 angeht: Das ganze ist selbstverstandlich immer subjektiv. Aber dennoch empfinde ich das Windowshandling unter Vista64 als deutlich flotter. Ich bemerkte es besonders bei meinem Notebook. Ist ein FS PA 1538. Das Teil hat einen Turion X2 (1.6GHz) verbaut. Ist also nicht unbedingt der allerflottesten Prozessor. Gerade hier bemerkte ich aber einen deutlichen Geschwindigkeitsverteil bzwischen Vista32 und Vista64. Habe beide BS auf dem Notebook installiert gehabt.

Der Hauptgrund jedoch, warum man auf 64-bit umsteigen (muß) ist der Speicherausbau. 4GB maximaler RAM reicht einfach nicht mehr. Zumal man momentan ja 8GB für 90€ bekommt und die RAM-Hersteller ja auch noch was verdienen möchten. Erstaunlich, daß mittlerweile die Softwareindustrie der Hardware nicht mehr hinterherkommt. Keine Sau kann ordentlich 64-bit programmieren. Obwohl die Infrastruktur ja bereits seit ein paar Jahren bereit steht. Hoffentlich ändert sich das bald.

Grüsse,

Rangoon
 
Na ja, wenn gewisse Befehle der CPU - wie du sagst - umgeleitet werden, dann läuft das ganze schon mal nicht mehr nativ. Weil es dann ja in meinem Falle (AMD 64) bzw. bei Intel-Prozessoren (EMT64) nicht mehr im eigentlichen Modus läuft ;).
Es werden keine CPU-Befehle umgeleitet. Wenn Windows eine ausführbare Datei (nennen wir sie "a.exe") lädt, schaut es erstmal welche Funktionen aus welchen DLLs die Datei benötigt, lädt diese DLLs und verdrahtet die Speicheradressen der Funktionen in dieser DLL fest mit den entsprechenden "Platzhaltern" in "a.exe". Das passiert immer - egal ob a.exe ein 32Bit-Programm ist oder ein 64Bit-Programm. Und es passiert exakt 1x beim Programmstart oder besser gesagt beim Laden des Programms.
Was macht nun WOW64 (WOW32 war Käse, denn das ist das Pendant zu WOW64, welches unter 32Bit-Systemen das Ausführen von 16Bit-Programmen ermöglicht)? Es schaut in dieser Phase, ob "a.exe" ein 32Bit-Programm oder ein 64Bit-Programm ist und lädt je nachdem andere DLLs - für 64Bit-Programme 64Bit-DLLs und für 32Bit-Programme 32Bit-DLLs.
Danach wird die Startadresse von "a.exe" angesprungen und das Programm nativ ausgeführt. Interpretiert wird da nichts.
Was WOW64 auch noch macht: Wenn ein Programm auf bestimmte Systemverzeichnisse oder bestimmte Registry-Schlüssel zugreift, werden einem 32Bit-Programm andere Pfade geliefert als einem 64Bit-Programm. Aber auch hier wird nichts interpretiert. Interpretieren würde bedeuten, dass jeder Befehl des Programms erstmal geprüft und ggf. modifiziert würde und dann der CPU übergeben würde. Das ist aber nicht der Fall. Das Ausführen eines Programms läuft so ab, dass das Betriebssystem erstmal das Programm in den Speicher lädt, den Prozess erzeugt und den ganzen anderen Verwaltungskram erledigt und dann die CPU veranlasst, die Startadresse des Programms anzuspringen. Die Maschinenbefehle werden fortan von der CPU von dieser Adresse gelesen; das Betriebssystem hat da seine Finger gar nicht mehr im Spiel.
 
Zurück
Oben Unten