PDA

Archiv verlassen und diese Seite im Standarddesign anzeigen : 64 Bit = Doppelter Speicherbedarf?


Jesus
2005-02-05, 11:20:54
Siehe Thema. Kann man das so pauschal immer sagen ?

Hab gestern mal Windows XP x64 installiert und dazu das .Net Framework 2.0beta 64bit.

Dann hab ich ein kleines C# Programm geschrieben dass nur 2 Schleifen durchläuft und dabei 2 long Zahlen addiert.

Der Speicherbedarf der exe war im Taskmanager dann etwas über 19000kb, die Ausführungszeit beträgt ca. 15,3 sekunden.

Dann hab ich dasselbe im 32 bit Windows kompiliert und als Ausführungszeit genau 15,3 Sekunden bekommen, allerdings werden hier nur etwas über 9000 kb an Speicher verbraten.

Das 64 bit etwas mehr Speicher benötigen war klar, aber 100% mehr ? Oder liegt das an dem noch unfertigen(?) MS compilern ? Ansonsten wär das ganze nämlich irgendwie sinnlos IMO.

Demirug
2005-02-05, 11:39:46
Warum hast du das ganze eigentlich neu kompiliert?

Primär brauchen nur die Zeiger mehr Speicher alles andere bleibt unverändert.

Es ist aber durchaus denkbar das das .Net Framework sich auf 64 Bit Manschinen gleich mal ein grösseres Workingset erzeugt. Ebenfalls denkbar ist das die verwendetene Frameworks auf einem unterschiedlichen Stand sind. Was ich damit sagen will ist das du dir mit dem Framework eine zusätzliche unbekannte an Board geholt hast die aber starke Auswirkung auf den durch eine Applikation angeforderten Speicher hat.

Jesus
2005-02-05, 11:44:45
Warum hast du das ganze eigentlich neu kompiliert?


Weil es zwei verschieden Targets gibt x64 und x86. x64 läuft nicht im 32 Bit Modus.

Trap
2005-02-05, 12:33:30
Bei so winzigen Programmen resultiert der Speicherbedarf allein aus den Frameworkkomponenten die zur Laufzeit geladen werden.
Warum die jetzt beim 64-Bit target doppelt so groß sind musst du MS fragen.

Demirug
2005-02-05, 13:12:12
Das mit den x64 Targets kommt mir jetzt sowieso etwas merkwürdig vor. Eigentlich sollte dieser Schalter gar nicht vorhanden sein. Nun gut ist ja alles noch in einem Beta Stadium.

Coda
2005-02-05, 13:19:35
Eigentlich sollte der Sinn hinter .NET doch auch sein Platformunabhängig zu funktionieren, oder nicht?

Jesus
2005-02-05, 13:45:26
hier steht mal bischen was über die beta http://msdn.microsoft.com/netframework/programming/64bit/default.aspx

Coda
2005-02-05, 14:35:34
Naja, das sind halt die üblichen Dinge, aber da steht nirgends was von einem nötigen Recompile.

Es dürfte eigentlich gar keinen Unterschied geben zwischen den Platformen, sonst hat Microsoft irgendwas falsch gemacht.

Bzw ein .NET Binary das die Anforderungen auf der Seite erfüllt (also nicht irgendwie 4 bytes für Pointer annimmt z.B.) sollte auf beiden Systemen laufen.

iam.cool
2005-02-05, 15:34:16
Bei Planer 3DNow hat mal einer ähnliche Tests mit dem 64Bit Linux gemacht, die ergebnisse waren fast identisch, mehr Leistung höchstens maginal aber speicherverbrauch meistens cirka 100% mehr.

Jesus
2005-02-05, 16:15:52
Bei Planer 3DNow hat mal einer ähnliche Tests mit dem 64Bit Linux gemacht, die ergebnisse waren fast identisch, mehr Leistung höchstens maginal aber speicherverbrauch meistens cirka 100% mehr.

Jupp, das ganze Betriebssystem schluckt auch wesentlich mehr Ram als ein 32 bit windows (Kernel etc.)

Coda
2005-02-05, 16:18:48
So ein Quatsch. Die Daten werden durch 64-bit auch nicht mehr und die paar Pointer in nem Program reißen's auch nicht raus.

Mag sein, dass Windows x64 mehr RAM braucht, aber doppelt so viel sicher nicht.

Ach btw.: An der Speicheranzeige in nem Protected Mode OS kann man rein gar nix ablesen.

Jesus
2005-02-05, 16:29:56
So ein Quatsch. Die Daten werden durch 64-bit auch nicht mehr und die paar Pointer in nem Program reißen's auch nicht raus.

Mag sein, dass Windows x64 mehr RAM braucht, aber doppelt so viel sicher nicht.

Ach btw.: An der Speicheranzeige in nem Protected Mode OS kann man rein gar nix ablesen.

Naja zumindest hier steht was

http://reviews.zdnet.co.uk/software/os/0,39024180,39183101-3,00.htm

Compared to a 32-bit operating system, a 64-bit OS needs more memory. The comparison table below shows that kernel of the 64-bit version takes up nearly 70 per cent more memory than its 32-bit counterpart. So in order to get the same performance level, users switching to 64-bit Windows will need to upgrade their systems' memory

Storage requirements: 64-bit v 32-bit

Total 52120 31344
Paged 40572 25396
Non-paged 11548 5840


ich werd mal demnächst probeweise eine kleine C consolenandwendung erstellen und den Code vergleichen ;)

Coda
2005-02-05, 16:33:33
Da geht's doch nur um den Kernelspeicher. Keine Ahnung was MS verbrochen hat, aber logisch isses nicht.

Reine Daten im Speicher werden in 64bit nicht größer.

Der Code is wohl 20% größer, dazu kommen noch Pointer mit 8 statt 4 Bytes im Datensegment.

Code+Pointer machen heute in Anwendungen vielleicht 5% aus, das dürfte effektiv überhaupt keinen Unterschied machen.

Jesus
2005-02-05, 17:02:36
hm anscheinend ist kein 64 bit Compiler für C++ dabei, es geht nur das Win32 Profil :(

Allerdings sind so erstellte C Programme mehr als doppelt so gross wie im 32 bit Modus, da dürfte es aber wohl daran liegen dass sie über den WoW64 Emulator laufen.

Zumindest der 64bit IExplorer ist sogar etwas schlanker als der 32bittige der im WoW läuft (und auch als der im nativen 32 bit Modus) :biggrin:

Coda
2005-02-05, 17:14:04
Whatever. 64bit bedeutet mehr Speicher, aber nicht doppelt so viel weil ja 64/32 = 2 gilt. Das sollte einem wirklich klar sein.

del_4901
2005-02-05, 19:21:14
Whatever. 64bit bedeutet mehr Speicher, aber nicht doppelt so viel weil ja 64/32 = 2 gilt. Das sollte einem wirklich klar sein.

Mhm hat der AMD64er vllt im 64er mode ein anderes Alignment? Dann würde der Speicherverschnitt größer werden. Aber im allgemeinen hast du schon recht, die paar Zeiger fallen nicht in's Gewicht.

Oder der 64er Compiler Optimiert anders. Da ja mehr Register zur Verfügung stehen kann es sein das Standartmäßig das Teil im SpeicherKiller Mode compiliert.

Coda
2005-02-05, 19:34:15
Was hat denn die Registeranzahl mit der Speichermenge zu tun?

avalanche
2005-02-06, 01:09:23
Die "64-Bit" haben AFAIK nichts mit der Anzahl der Register zu tun. Dass dem Athlon64 nun im "64-Bit-Modus" mehr Register zur Verfügung stehen, ist wohl eine Eigenart des Athlon64, die (wahrscheinlich?) aus Kompatibilitätsgründen zum "32-Bit-Modus" vorhanden ist und die nicht generell auf alle 64-Bitter bezogen werden sollte. Jedenfalls fällt mir kein Grund rein, das könnte man einschränkend sagen.

Brillus
2005-02-06, 03:02:34
Der AMD64 hat mehr register weils mehr Performance bringen.
und bevor jetzt die frage kommt warum dann nciht schon früher ganz einfach weils dann eine neue Architektur gewesen wäre sprich wie auch jetzt alles neu kompiliert werden müsste und für nur mehr perforamce allein hätte es sich nciht gelohnt wo jetzt sowieso eine neue Architektur da ist hat man die mehr register halt einfach weil die Zeit günstig war eingebaut.

del_4901
2005-02-06, 03:52:17
Was hat denn die Registeranzahl mit der Speichermenge zu tun?

Der Compiler Optimiert anders, du kannst dem Compiler doch sagen ob er schnellen code (dafür mehr Speicher) oder kleineren Code, und dafür etw. langsameren. Hast du mehr Register ist die Trashinggröße für großen Code weitaus weiter oben.

Coda
2005-02-06, 11:56:42
Kapier ich nicht. Das REX Präfix brauchst du doch im 64-bit Modus eh immer.

Der Code wird eher kleiner durch mehr Register, weil man weniger Load/Store braucht.

][immy
2005-02-06, 12:17:54
ihr vergesst ein wenig das das .Net Framework 2.0 noch Betastatus hat
also könnte man auch davon ausgehen das entweder noch ein bug drin ist, oder das der code für das .Net Framework 2.0 noch nicht optimiert wurde

Das kleine programme auf anhieb doppelt so viel speicher verbrauchen kann ich mir aber auch noch vorstellen, aber hat das mal jemand mit dem kompelieren eines größeren programmes versucht?

fest steht, die pointer brauchen definitiv mehr speicherplatz als vorher (eben doppelt so viel) aber das war es im großen und ganzen auch schon. gut es gibt innerhalb eines programms massig pointer, aber so stark ins gewicht fallen sollten diese nun wirklich nicht

aber mit der entwicklung der programmiersprachen werden die programme gezwungenermaßen immer größer. größer heißt ja nicht unbedingt das es schlechter sein muss. größer kann auch bedeuten das etwas direkt verfügbar ist, ohne das noch etwas speziel berechnet werden muss.
beispiel sounddateien:
der mp3 standart ist recht rechenintensiv. man braucht schon eine gewisse geschwindigkeit um die mp3s in echtzeit abzuspielen. WAV ist da schon wesentlich freundlicher. es ist zwar groß, aber dafür wird kaum rechenleistung benötigt.

Coda
2005-02-06, 12:31:12
Bei .NET und Java kann man die tatsächlich verbrauchte Speichermenge eh nicht am Taskmanager ablesen.

der mp3 standart ist recht rechenintensiv. man braucht schon eine gewisse geschwindigkeit um die mp3s in echtzeit abzuspielen. WAV ist da schon wesentlich freundlicher. es ist zwar groß, aber dafür wird kaum rechenleistung benötigt.In Programmen werden Daten sehr sehr selten komprimiert im Speicher gehalten.

HellHorse
2005-02-06, 13:11:50
Bei .NET und Java kann man die tatsächlich verbrauchte Speichermenge eh nicht am Taskmanager ablesen.
Bei Java kann man seit 1.5 mit JMX dahinter. Da bekommt man je nach VM recht detaillierte Informationen und es gibt auch lustige Tools via JConsole.

Vorher war das nur sehr rudimentär möglich und liess sich von aussen nicht auslesen.

Wie's bei .NET aussieht weiss ich nicht.

GloomY
2005-02-07, 13:06:50
Reine Daten im Speicher werden in 64bit nicht größer.Wenn du für z.B. ein "Int" statt 32 nun 64 Bit nimmst, dann schon.
Ach btw.: An der Speicheranzeige in nem Protected Mode OS kann man rein gar nix ablesen.Was hat das mit dem protected Mode zu tun? Wenn's umfangreicher wird, auch gerne per PM :)
Kapier ich nicht. Das REX Präfix brauchst du doch im 64-bit Modus eh immer.Immer? kann ich keine 32-, 16- oder 8 Bit-Operationen auf Register mehr ausführen? Dann brauche ich das 64Bit-Prefix ja auch nicht...
Mhm hat der AMD64er vllt im 64er mode ein anderes Alignment? Dann würde der Speicherverschnitt größer werden.Gute Idee :) , aber imho ist das nicht der Fall.

Coda
2005-02-07, 13:24:48
Wenn du für z.B. ein "Int" statt 32 nun 64 Bit nimmst, dann schon.Das macht aber weder Visual C++ noch GCC für x86_64 und andere Compiler wohl auch nicht.

Immer? kann ich keine 32-, 16- oder 8 Bit-Operationen auf Register mehr ausführen? Dann brauche ich das 64Bit-Prefix ja auch nicht...Ich korrigiere: Du must es verwenden, wenn du 64-bit Operaden oder R8-R15 benützen willst. Trotzdem wird das wohl ähnlich viel Speicher verbrauchen als mehr Load/Stores wenn die Register ausgehen.