Je croyais que c'était l'adressage des données qui prenait plus de place et non pas pas les données.lecbee wrote:pour la simple raison que les données 64 bits prennent 2 fois plus de place en mémoire que les données en 32 bits.
D'accord avec toi, le bus mémoire passe à 64 bit ce qui donne 2^64 = 1.9e19 adresses et à chaque adresse on trouve 1 octet (pour info en 32 bit : 2^32 = 4.3e9 = 4Go).pmarion wrote:Je croyais que c'était l'adressage des données qui prenait plus de place et non pas pas les données.lecbee wrote:pour la simple raison que les données 64 bits prennent 2 fois plus de place en mémoire que les données en 32 bits.
Si l'on a un pointeur sur une chaine de caractères, cette chaine ne prendra pas plus de place, mais c'est son adresse sur 64bits qui prendra plus de place.
Comme j'ai répondu à pmarion, une variable entière (un int en C par exemple) est codée "normalement" (en 32 bits) sur 32 bits. On peut utiliser une variable sur 64 bits en utilisant "long long int" (ou un truc dans le genre). Mais sur un OS 64 bits, un int basique est directement à 64 bits.Salokyn wrote:J'imagine qu'on doit pouvoir utiliser des variables integer ou float codées sur 64bit au lieu de 32 pour avoir moins de limitations ou plus de précision lors des calculs, ce qui demande donc 2x plus de place pour ces variables particulières, mais de là à dire qu'il faut 2x plus de RAM c'est un grossier raccourci 🙂 D'ailleurs je doute que la plupart des applications compilées en 64bit se servent effectivement des avantages propres à cette architecture.
Donc un int sans long ni short resterait codé sur 32bit quelque soit l'architecture ... enfin ça doit bien varier d'un compilateur à un autre 🙂la plupart des compilateurs brisent la règle selon laquelle le
type int est le type des entiers natifs du processeur, et fixent sa taille à 32 bits quelle que soit
l'architecture utilisée. Ainsi, le type short est toujours codé sur 16 bits, le type int sur 32 bits et le
type long sur 32 ou 64 bits selon que l'architecture de la machine est 32 ou 64 bits. Autrement
dit, le type qui représente les entiers nativement n'est plus le type int, mais le type long. Cela ne
change pas les programmes 32 bits, puisque ces deux types sont identiques dans ce cas. Les
programmes destinés aux machines 64 bits pourront quant à eux être optimisés en utilisant le
type long à chaque fois que l'on voudra utiliser le type de données natif de la machine cible. Les
programmes 16 bits en revanchent ne sont en revanche plus compatibles avec ces règles, mais
la plupart des compilateurs actuels ne permettent plus de compiler des programmes 16 bits de
toutes manières.
#include <stdlib.h>
#include <stdio.h>
int main (int argc, char* argv[])
{
printf("sizeof(short) = %d\n", sizeof(short));
printf("sizeof(int) = %d\n", sizeof(int));
printf("sizeof(long) = %d\n", sizeof(long));
printf("sizeof(size_t) = %d\n", sizeof(size_t));
return 0;
}$ gcc -o sizeof sizeof.c
$ file sizeof
sizeof: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.9, not stripped
$ ./sizeof
sizeof(short) = 2
sizeof(int) = 4
sizeof(long) = 8
sizeof(size_t) = 8#include <iostream>
int main(void)
{
int unsigned a = 5000000000;
std::cout << a << std::endl;
return 0;
}$ g++ -m64 test.cc -o test && ./test
test.cc: In function 'int main()':
test.cc:5: attention : grand entier implicitement tronqué pour un type non signé
705032704$ g++ -m32 test.cc -o test && ./test
Dans le fichier inclus à partir de /usr/include/features.h:359,
à partir de /usr/lib/gcc/x86_64-redhat-linux/4.3.2/../../../../include/c++/4.3.2/x86_64-redhat-linux/32/bits/os_defines.h:44,
à partir de /usr/lib/gcc/x86_64-redhat-linux/4.3.2/../../../../include/c++/4.3.2/x86_64-redhat-linux/32/bits/c++config.h:40,
à partir de /usr/lib/gcc/x86_64-redhat-linux/4.3.2/../../../../include/c++/4.3.2/iostream:44,
à partir de test.cc:1:
/usr/include/gnu/stubs.h:7:27: erreur: gnu/stubs-32.h : Aucun fichier ou dossier de ce type
test.cc:5: erreur: integer constant is too large for 'long' type
test.cc: In function 'int main()':
test.cc:5: attention : grand entier implicitement tronqué pour un type non signéUne voiture, des vacances, un ordinateurQu'y-a-t-il à gagner de passer en Fedora 64 bits?
Sous Linux, tout devrait être proposé, mais rien ne devrait être imposé ! ! !De toute façon avec Fedora 11 vous n'aurez plus choix entre le 64 et le 32. Si le CPU est compatible 64 bits alors Fedora le sera. Et je trouve que c'est une bonne chose, même si c'est un peu "forcé".
Imagines que l'on te demande de choisir les modules d'un kernel lors de l'installation ou la mise à jours du kernel ?!pmarion wrote:Sous Linux, tout devrait être proposé, mais rien ne devrait être imposé ! ! !De toute façon avec Fedora 11 vous n'aurez plus choix entre le 64 et le 32. Si le CPU est compatible 64 bits alors Fedora le sera. Et je trouve que c'est une bonne chose, même si c'est un peu "forcé".
Seul le noyau sera 64bits (pour bénéficier d'une meilleure gestion du matériel), les applications seront 32 bits si on le souhaite.Heldwin wrote:Si on estime qu'on va avoir plus de problèmes de compatibilités ou autres en 64b (drivers, programmes, etc.), et qu'on veut installer la version 32b sur un proc 64b, on devra faire comment ?
Faux.Heldwin wrote:De plus, il me semblait que ça ne servait à rien d'installer un 64b si on avait moins de 3G de mémoire.
Un PC avec proc 64b n'a pas toujours + de 3G de mémoire.
Faut vivre avec son temps, mais il y aura toujours des gens qui seront des freins au progrès. On se demande bien pourquoi on n'est pas resté au 16 bits.Heldwin wrote:En tout cas, j'ai plutôt tendance à éviter les 64b, car de toute façon aucun de mes PC a plus de 2G de mémoire ^^
Et c'est mon droit !
