Salut Caribensila !
Je vais essayer de compléter un peu ces réponses.
Envoyé par
Caribensila
En pratique, que faudra-t'il changer dans nos anciennes routines utilisant le type Integer pour tirer parti du nouvel environnement 64 bits :
- Rien ?
- Passer en Int64 ?
- Exploiter le fait qu'il y a 2 Integers dans un Int64 ?
Déjà, ce qu'il faut savoir, c'est que le 64 bits n'apporte généralement pas grand chose si ce n'est rien au niveau des performances. D'un côté certains "travaux" souvent utilisés sur la mémoire (Ajoutées par le compilateur) peuvent être plus rapides tel que CopyMemory/Move, ZeroMemory (Encore que ça dépend beaucoup de l'implémentation)... De l'autre, le code est beaucoup plus gros en mémoire (Les instructions ont des opérandes sur 64 bits qui prenne de la place), et les données aussi ce qui pose problème pour tout ce qui est cache processeur. Il y a plus de transferts des caches vers la RAM ce qui est préjudiciable.
Par exemple dans le code suivant (Du moins la partie gestion de i et j en mémoire, l'addition...) tourne très probablement à la même vitesse sur un processeur 64 bit, qu'il soit compilé vers une appli 32 ou 64. Et passer par du Int64 pour la compilation vers 64 ne changerait rien non plus aux perfs.
1
2
3
4
5
6
7
| var
i, j: Integer;
begin
i:= Random(200);
j:= Random(200);
ShowMessage(IntToStr(i + j));
end; |
Par contre, utiliser un Int64 est désastreux pour les perfs quand on compile vers du 32 !
Et c'est là le principal avantage de compiler vers du 64 bits. Le processeur devient capable de travailler efficacement sur des entiers non signés supérieurs à 4294967295.
Avant, si l'application devait traiter des entiers supérieurs à 4294967295, soit on passait par un Int64 plus lent (Mais aussi limité), soit par une librairie dédiée au calcul sur grands entiers (Tel que gmp ou peut être NewGInt et NewGCent évoquées sur ce thread), encore plus lente.
Maintenant, on n'aura plus ce problème de lenteur avec les Int64, et on aura moins tendance à utiliser une "lente" librairie pour les grands entiers. 4 milliards et des brouettes, c'est un chiffre plus facile à dépasser que 18446744073709551615.
Les applications monétaires actuelles en Delphi utilisent probablement le type Currency pour la plupart. C'est en gros un Int64 auquel on met virtuellement une virgule au niveau du 4ème chiffre. Compilé en 32 bit, ce type est strictement équivalent à un un Int64, donc lent. Compilé en 64 bit, le type Currency devient aussi rapide que ne l'était le type Integer.
Le processeur devient aussi un peu plus à l'aise avec le type Double (flottant 64 bit). Pas dans les calculs, vu que ça reste le boulot de la FPU qui les gérait déjà, mais dans certains déplacements de Double (Mais bon ça doit rester vraiment marginal. Et dans le domaine du jeux vidéo, passer du Single au Double n'est pas forcément intéressant non plus pour les perfs niveau carte graphique).
Bref, porter une appli 32 bits en 64 bits n'apporte généralement pas grand chose, et souvent, ceux qui le font conservent pas mal d'entiers en 32 bits ! Faut par exemple savoir que sous Visual C++, si on cible x64 le type C int est sur 32 bits (Relativement normal, de même avec pas mal de compilo sous unix), mais le type long est aussi en 32 bits !
Mais c'est sûr que comme dit plus, réécrire certaines procédures classiques avec du NativeInt doit parfois être pertinent.
Envoyé par
Caribensila
Je viens d'acheter un bouquin pour (enfin!) m'initier à l'ASM (en 32 bits).
Me conseillez-vous de me lancer ou est-il urgent d'attendre ?
Franchement, je te conseillerais de te lancer dans le 32 bits, vu que comme dit partout, le x64 est une "extension" du x86 (Donc facile d'apprendre le x64 après le x86). Tu peux même commencer par du 16 bits si tu veux ! C'est d'ailleurs à peine plus facile pour les humains car les opérandes sont moins grandes.
En tout cas l'IDE de Delphi (Tout du moins les versions 6 et 7) est vraiment bien pour apprendre l'assembleur, peut être le meilleur produit à ce niveau.
2 |
0 |
