float et double processeur 32 bits

Bonjour,

Est il plus rapide de manipuler des réels simple précision (32 bits) sur un système 32 bits ?
Il me semble que les registres FPU des processeurs 32 bits sont de 32,64et 80 bits ,que le bus d'adresse soit également de 64 bits et qu'il existe des commandes assembleurs permettant un "memory-to-registery".

Donc hors mis le calcul en lui même, le temps que mets un proesseur 32 bits à obtenir un réel double précision dans un registre ne prends pas plus de cycle d'horloge que pour un réel simple précision ?

Merci

sur une archi 32 bits, le bus fait 32 bits :€ Charger un double 64bits prend un poil plus de temps. Le vrai ralentissement provient souvent des algorithmes qui necessitent des calculs plus complexes pour atteindre une précision acceptable.

j'étais sûr que le bus d'adresse faisait 64 bits

Citation:

---

Envoyé par guillaume07

Est il plus rapide de manipuler des réels simple précision (32 bits) sur un système 32 bits ?

---

Ça va vraisemblablement dépendre de ce qui varie et ce qui est constant dans ta comparaison.

Citation:

---

Il me semble que les registres FPU des processeurs 32 bits sont de 32, 64 et 80 bits,

---

Oui et non. Si on considère l'ensemble des architectures, celles disposant de flottant sur 80 bits sont rares (x86 et 68000).

Citation:

---

que le bus d'adresse soit également de 64 bits et qu'il existe des commandes assembleurs permettant un "memory-to-registery".

---

1/ qu'est-ce que le bus d'adresse vient faire ici?
2/ je ne connais pas de processeur utilisant des adresses physiques sur 64 bits. J'ai pas été voir les derniers, mais les adresses logiques doivent tourner autour de 56 bits et les adresses physiques autour de 48.

3/ il n'y a pas de relation entre le nombre de bits d'un processeur (ce qui est le nombre de bits de ses registres d'usage général tant que le marketting n'intervient pas pour rentre enlever toute signification autre qu'une affirmation "nous sommes les meilleurs") et la taille des bus (qu'ils soient de données ou d'adresse).

Citation:

---

Donc hors mis le calcul en lui même, le temps que mets un proesseur 32 bits à obtenir un réel double précision dans un registre ne prends pas plus de cycle d'horloge que pour un réel simple précision ?

---

Je ne comprends pas comme tu déduis ça de tes remarques précédentes. En général, les caches intervient et si la donnée est en cache et correctement alignée, obtenir 32 ou 64 bits prend le même temps. Et comme de toute manière on lit maintenant des lignes de cache entière, si la donnée n'est pas dans le cache, c'est aussi équivalent (mais d'un ordre de grandeur ou deux fois plus lent si elle est dans la mémoire externe par rapport à être dans le cache le plus proche). Mais si plutôt que de comparer le temps d'accès à 1 float au temps d'accès à 1 double, tu compares le temps d'accès à 100M floats au temps d'accès à 100M double, il y a de bonne chance que ce dernier soit le double...

Citation:

---

Envoyé par Joel F

sur une archi 32 bits, le bus fait 32 bits :€

---

Il n'y a jamais eu de relation. D'une part, on a toujours utilisé du multiplexage dans les versions bas de gamme pour diminuer la taille des bus (et on a aussi multiplexé le bus d'adresses avec le bus de données). D'autre part dés qu'il y a eu des caches, on a souvent utilisé des bus de données plus larges que les registres (le Pentium avait déjà un bus de données sur 64 bits). Quant aux bus d'adresses, même sans utiliser de multiplexage, on a souvent eu des architectures permettant des adresses plus larges que ce que ne permettaient les bus (IBM 360, Motorola 68000, et c'est vrai de nos jours sur les archi 64 bits) et en fin de vie des archi, on a souvent utilisé des trucs plus ou moins nets pour permettent des bus d'adresse plus large (PDP-11, PEA sur X86, ...) Sans sans tenir compte du fait qu'on peut avoir plusieurs canaux vers la mémoire...

Si je me souviens bien de mes cours de C, lorsque l'on utilise une constante statique numérique elle est par défaut du type « int » pour les entiers et « double » pour les réels.

Il me semble avoir lu que le comportement du C avait plus ou moins été optimisé pour les « int », et qu'il était souvent préférable (plus rapide ?) d'utiliser un « int » plutôt qu'un « short ».
Vu que les « int » sont très utilisés, même pour représenter un booléen (du moins en C), ça m'a paru raisonnable.

Du coup, je me suis dit que c'était la même chose pour les réels :
Sauf besoin particulier, autant utiliser un « double » plutôt qu'un « float ».

Mais je commence à avoir des doutes…
Alors, quand l'amplitude des entiers ou la précision des réels dont on a besoin n'est pas grande, et que la taille mémoire utilisée n'a pas d'importance, quel(s) type(s) vaut-il mieux utiliser ?

Les doubles. Les floats sont souvent pas assez precis (surtout quand on fait des calculs, float c'est plus un format pour stocker que pour calculer). long double a le probleme d'etre implementer de maniere inhomogene (soit c'est la meme chose que double, soit un flottant sur 80 bits avec un support hard, soit un flottant sur 128 bits avec un support soft uniquement).