Managed Code: 32bit vs. 64 bit

Ich hatte am Freitag ein paar Worte zu unserer Statiksoftware in Bezug auf 32 und 64bit sowie Multicore Systeme gesagt. Das führte zu einer Rückfrage, ob ich darüber nicht einen Artikel für eine Zeitschrift verfassen wollte. Nun schreibe ich ja in der Tat hin- und wieder mal solche Fachbeiträge - in diesem Fall glaube ich aber, das das Thema einfach nicht genug für einen solchen Text hergibt. Für einen kurzen Blogeintrag ist es aber vielleicht ausreichend... Mal sehen.

Zunächst mal ist die erste Frage: Wodurch wird die Anwendung 32- oder 64bittig? Da gibt es ein paar Fälle... Im Visual Studio kann man unter den Projekteigenschaften bei "Build" eine Platform Target einstellen. Dort gibt es 3 Optionen, und zwar x86, x64 und "Any CPU". Stellt man die Option auf x86, wird Code für x86 generiert: Der läuft dann sowohl auf 32bit als auch auf 64bit Maschinen als 32bit Code. Stellt man die Option auf x64, dann läuft das Resultat als 64bitter nur noch auf 64bit Maschinen. Stellt man die Option hingegen auf "Any CPU", dann läuft das Resultat auf 64bit Maschinen als 64bitter und auf 32bit Systemen als 32bitter.

Wenn zum Projekt mehrere Assemblies gehören, dann legt die ladende Assembly (also die mit dem Eintrittspunkt ins Programm) fest, ob die Sache 32bittig oder 64bittig wird. Im Wesentlichen kann man also immer die Default-Option "Any CPU" eingeschaltet lassen, und hat dann nie Ärger, egal wie die Zielplatform aussieht.

Dazu gibt es eine Ausnahme, und die tritt dann in Kraft, wenn man im Projekt 32bit Code verwenden muss. Dabei ist mit "muss" gemeint: Man hat entweder eine 3rd Party Bibliothek die es nur in 32bit Geschmacksrichtung gibt, oder aber man hat eigenen Code den man noch nicht umstellen kann oder will. In diesem Fall bleibt einem nichts anderes übrig, als den Eintrittspunkt als "x86" zu übersetzen, und damit eine komplett 32bittige Anwendung zu erzeugen.

Warum überhaupt x64? Gute Frage - auf die ich aber leider keine einfache Antwort kenne. Der wesentliche Vorteil von x64 ist der, das man einen deutlich größeren Adressraum hat. Und zwar einen, der in der Theorie 16 Exabyte unterstützt (was ziemlich viel ist), in der Praxis bei Win64 aber nur 16 Terabyte umfasst (was im Vergleich zu den 4GB bei Win32 auch ziemlich viel ist.). Davon hat man aber nur was, wenn man a) diese Speichermenge auch braucht und b) über Hardware verfügt wo man auch tatsächlich mehr als 4GB reinstecken kann.

Dabei gibt es durchaus Anwendungen auf die a) zutrifft - nicht zuletzt kümmere ich mich um so Kram, weil einige unserer Programme gerne auch mal sehr viel Speicher verbrauchen (Handregel: Je größer das Gebäude das berechnet wird, um so mehr Speicher wird dafür benötigt :-)).

b) ist hingegen eine Sache, die sich wohl erst in nächster Zeit entwickeln wird: (Desktop) Motherboards in die tatsächlich mehr als 4 GB reingehen sind selten - und wenn, dann gehen auch nur 8 rein. (Zumindest habe ich keine anderen gefunden.). Das wird sich mittelfristig natürlich ändern, ist aber zumindest zur Zeit der Stand der Dinge.

Man kann auch ganz sicher Performance-Betrachtungen anstellen, bei denen rauskommt, das 64bit Programme schneller sind als 32bit Programm - aber das genaue Gegenteil geht mit Sicherheit auch. Ebenso kann man wohl Messungen machen, bei denen rauskommt das 64bit Programme größer sind als 32bit Programm (schließlich brauchen ja alle Pointer doppelt so viel Platz) - aber in Abhängigkeit vom Programm geht auch hier wohl das Gegenteil.

Im Wesentlichen läuft das für mich auf eines hinaus: Wenn man keine sehr speziellen Anforderungen hat (so wie wir mit dem massiven Speicherbedarf) und auch nicht an "altem" 32bit Code hängt - dann verwendet man am besten die Option "Any CPU" - denn die macht am wenigsten Ärger.

Apropos Ärger: Einen kleinen Haken hat die Sache schon. Wenn man Interop (PInvoke) verwendet, dann muss man sicherstellen, das die meist von Hand gebastelten Interfaces auch _wirklich_ stimmen - ansonsten funktionieren die hinterher nämlich nur auf ein 32bit Platform, aber nicht auf einer 64bit Platform. Oder natürlich umgekehrt. Hint: pinvoke.net ist dabei wirklich hilfreich.

Hilfreich zu lesen: Everything you need to know to start programming 64-bit Windows Systems.