Discussion :

[Ggamer]

Bonjour,

Je compile actuellement mes applications Python + wxPython avec Py2exe sous windows 7-32 Bits. Si je passe sur Windows 7-64 Bits, est-ce que les fichiers compilés fonctionneront toujours aussi bien sur les systèmes 32 et 64 bits ? Devrais-je installer les version 64 bits de Python et wxPython ? etc...

Quels seraient vos conseils ?

Merci pour vos réponses...

[tyrtamos]

Bonjour,

Sur Windows 7 64bits, je travaille exclusivement avec Python 32bits. Les bibliothèques utilisées par Python (wxPython, ...) sont aussi en 32 bits. Les programmes exe 32 bits obtenus avec py2exe ou cx_freeze fonctionnent très bien sur Windows 64bits. Et ces programmes exe, après traitement par l'installeur "inno setup", s'installent sans broncher dans "C:\Program Files (x86)". Ça marche très bien.

[Ggamer]

Ok, merci pour cette réponse rapide.

Mais quel serait l'intérêt d'installer les versions 64bits de Python ou wxPython... ? Les programmes d'exécuteraient plus vite ?

[tyrtamos]

Bonjour,

Mais quel serait l'intérêt d'installer les versions 64bits de Python ou wxPython... ? Les programmes d'exécuteraient plus vite ?

On pourrait espérer que les programmes 64bits s'exécutent plus vite, mais jusqu'à présent, j'ai du mal à voir une différence. J'en reste donc à 32bits.

Mais peut-être quelqu'un d'autre a-t-il des infos plus étayées sur le sujet?

[mont29]

Pour autant que je sache, seules les applications lourdes (traitements d’image/son, calculs scientifiques, etc.) bénéficient vraiment du 64bits…

Sur une bibliothèque comme wxWidget, le bénéfice est quasi nul, et probablement bloqué par les performances d’autres sous-systèmes, comme la RAM.

De toute façon, quelle importance, vu qu’une interface n’est pas sensée être une grosse consommatrice de temps CPU*?

[wiztricks]

Salut,

Un processeur 64 bits permet d'ajouter de la mémoire physique au delà des 3.5/4Go.

Un OS 64 bits permet de créer des "process" ayant un espace d'adressage 64 bits, i.e. d'avoir plus de 2Go "d'espace virtuel".
On pourra aller "plus vite" s'il est possible de réduire le nombre d'entrées sorties disques ou autres en pouvant "garder" nombre d'objets "en mémoire".

Pour des questions de "compatibilité", Linux, OSX, Windows7 permettent de profiter des processeurs 64 bits (plus de mémoire) tout en permettant d'y installer et d'y faire fonctionner des applications en 32 bits.

La vitesse d'un processeur est fonction du nombre d'instruction exécutées "par seconde" qui dépend en gros de la vitesse de l'horloge.
Or que l'application soit 32 bits ou 64 bits, la vitesse de l'horloge sera la même, la différence risque de ne pas être "évidente" à constater...

note: il y en fait plus de registres et une bande passante mémoire plus importante qui permettent d'aller jusqu'à 30% plus vite mais ces "gains" dépendent du profil des applications et sont plus "faciles" à constater sur
des traitements côté serveurs que "poste de travail".

- W

[mont29]

Petite précision, un proc 64bit, ce n’est pas qu’un espace d’adressage mémoire de 64 bit, c’est aussi un traitement natif des valeurs sur 64bits (au hasard, double, et le int devient aussi précis que le long, en C (~standard)), ainsi que des registres 64bit, donc une bien plus grande rapidité d’exécution des instructions traitant ce type de données (quand le compilateur ou le programmeur ne les a pas optimisées vers des extensions genre SSE…).

[wiztricks]

Petite précision, un proc 64bit, ce n’est pas qu’un espace d’adressage mémoire de 64 bit, c’est aussi un traitement natif des valeurs sur 64bits (au hasard, double, et le int devient aussi précis que le long, en C (~standard)), ainsi que des registres 64bit, donc une bien plus grande rapidité d’exécution des instructions traitant ce type de données (quand le compilateur ou le programmeur ne les a pas optimisées vers des extensions genre SSE…).

Lorsqu'on passe de 32 a 64 bits, on augmente la quantité d'information accédée par les instructions machines. C'est une augmentation du "débit" mais pas de la "vitesse".
- W

[mont29]

Ben si, de la vitesse aussi, vu qu’en 64bit, une opération sur des doubles peut se faire en un seul cycle, alors qu’en 32bit, il en faut plusieurs (car la dite opération est décomposée)… Non*?

[wiztricks]

Ben si, de la vitesse aussi, vu qu’en 64bit, une opération sur des doubles peut se faire en un seul cycle, alors qu’en 32bit, il en faut plusieurs (car la dite opération est décomposée)… Non*?

ce n'est pas aussi "simple".

32 ou 64 bits est la "largeur" d'une adresse: elle définit la capacité d'adressage "mémoire" - RAM - du processeur.

La longueur de l'unité d'information rangée à l'adresse mémoire X est indépendante de la largeur du bus d'adresse: un octet, un int(32bits), un double(64bit) ou une chose à 128 bits.

Pour exécuter une instruction, le processeur doit copier le contenu des "cases" mémoire dans des registres "internes" qui auront la capacité suffisante pour stocker l'unité d'information à traiter.
note: un processeur 32 bits peut avoir des registres 128 bits...

- W

[mont29]

Oui, mais non*! Quand on parle d’architecture 32 ou 64bit, on fait référence à la taille de base des éléments manipulables par le proc, (et l’espace d’adressage mémoire n’en est qu’un aspect).

Si l’on exclut les extensions genre SSE (qui sont en 128, voire en 256 bits), un processeur 32 bits travaille sur des mots de 32 bits, et toute son électronique interne de manipulation est limitée à une largeur de 32 bits. Donc si on veut manipuler du 64bits avec lui, il faut se livrer à une sacrée gymnastique… C’est d’ailleurs pour ça que, traditionnellement, les applications genre 3D, audio, etc. travaillent de préférences avec des float plutôt qu’avec des double, sur un système 32bits c’est beaucoup plus performant.

Ça me rappelle quand j’ai fait un peu d’assembleur en PIC (microcontrôleurs 8bits), si on voulait manipuler des nombres supérieurs à 255, le nombre d’instructions assembleur était très vite décuplé*!

[wiztricks]

Oui, mais non*! Quand on parle d’architecture 32 ou 64bit, on fait référence à la taille de base des éléments manipulables par le proc, (et l’espace d’adressage mémoire n’en est qu’un aspect).

Je ne sais trop qui est "on", mais _je_ parle de:
1 - le nombre de bits décrivant une adresse,
2 - la taille des registres généraux

La taille des opérandes d'une instruction pourra être: octet, float, double,... ne dépend pas du 32/64 bits de l'architecture CPU.
Sinon, nous aurions des soucis majeurs côté "portabilité" et des difficultés à faire tourner une application 32 bits sur un processeur 64 bits.

Les seuls opérandes qui changent de taille sont les "int" (et les adresses).
Ils suivent la taille des registres généraux qui est alignée sur le nombre de bits d'adresse. Mais c'est parce qu'on préfère une API qui présente des adresses linéaires ou "flat" que "segmentés" - ce qui n'empêche pas une segmentation multi-niveaux en interne.

Pas de quoi faire tourner "moins" vite les applications 32 bits que leur variante 64 bits sur un environnement 64 bits.

C’est d’ailleurs pour ça que, traditionnellement, les applications genre 3D, audio, etc. travaillent de préférences avec des float plutôt qu’avec des double, sur un système 32bits c’est beaucoup plus performant.

Que le système soit 32 ou 64 bits:
- un float est toujours représenté par un mot 32 bits,
- avant d'exécuter une instruction, il faut récupérer les opérandes dans des "registres" qui passent par des transferts "mémoire" <-> "caches" <-> "registres". moins d'informations à transférer, c'est:
=> utilisation moindre des "ressources" intermédiaires
=> moins de délais pour récupérer les opérandes
=> un "débit" d'instructions plus important
note: le processeur ne peut exécuter une instruction qu'après avoir chargé les opérandes... et pendant que çà attend: le thread d'instructions sera "gelé".

sur X86_64, ce qui pourra faire aller "plus vite" les moutures 64 bits des applications est la possibilité pour les compilateurs d'utiliser un nombre plus important de registres (dans l'architecture 64 bits).

On considère, dans ce cas, les registres comme un "cache". En gros il y a plus de lignes dans le cache et moins d'allers retours mémoire. Les gains de ce côté sont d'autant plus intéressants que l'architecture 32 bits x86 datant des années 80s, disposait d'un nombre de registres relativement petit.
note: plus de registres apportera des gains côté performance, mais leur nombre ne dépend pas de la taille des adresses.

- W

[mont29]

Dans l’ensemble, je suis d’accords avec tout ça. Mais:

Je ne sais trop qui est "on", mais _je_ parle de:
1 - le nombre de bits décrivant une adresse,
2 - la taille des registres généraux

Moi, j’y rajoute un 3 - La taille des opérandes que peut traiter nativement une architecture (32 ou 64 bits).

À la réflexion, c’est un peu redondant, ça. Amha, 2 implique 3 et vice-versa…

Par contre, le nombre de bits décrivant une adresse n’a que (très) peu d’influence sur les performances, seule la quantité de mémoire utilisable (adressable) est affectée. Le débit de données dépend de la largeur du bus de données (sauf erreur, 64bits depuis bien longtemps pour la RAM, même si des bidouilles genre DualChannel sont supposées le dédoubler), et évidemment de sa fréquence.

Pas de quoi faire tourner "moins" vite les applications 32 bits que leur variante 64 bits sur un environnement 64 bits.

Évidemment que non (qui peut le plus, peut le moins). Par contre, une application utilisant massivement des calculs avec des doubles, par exemple, tournera beaucoup plus lentement en 32 qu’en 64 bits –*et pas seulement à cause des registres, mais aussi parce que le proc 32bit n’est tout simplement pas capable de faire une opération sur des doubles d’un seul tenant, il est obligé de la découper, puisqu’il ne travaille que sur des mots de 32bits.