...encore du 64 bits souhaité
...encore du 64 bits souhaité
Je viens voir où le developpement du 64 bit en est car j'en ai vraiment besoin. J'en ai tellement besoin que je pense adopter un autre language si PB ne le faisait pas dans quelques mois (semaines ?)
64 bits en natif, evidement...
ps: dark est en 64 bits ?
64 bits en natif, evidement...
ps: dark est en 64 bits ?
-
- Messages : 1092
- Inscription : mer. 28/janv./2004 16:22
- Localisation : 76
- Contact :
Ca ne se fait pas en claquant des doigts, donc, les semaines, tu peux réver.
Heis Spiter, webmaster du site http://www.heisspiter.net
Développeur principal et administrateur du projet Bird Chat
Parti courir au bonheur du dév. public et GPL
Développeur principal et administrateur du projet Bird Chat
Parti courir au bonheur du dév. public et GPL

-
- Messages : 1500
- Inscription : jeu. 25/mars/2004 11:23
- Localisation : Sophia Antipolis (Nice)
- Contact :
Pour Dark ça m'étonnerais 

Webmestre de Basic-univers
Participez à son extension: ajouter vos programmes et partagez vos codes !
Participez à son extension: ajouter vos programmes et partagez vos codes !
bah nan, sinon à quoi serviraient ces libs 64bits que les utilisateurs PB s'évertuent de coder pour palier ce manque ?poshu a écrit :je crois pas qu'on soit obligé de tourner sous windows xp 64 ou windows 2003 64 pour executer des programmes utilisant les instructions amd64 ou emt64, tant que le proco est compatible. J'ai tord?
Dri

Déja qu'on a pas le support des types 64 bits, je pense que tu en demande trop en esperant le support complet du 64 bits prochainement
Mais bon, peut être que la trésorerie de Fred lui permettra d'embaucher d'autres talentueux programmeurs qui l'aiderons à accélérer un peu le rythme du développement de PB

Mais bon, peut être que la trésorerie de Fred lui permettra d'embaucher d'autres talentueux programmeurs qui l'aiderons à accélérer un peu le rythme du développement de PB

"Qui baise trop bouffe un poil." P. Desproges
Faut différencier le 64bits et le 64bits 
Le premier en utilisant des doubles 32bits et le second qui seront gérés par des registres 64bits.
Pour faire du "vrai" 64bits et en tirer profit il faut d'abord que le cpu le gère (càd des instructions 64bits et des registres 64bits).
Ensuite il faut que le code généré soit 64bit, càd que le compilateur tienne compte des instructions 64bits.
En bien entendu il faut que le programmeur l'utilise.
Je vais essayer de clarifier les choses par un exemple (n'hésitez pas à me reprendre si je dis des conneries).
Calcul : a + b
CPU 32 - compilateur 32
- a et b sont chacun placés dans un registre 32
- une instruction 32 est utilisée
CPU 64 - compilateur 32
- a et b sont chacun placés dans un registre 64
- une instruction 64 est utilisée
CPU 32 - compilateur 64
- Je crois pas que c'est faisable ça
CPU 64 - compilateur 64
- a et b sont chacun placés dans un registre 64
- une instruction 64 est utilisée
Comme on le voit avec un code 32 sur un cpu 64 il y a une sorte de perte virtuelle dans le sens on l'on utilise pas les capacités au maximum, mais bon si on doit stocker la valeur 1 dans un 32 ou 64 c'est pas le maximum non plus.
J'ai pu lire plusieurs tests sur les performances d'une application 32 et 64 sur un système 64bits (OS + hardware) et étonnement ce n'est pas toujours le 64 qui l'emporte (pourquoi c'est une autre question).
Mais dans tous les cas ce n'est qu'une histoire de performances et de facilité dans le sens où avec une librairie on sait très bien s'en sortir.

Le premier en utilisant des doubles 32bits et le second qui seront gérés par des registres 64bits.
Pour faire du "vrai" 64bits et en tirer profit il faut d'abord que le cpu le gère (càd des instructions 64bits et des registres 64bits).
Ensuite il faut que le code généré soit 64bit, càd que le compilateur tienne compte des instructions 64bits.
En bien entendu il faut que le programmeur l'utilise.
Je vais essayer de clarifier les choses par un exemple (n'hésitez pas à me reprendre si je dis des conneries).
Calcul : a + b
CPU 32 - compilateur 32
- a et b sont chacun placés dans un registre 32
- une instruction 32 est utilisée
CPU 64 - compilateur 32
- a et b sont chacun placés dans un registre 64
- une instruction 64 est utilisée
CPU 32 - compilateur 64
- Je crois pas que c'est faisable ça
CPU 64 - compilateur 64
- a et b sont chacun placés dans un registre 64
- une instruction 64 est utilisée
Comme on le voit avec un code 32 sur un cpu 64 il y a une sorte de perte virtuelle dans le sens on l'on utilise pas les capacités au maximum, mais bon si on doit stocker la valeur 1 dans un 32 ou 64 c'est pas le maximum non plus.
J'ai pu lire plusieurs tests sur les performances d'une application 32 et 64 sur un système 64bits (OS + hardware) et étonnement ce n'est pas toujours le 64 qui l'emporte (pourquoi c'est une autre question).
Mais dans tous les cas ce n'est qu'une histoire de performances et de facilité dans le sens où avec une librairie on sait très bien s'en sortir.
Vive le thread-safe !