64/32bit

[Bax]

Hallo miteinander,

Will mir ne neue Kiste anschaffen mit Windows XP64, darauf dann python 2.5.2amd64 installieren. Wird dann auch mysqldb noch funktionieren. das gibt es ja meines wissens nach nur als 32bit version?

Gruss Bax

[Leonidas]

Hallo Bax, willkommen im Forum,

Will mir ne neue Kiste anschaffen mit Windows XP64, darauf dann python 2.5.2amd64 installieren. Wird dann auch mysqldb noch funktionieren. das gibt es ja meines wissens nach nur als 32bit version?

Nein, wohl eher nicht. Man kann keine 32-Bit DLLs in 64-bit Prozesse reinladen. Du musst also die 32-Bit-Version von Python nehmen oder eine 64-Bit-Version von MySQLdb kompilieren.

[Bax]

ok, danke. und 32bit python läuft unter xp64?

[Sr4l]

ja, wegen WOW64 (Windows on Windows 64)
32 Bit Programme werden dann unter 64bit ausgeführt, mehr oder weniger erfolgreich Also Python geht habe ich selber inkl MySQLdb uvm.

Diablo2 was unter 32bit Vista geht unter 64bit Vista nicht, Spiele aber auch "Hardwarenahe Programme" gehen manchmal nicht.
Virescanner, Firewall, Treiber gehören dazu.
32 oder 64bit sollte überlegt sein, ich habe mich für 64bit entschieden.

Motto: Wenn alles geht ist es langweilig.

[sma]

Unter der Annahme, dass 64-Bit-Programme im Schnitt doppelt so viel Hauptspeicher verbrauchen wie 32-Bit-Programme, lohnt sich das IMHO erst, wenn man in einem Programm mehr als 2 GB benötigt und eine Maschine mit mehr als 6 GB Hauptspeicher anzuschaffen gedenkt. Für Python fände ich es eher ungewöhnlich, wenn man da mit so großen Datenmengen hantieren will.

Bei Java versucht man ja inzwischen, die 64-bit-Versionen dank VM und JIT mit "verkürzten" Speicherreferenzen (keine 64-bit-Pointer sondern nur 32-bit, die dann mit 8 multipliziert für 32 GB Hauptspeicher gut sind) laufen zu lassen, um den Hauptspeicher effizienter zu nutzen. Macht Python das auch oder verdoppeln sich einfach int und void* und damit der Speicherbedarf?

Stefan

[lunar]

Unter der Annahme, dass 64-Bit-Programme im Schnitt doppelt so viel Hauptspeicher verbrauchen wie 32-Bit-Programme

Diese Annahme ist zu pessimistisch. Der Speicherverbrauch eines Programms hängt neben Referenzen und Zeigern auch stark davon ab, welche Daten das Programm wie verarbeitet, und die Größe dieser Datei ändert sich im Allgemeinen eher selten durch den Umstieg auf 64Bit.

Bevor man allein wegen des Speicherverbrauchs 64-Bit grundsätzlich ablehnt, sollte man alle anderen Aspekte dieser Architektur mit einbeziehen und je nach Einsatzzweck abwägen.

Macht Python das auch oder verdoppeln sich einfach int und void*
und damit der Speicherbedarf?

Letzteres.

[sma]

Ein Vorteil von 64-bit soll bei x86-Prozessoren eine größere Menge der ansonsten ja notorisch knappen Prozessorregister sein. Davon wird Python aber wenig haben, da es ein stackbasierter Interpreter ist. Cryptoalgorithmen liefen bei Java mit 64-bit fast doppelt so schnell, doch ansonsten habe ich dort selten eine signifikate Performance-Steigerung beobachtet.

Mir scheint daher der Ruf nach 64-bit eher dem irrationalen Wunsch nach "mehr power" zu entsprechen, als sich wirklich messbar zu lohnen.

Stefan

[Leonidas]

Ich kann hier mit einem 64-Bit System keine großen User-Sichtbaren Performanceunterschiede gegenüber 32-Bit erkennen. Das liegt vermutlich auch an den Optimierungen, denn x86_64 Binaries dürfen mehr Optimierungen verwenden als 486-Binaries, da die nach dem 486 eingeführten Features wie MMX, SSE in jedem x86_64-Prozessor vorhanden sind und man nicht abwägen muss ob man damit nicht irgendwelche Prozessoren die noch in Benutzung sind ausschließt. Das ist für Binärdistributionen und Systeme wie Debian, Fedora, OpenSUSE oder Windows recht praktisch. Debian kompilierte lange Zeit für 386, inzwischen für 486 und viele Linux-Distributionen setzen 686 vorraus, aber auch seit dem Pentium Pro sind weitere Hardwareverbesserungen dazugekommen die man bei x86_64 seit Anfang an hatte. Für Sourcebasierte Systeme wo man sich das System handoptimieren kann ist das natürlich so ziemlich egal. Aber inwieweit das zu spürbaren Unterschieden außerhalb von Benchmarks führt... da müsste man wohl einige Tests durchführen, die mir aber zu zeitauwendig sind.

Apropos, Knuth hat sich auch erst letztens über den Speicherverbrauch von 64-Bit beschwert, ich zitiere das mal direkt:

A Flame About 64-bit Pointers

It is absolutely idiotic to have 64-bit pointers when I compile a program that uses less than 4 gigabytes of RAM. When such pointer values appear inside a struct, they not only waste half the memory, they effectively throw away half of the cache.

The gcc manpage advertises an option "-mlong32" that sounds like what I want. Namely, I think it would compile code for my x86-64 architecture, taking advantage of the extra registers etc., but it would also know that my program is going to live inside a 32-bit virtual address space.

Unfortunately, the -mlong32 option was introduced only for MIPS computers, years ago. Nobody has yet adopted such conventions for today's most popular architecture. Probably that happens because programs compiled with this convention will need to be loaded with a special version of libc.

Please, somebody, make that possible.

[lunar]

Davon wird Python aber wenig haben, da es ein stackbasierter Interpreter ist.

Im Allgemeinen ist ein PC ja nun auch keine Dedicated Python Maschine

Cryptoalgorithmen liefen bei Java mit 64-bit fast doppelt so schnell, doch ansonsten habe ich dort selten eine signifikate Performance-Steigerung beobachtet.

Tja, wenn man Software-Festplattenverschlüsselung nutzt, profitiert man von solchen Geschwindigkeitssteigerungen. Ich persönlich habe mich bei meinem Notebook für 64-Bit entschieden, weil dmcrypt mit AES spürbar schneller ist. Ob der Speicherverbrauch nun signifikant höher ist, weiß ich nicht, das habe ich nicht beachtet, weil es für mich persönlich völlig irrelevant ist. Von der verbauten 2GB liegen durchschnittlich 700 MB brach, und das nach Abzug aller Kernel-Puffer und -Caches. Was hätte ich von noch mehr freiem Speicher?

Nur um das nochmal explizit klar zu stellen: Ich habe nicht behauptet, dass ich 64-Bit generell für sinnvoll halte. Ich halte es lediglich für falsch, die Beurteilung von 64-Bit nur und ausschließlich am Speicher zu reduzieren.

Im Übrigen ist diese ganze Diskussion ums Für und Wider von 64-Bit doch völlig unsinnig. Wer 32-Bit nutzen möchte, soll das tun, wer 64-Bit nutzen möchte, mag dafür mehr oder weniger gute Gründe haben. All das ist für den OP und sein konkretes Problem aber doch wohl eher irrelevant, schließlich ist "Installiere dir ein 32-Bit-System" kaum eine gute Lösung für ein Problem bei der Installation von Python.

[farid]

Im Allgemeinen ist ein PC ja nun auch keine Dedicated Python Maschine

Falls sich sowas wie Parrot als Backend fuer Perl, PHP, Python und Ruby etc. durchsetzt und vor allem stabilisiert (API-technisch), koennte eine dedicated Parrot-VM auf Silikon durchaus Sinn machen, sogar fuer den Server-Markt mit seinen vielen LAMPen.

[Leonidas]

Unwarscheinlich. 1. Parrot-VM hat nicht genug Backing um in absehbarer Zeit von größerem Interesse zu werden. 2. Lisp-Maschienen werden wohl nicht wiederkommen. Sun hats versucht und ist gescheitert und so toll ist Parrot dann doch nicht. Außerdem bräuchte man dann sowieso noch einen "richtigen" HTTPD und eine Datenbank für LAMP.

[BlackJack]

@farid: Juhuu, ich bin nicht der einzige der solche "Fehlübersetzungen" macht. Silikon != Silizium.

[Leonidas]

Wobei ich solche Fehlübersetzungen noch für das geringste Übel halte. Von farid habe ich bisher nichts grundlegend falsches gehört (daher wird wohl sein Buch auch im großen und ganzen durchaus empfehlenswert sein, nicht so wie einige andere, die an dieser Stelle besser nicht genannt werden.) von BlackJack kann man auch als "Regular" noch was lernen; von dem her könnt ihr beide meinetwegen "Silicone" so übersetzen wie ihr wollt

[BlackJack]

Hm, vielleicht mit "blöder Kegel"!? "silicone" != "silicon"

Ich glaube *das* hatten wir beim letzten mal auch. Und Spekulationen darüber was für Gedankengänge zu Silikon und Kegeln in Männerhirnen wohl unterbewusst abgehen könnten.