Bonjour à tous!

Je possède Windows Vista et plusieurs distributions (Fedora 10, (K)Ubuntu, openSUSE 11.1, Mandriva Free 2009.0, et bientôt Debian 4.0), toutes en 32 bits, sur le même PC: HP Pavilion m8000 m8079.fr.

En regardant la doc de mon PC, j'ai remarqué qu'il était double coeur, et compatible 64 bits... Chose que je ne savais pas...
http://www.cnetfrance.fr/produits/pc/hp-pavilion-media-center-tv-m8079-fr-39370143_4t.htm

Bref, je voudrais savoir ce que j'ai à gagner de passer de la version 32 bits à la version 64 bits de Fedora.


1) Que verrais-je comme principales différences sous 64 bits?

2) Sachant que Fedora a un noyau très récent, les deux versions sont-elles toutes deux au même niveau de stabilité?

3) Peut-on passer à la version supérieure sans perdre mes configs et mon /home?

4) AU lieu de regraver une iso, est-il possible de faire une sorte d'upgrade vers une version 64 bits?

Merci

Skully.
Demande toi plutôt ce que tu as à perdre en restant en 32 bits. Sauf si ce n'est qu'un test.
Salut,
1) pour les différences, le sujet est largement abordé dans le forum déja ... et le point de vue de nouvo09 se tiens aussi ^^
2) les logiciels n'ont pas de versions différentes, qu'ils soient en 32 ou 64 bits. Ils sont juste compilés sur une architecture différente.
3) Tu peux changer d'archi en gardant ton /home ... soit t'as une partoche séparée, soit tu fais des sauvegardes.


epo
1) Fait une recherche dans les forums et la blogosphère... Des perfs en plus sur certain truc.

2) Fedora propose peu de branches (i386, x86_64 et ppc) donc les maintient pleinement au même rythme. Le noyaux de Fedora n'est pas récent, c'est le dernier stable.

3) Tu peux faire une mise à jour Fedora n vers Fedora n+1 sans problème mais sur architecture identique. Tu ne pourra pas passer d'une F9 i386 vers une F10 x86_64. Cependant si tu réinstalle et possède un /home sur une partition distincte alors tu ne perdra pas tes configs de ton /home

4) Réponse dans le 3. Pour i386 vers x86_64, je te conseil de réinstaller.
Merci de vos réponses. Je suis convaincu et passerait en 64 bits une fois l'iso téléchargée, et quand j'aurai un peu de temps 😉.

Par contre dans le lien de petitdernier, il est dit que la x86_64 demande plus de mémoire vive. Je n'ai que 2 Go de mémoire vive, et ils parlent du double, soit 4 Go...

Pensez vous que ça ira quand même, et que je ne verrais pas de ralentissements?

Je note que j'ai tendance à faire plusieurs choses en même temps et mon tableau de bord est toujours plein... Paraît que ça use beaucoup de mémoire vive, ça aussi...

Merci beaucoup!

Skully.

  • [supprimé]

  • Message #7
  • Modifié
Skully wrote:Par contre dans le lien de petitdernier, il est dit que la x86_64 demande plus de mémoire vive. Je n'ai que 2 Go de mémoire vive, et ils parlent du double, soit 4 Go...
Il ne faut pas confondre 2 choses :
- une version 64 bits permet d'exploiter 4 Go de RAM ou plus. En effet, en 32 bits le système d'exploitation ne peut gérer que jusqu'à 3 Go de RAM (à moins de recourir au PAE mais bon...)
- en 64 bits, les mêmes programmes utilisent plus (+) de mémoire vive que leur version 32 bits 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. Mais ne t'inquiètes pas, avec 2 Go de RAM tu as de la marge.
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.
Je croyais que c'était l'adressage des données qui prenait plus de place et non pas pas les données.
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.
pmarion wrote:
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.
Je croyais que c'était l'adressage des données qui prenait plus de place et non pas pas les données.
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.
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).

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.

  • [supprimé]

  • Message #10
  • Modifié
@pmarion
Exact, la chaine de caractère sera la même, car un char sera toujours sur 8 bits. Par contre, sur un OS 32 bits un int est en 32 bits, sur un OS 64 bits il passe sur 64 bits.

  • [supprimé]

  • Message #11
  • Modifié
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.
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.
Donc ce n'est absolument pas un grossier raccourci. Ceci dit toutes les variables ne sont pas 2 fois plus grosses (la preuve avec les caractères qui restent à 8 bits).
Pour l'optimisation, c'est plus (+) la responsabilité du compilateur. En réalité une application basique (pas scientifique) n'a rien à faire d'avoir des entiers 64 bits. Déjà un 32 bits est largement suffisant ! (je ne pense pas que beaucoup de développeurs est besoin dans leurs applications d'avoir des nombres supérieur à 4 milliard...). Mais là est la grosse erreur aussi, l'avantage de l'AMD64 ce n'est finalement pas réellement le 64 bits, c'est tout le reste : plus (+) de registres, mise à jour de la base commune (utilisation de SSE), etc.
J'ai trouvé sur un bouquin de C/C++ de Christian Casteyde :
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.
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 🙂

  • [supprimé]

  • Message #13
Oui c'est une histoire d'implémentation dans ce cas.
Dans les tests que j'avais fait il y a quelques mois avec gcc, sur OS 64 bits, un int est codé en 64 bits.
Un simple essai : 
#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;
    }
Le résultat : 
$ 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
Donc int = 32 bits.

++
J'ai fait le test (j'ai Fedora x86_64) : 
#include <iostream>

int main(void)
{
    int unsigned a = 5000000000;
    std::cout << a << std::endl;
    return 0;
}
J'obtiens : 
$ 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
Là même chose avec long affiche bien 5000000000.

Par contre si j'utilise toujours long mais que je compile cette fois avec le paramètre -m32, je me fait jeter par le compilateur : 
$ 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é
Ce qui vérifie bien ce qui est écrit dans mon bouquin.

PS: Ah Remi m'a doublé avec une technique bien plus élégante 🙂

  • [supprimé]

  • Message #16
Tiens j'avais fais exactement le même test que remi, et j'étais persuadé que l'int prenait 8 octets. Ma mémoire flanche ?
Enfin si c'est seulement 4 octets à la limite c'est mieux, ça économise de la mémoire.
D'accord, merci de vos réponses. Je téléchargerai donc l'iso comme prévu dès que possible.
2 mois plus tard
Un grand méchant up pour demander un bilan, du coup.
Il y a beaucoup d'applis qui sont dans les dépôts en 32 bits et pas en 64? À part Wine, mais je suppose qu'à l'install de wine il remonte tout seul les ia32lib, comme sous Ubuntu.
Sinon, qu'est-ce qui change fondamentalement, si je suis prêt à faire des concessions sur le flash? Il y a d'autres choses qui ne passent pas en 64?
Dans l'attente de votre réponse, veuillez agréer, et tout et tout
Bonsoir,

wine est l'une des rares applications non disponibles en 64 bits dans les dépôts officiels : son code contient des instructions assembleur 32 bits. Mais un portage 64 bits est en cours de développement.
Il y a aussi la bibliothèque de compatibilité pour les applications compilées avec gcc 2.9x (compat-libstd-c++-296) ; à l'époque où ce compilateur était utilisé, les architectures 64 bits ne couraient pas les rues ^^.

Il y a quelques applications sur RPM Fusion non disponibles en 64 bits (dont unace), mais cela concerne des applications propriétaires dont l'éditeur n'a pas fourni de binaire 64 bits.

Quant à la question « 64 bits vs 32 bits », c'est une question qui revient souvent sur le forum, et dont les réponses sont parfois (si peu) truffées de troll. Les archives tendent cependant à montrer un gain de performance d'une Fedora 64 bits sur archi. 64 bits, avec la RAM qu'il faut, par rapport à une Fedora 32 bits.

Enfin, depuis qu'Adobe propose en version bêta un plugin 64 bits natif, il n'y a plus de grosse concession à faire... Même Sun propose un plugin Java 64 bits depuis peu, quoiqu'OpenJDK le proposait depuis le début.