Je viens de terminer une install de Mandriva2008 PowerPack sur un portable neuf - pas le mien mille fois hélas ;-) - et j'ai été fort surprise de voir :
1 - qu'il n'y avait qu'un seul DVD commun aux versions 32 et 64 bits (alors que dans les revues on trouve un DVD pour chaque architecture)
2 - qu'il ne soit pas proposé d'option permettant de choisir à l'installation une des 2 versions
Aussi dès que l'installation de base fut terminée l'une des toutes premières choses que je fis, fut de vérifier la nature des paquets installés.
Comme je m'en doutais le système d'installation a privilégié l'option x86_64. Mais pas uniquement... en effet les RPM i586 se retrouvent en nombre, comme le pluginFlash - normal je crois vu qu'il n'existe qu'en 32bits.
J'ai besoin de votre avis sur quelques points :
1/ Cette installation est elle réellement propre et normale ?
2/ Ne serait il pas plus sage d'envisager - comme il me semble avoir lu ici ou là - de refaire une installation intégralement en 32 bits (i586) ?
3/ Et dans ce cas comment s'y prendre avec le DVD officiel ?
Une autre chose m'intrigue - en fait cela provient de mon ignorance de Windows - il y a en plus de la partition Windows (disque C:) deux autres partitions (E: et F:) qui n'étaient pas visibles avant l'installation de Linux. Sur une DD de 160Go dont j'ai redimentionné la taille initialement dévolue à NTFS il y ainsi dans l'ordre d'entrée de Grub :
- /dev/sda1 (/mnt/win) de 118Mo en FAT
- /dev/sda2 (/mnt/win_c) qui se trouve être la partition NTFS de Windows
- /dev/sda4 (/mnt/win_2) de 3.3Go en FAT
- /dev/sda6 (/mnt/win_3) de 2.5 Go en FAT
La création de sda1, sda4 et sda6 ne sont pas de mon fait;
j'ai certes partitionné le DD afin d'avoir
- XP systeme et appli en NTFS (sda2)
- une partition réservée aux données sous Win en FAT (sda5)
- ainsi que celles résevées à Linux, swap comprise ( de sda7 à sda11)
mais pas plus !
Je suis à l'écoute de toute info qui éclairera ma lanterne.
L'autre point que je trouve surprenant c'est la dénomination /dev/sdax pour un disque IDE
Journal x86_64 en général et sur Mdv en particulier
21
jan.
2008
# 32/64
Posté par patrick_g (site web personnel) . Évalué à 4.
Ensuite pour le débat 32/64 bits si ton laptop marche bien il n'y a pas de raison de vouloir tout réinstaller en 32 bits. Ce n'est que si tu constates des incompatibilités diverses et variées avec des softs que tu utilises qu'il faudra y penser.
[^] # Re: 32/64
Posté par Clément David (site web personnel) . Évalué à 4.
- C: partition de boot normal de windows
- E: partition de 'Restauration système'
- F: partition de Média Center (boot sur un windows minimal quand tu appui sur la touche 'DVD')
Mon portable était à l'origine partitionné comme cela.
[^] # 32/64
Posté par Mars . Évalué à 2.
# Option d'installation
Posté par Dr BG . Évalué à 5.
En l'installant sur mon macbook j'avais aussi eu cette surprise. J'ai donc recommencé l'installation en 32 bits parce que le wifi ne machait pas sinon.
Pour i586 et x86_64 proposés par le gestionnaire de paquet, je trouve aussi que c'est très déroutant. Un débutant à qui on a installé tout seul en 64 bits ne saura pas quel paquet choisir... surtout qu'on ne lui a pas demandé à l'installation quelle était son architecture. Il serait à mon avis plus judicieux de mettre 32 bits par défaut et laisser le choix 64 bits à ceux qui savent ce que c'est et assument leur choix :-)
[^] # Re: Option d'installation
Posté par ʭ ☯ . Évalué à 2.
Exemple vécu, sur x86_64, TORCS ne fonctionnait pas en x86_64. Qu'à cela ne tienne, j'installe la version i586 et ça roule!
⚓ À g'Auch TOUTE! http://afdgauch.online.fr
[^] # Re: Option d'installation
Posté par Dr BG . Évalué à 5.
Personnellement, sans être un expert linux, j'estime ne pas être trop débutant (j'ai commencé avec une Red Hat 5.1), mais je ne sais pas trop à quoi va ressembler mon système si je mélange au petit bonheur la chance des versions i586 et x86_64.
# A propos des disques vu comme /dev/sd*
Posté par yannig (site web personnel) . Évalué à 4.
Mais comme se sont également des gars pragmatique, ils ont laissé l'ancienne couche pour garder les vieux chipset supportés.
# Explications sur 64 bits
Posté par Matthieu . Évalué à 3.
[^] # Re: Explications sur 64 bits
Posté par Nicolas Boulay (site web personnel) . Évalué à 1.
"La première sécurité est la liberté"
[^] # Re: Explications sur 64 bits
Posté par Matthieu . Évalué à 3.
[^] # Re: Explications sur 64 bits
Posté par Nicolas Boulay (site web personnel) . Évalué à 5.
http://f-cpu.seul.org/~nico/amd64.html
En résumé, l'archi x86_64 est en moyenne 20% plus rapide grâce au doublement des registres disponibles. Cela permet aussi d'utiliser plus de 2 à 4 Go par processus.
Les bits PAE servaient pour des gros serveurs intel pour avoir jusqu'à 64 Go de RAM. Mais chaque processus ne pouvaient voir que 4 Go à la fois.
"La première sécurité est la liberté"
[^] # Re: Explications sur 64 bits
Posté par Matthieu . Évalué à 5.
D'après ce que moi j'ai compris du 64 bits, il ne sert que si l'on a plus de 4 Go de mémoire. Et encore, avec le mode PAE, on peut faire reconnaître à son système d'exploitation (n'importe lequel) plus de 4Go de mémoire. Sauf que une application ne pourra pas utiliser plus de 4Go (et encore, j'ai l'impression qu'il existe des bidouilles pour).
Donc, si l'on a pas plus de 4Go de mémoire, et si l'on a pas d'application qui utilise plus de 4Go de mémoire, le 64bits n'est pas nécessaire.
Il a eu des commentaires sur le 64 bits et la mémoire il n'y a pas longtemps, mais je ne retrouve pas.
[^] # Re: Explications sur 64 bits
Posté par Nicolas Boulay (site web personnel) . Évalué à 1.
"La première sécurité est la liberté"
[^] # Re: Explications sur 64 bits
Posté par Matthieu . Évalué à 2.
Par contre, tu fais des tests sur des applications spécifiques que l'utilisateur lambda n'utilise pas tous les jours (il n'y a que les utilisateurs avancés pour compiler leur kernel).
Il y a deux choses intéressantes à savoir (du moins qui m'intéresse) :
- dans l'utilisation de tous les jours (messagerie, traitement de texte et navigation), est-ce que le 64 bits est mieux ?
- concrètement pourquoi le 64 bits serait-il plus rapide ?
[^] # Re: Explications sur 64 bits
Posté par Nicolas Boulay (site web personnel) . Évalué à 3.
Dans le cadre bureautique, suffisamment de RAM et un disque dure rapide auront bien plus d'effets !
Par contre, ne me dis pas que tu n'utilises jamais de player video ou de compression mp3... La compilation est un des benchs sur un nombre assez important...
"La première sécurité est la liberté"
[^] # Re: Explications sur 64 bits
Posté par Matthieu . Évalué à 1.
Dans le cadre bureautique, suffisamment de RAM et un disque dure rapide auront bien plus d'effets !
Et dans le cadre d'un serveur ? (fichier, dns, ldap...)
Et quid de Windows XP 32/64 ?
[^] # Re: Explications sur 64 bits
Posté par Nicolas Boulay (site web personnel) . Évalué à 6.
Vu que c'est un benchmark de desktop...
Et quid de Windows XP 32/64 ?
Sur Linuxfr, tu penses bien que l'on a un peu rien à foutre. Le seul truc qui est à peu prêt sûr, c'est que tu trouvera beaucoup de drivers ou du programme qui ne marche pas sous un windows 64 bits.
"La première sécurité est la liberté"
[^] # Re: Explications sur 64 bits
Posté par Matthieu . Évalué à -8.
[^] # Re: Explications sur 64 bits
Posté par Matthieu . Évalué à 1.
[^] # Re: Explications sur 64 bits
Posté par CrEv (site web personnel) . Évalué à 3.
Sous windows, il peut être très très intéressant de passer au 64 bits _avant_ 4Go tout simplement parce que si tu colles 4Go dans un vista (je sais pas pour les autres) tu en vois ... 3.5Go ...
et là on dit merci microsoft !
[^] # Re: Explications sur 64 bits
Posté par Jean-Philippe (site web personnel) . Évalué à 1.
[^] # Re: Explications sur 64 bits
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
"La première sécurité est la liberté"
[^] # Re: Explications sur 64 bits
Posté par Sébastien Rohaut . Évalué à 2.
Sur un Core2Duo à 2.66GHz, un rip en grande taille, redim HQ, une passe, en xvid+mp3 192kbits qui faisait 27-30 fps en 32 bits, fait 38-40 fps en 64 bits.
Alors certes tout le monde ne rippe pas de dvds, mais sur un montage video ou une transformation finale de dv vers dvd ou divx, c'est un gain de temps énorme. Je suppose que le traitement d'image se trouve aussi accéléré.
Pour le reste, pour la bureautique ou du web, la différence n'est pas visible. J'ai aussi testé pour m'amuser un superpi optimisé 64bits, je suis passé de 17 secondes à 11.
My 2 cents.
[^] # Re: Explications sur 64 bits
Posté par eon2004 . Évalué à 2.
[^] # Re: Explications sur 64 bits
Posté par patrick_g (site web personnel) . Évalué à 5.
En ce qui concerne les x86_64 le gros avantage de l'archi c'est qu'on passe de 8 à 16 registres.
[^] # Re: Explications sur 64 bits
Posté par GeneralZod . Évalué à 5.
[^] # Re: Explications sur 64 bits
Posté par ʭ ☯ . Évalué à 3.
⚓ À g'Auch TOUTE! http://afdgauch.online.fr
[^] # Re: Explications sur 64 bits
Posté par Matthieu . Évalué à 2.
Je cite notre cher ami IsNotGood
Ben oui, il n'y a aucun raisons "évidentes" de passer à 64 bits. Je n'ai jamais dit le contraire.
Le 64 bits se justifie si on a un gros besoin de mémoire (plus de 4 Go (ou 2 ?) par processus ou plus de 64 Go pour le système (i686 a le mode PAE)).
Il faut noter que cette réflexion est pas dépendante du système d'exploitation vu que l'on parle au niveau hardware.
Ma réflexion est : On nous parle tout le temps du 64 bits. On nous fait croire que le 64 bits c'est carrément mieux que le 32 bits. Est-ce vrai ? est-ce que ça vaut le coup de passer en 64 bits ?
[^] # Re: Explications sur 64 bits
Posté par ʭ ☯ . Évalué à 5.
> Est-ce vrai ? est-ce que ça vaut le coup de passer en 64 bits ?
Si tu te poses ces questions, la réponse est non. Passer en 64 bits est utile à ceux qui (au choix) :
- Sont prêts à essayer un truc moins courant juste pour voir.
- Sont intéressés par un gain de performance sur de longs calculs.
- Ont assez d'espace RAM et disque dans leur machine pour ne pas être pénalisés pour une occupation mémoire supérieure.
- N'ont pas peur de devoir se passer de logiciels propriétaires (ou bidouiller pour les utiliser).
- Peuvent se passer de quelques logiciels ou pilotes non encore portés en x86_64. Ce dernier point ne peut cependant s'améliorer que si le nombre d'utilisateurs x86_64 est suffisant.
⚓ À g'Auch TOUTE! http://afdgauch.online.fr
[^] # Re: Explications sur 64 bits
Posté par Obsidian . Évalué à 7.
- A prix égal et, surtout, si le système est compatible 32, cela ne vaut pas le coup de se priver. Ca permet de voir venir les nouveautés, et de se familiariser avec la programmation des nouveaux jeux d'instructions et la nouvelle architecture, ce qui est toujours très intéressant ...pour peu que l'on programme encore un minimum en assembleur ! Si c'est pour tout demander à gcc et faire de la compatibilité ascendente en nivelant par le bas, ça n'a aucun intérêt.
- Un nouveau jeu d'instruction et surtout des registres supplémentaires permettent d'être très efficace. Un registre supplémentaire, c'est autant d'accès bus en moins, et çà, ça fait une très grande différence sur un processeur de PC.
- 64 bits, ça permet de dépasser 4 Go d'adressage direct et on en aura forcément besoin à terme. 512 Mo de RAM tend à devenir la norme et même les portables "conçus pour le jeu" chez Dell, par exemple, déjà sont livrés avec 2048 Mo.
Maintenant, je ne suis pas sûr que ce soit une bonne chose en soi que laisser cet état de fait devenir la norme. Dépasser 4Go, ce n'est pas du tout la même chose que de dépasser 64Ko. Même en progressant, la consommation de RAM devrait croître de manière linéaire, pas exponentielle ! Pour la plupart des gens, ce ne sont que des chiffres, que se valent à différentes époques, à la manière des francs et euros constants.
- Gros avantage, au niveau du traitement des blocs de données : Tu traites tes zones par blocs de 8 octets et plus 4 et donc à chaque fois que tu as une boucle, tu divises par deux l'overhead dû au traitement des invariants. Or, la copie de blocs de données est extrêmement fréquente en informatique. Quand tu regardes des vidéos, certes (même si elles ne durent que 5 minutes, tu aspires quand même à ce qu'elles soient fluides dans l'intervalle, et qu'elles ne consomment pas trop de temps CPU, ni trop de bus), mais également quand tu travailles sous GIMP, ou même simplement lorsque tu déplaces une fenêtre ! Une fenêtre en 1280*768 et en 32 bits, mine de rien, ça fait beaucoup de mémoire ! Et comme, lorsque la résolution augmente, elle le fait dans les sens verticaux et horizontaux, cette quantité augmente au carré, encore une fois.
Bref, à partir d'une certaine quantité de données, travailler en 64 bits peut soulager ton processeur et augmenter, même d'un point de vue uniquement théorique, la rapidité d'exécution d'un algorithme, et ce même en dessous de 4Go de RAM.
important : Tout ceci n'est réellement valable que si ton bus et ta mémoire sont eux-aussi en 64 bits. Sinon, il y a conversion par des circuits externes et évidement, les perfs chutent.
- Les "double" tiennent enfin, à nouveau, sur un seul registre. J'ai toujours considéré cela comme une faiblesse des formations en programmation. J'ai un float et un double. Le double a une mantisse beaucoup plus large pour le même prix. Alors, je choisis le double, au point que les nouveaux programmeurs ne savent même plus que float existe.
Les tailles 32 et 64 bits des flottants sont ainsi parce qu'elles sont nomalisées, mais personne ne sait vraiment comment elles sont traitées en profondeur. Depuis qu'il y a un coprocesseur, les gens ne s'en soucient plus. Même les environnement de développement intégrés proposent des double par défaut. N'empêche que les accès bus et la mémoire consommée en demeurent effectivement doublés.
A l'époque des 8 bits, on utilisait déjà les mêmes formats, et il fallait de toutes façons une boucle pour traiter l'un comme l'autre. Sur un 32 bits, un float tient dans un registre (tel que EAX), pas un double.
Puisque le format de ces nombres est normalisé quelque soit l'architecture, on peut espérer des gains sur les programmes qui utilisent massivement le double. La plupart, pour ce que j'ai pu en voir.
- Enfin, 65535, c'est tout de suite atteint. 4 milliards beaucoup moins vite, mais ça reste courant. 2^64, ça dépasse le nombre de galaxies (visible) contenues dans l'univers entier. Ca veut dire aussi qu'on ne pourra jamais adresser autant de mémoire même au niveau atomique.
- Le principal ennui, donc, en changeant d'architecture est que la taille des données d'un même programme double pratiquement, du simple fait d'être recompilé.
C'est inquiétant parce que la croissance exponentielle de la mémoire requise est due en grande partie aux dépendances entre les différentes couches d'abstraction. Si on continue à en ajouter, et si en plus les couches existantes consomment plus de mémoire sans même gagner une ligne de code, alors on va atteindre physiquement les limites de la mémoire adressable comme on a atteint celles de la finesse de la gravure, et ce avant même de passer aux 128 bits.
Donc, faire des frais pour passer explicitement en 64 bits, ça ne sert à rien. Par contre, si c'est dans un plan prévu de remplacement de tes machines, ce n'est (presque) que des avantages.
[^] # Re: Explications sur 64 bits
Posté par Antoine . Évalué à 3.
Un registre supplémentaire, c'est autant d'accès bus en moins, et çà, ça fait une très grande différence sur un processeur de PC.
Il n'y a pas d'accès bus externe puisque la pile locale reste presque toujours quelque part dans le cache L1. Je ne dis pas que l'amélioration est inexistante (un adressage de registre est toujours plus léger qu'un adressage indirect) mais c'est loin d'être "une très grande différence".
Gros avantage, au niveau du traitement des blocs de données : Tu traites tes zones par blocs de 8 octets et plus 4 et donc à chaque fois que tu as une boucle, tu divises par deux l'overhead dû au traitement des invariants. Or, la copie de blocs de données est extrêmement fréquente en informatique.
Faux, non seulement on pouvait déjà transférer des données sur 64 bits (en utilisant par exemple les registres MMX qui sont présents sur tous les CPU depuis dix ans), mais en plus les transferts mémoires sont limités par la bande passante externe du CPU, qui est minuscule par rapport à la puissance de traitement disponible au coeur du CPU.
Tout ceci n'est réellement valable que si ton bus et ta mémoire sont eux-aussi en 64 bits
C'est déjà le cas depuis le Pentium (depuis 1995 !).
Les "double" tiennent enfin, à nouveau, sur un seul registre.
Encore faux. Les "double" ont toujours tenu sur un seul registre, puisqu'ils ont toujours eu des registres dédiés au sein de l'unité de calcul à virgule flottante (en tout cas depuis que cette dernière existe, c'est-à-dire bien longtemps).
Le double a une mantisse beaucoup plus large pour le même prix.
Le même prix ? C'est vite dit. Il prend deux fois plus de place en mémoire, ce qui n'est pas très gênant certes, mais surtout les opérations effectuées sur les double sont plus lourdes que sur les float, ce qui fait que la plupart des CPU peuvent en exécuter moins par cycle.
Le principal ennui, donc, en changeant d'architecture est que la taille des données d'un même programme double pratiquement, du simple fait d'être recompilé.
Encore faux, seuls les pointeurs doublent de taille, les entiers selon les cas restent sur 32 bits (int) ou passent à 64 (long), quand aux flottants leur taille est inchangée comme expliqué plus haut.
[^] # Re: Explications sur 64 bits
Posté par briaeros007 . Évalué à 1.
Sans me prononcer sur la validité de ton message (qui me semble tout a fait correct au demeurant ;) , il me semble que les personnes plus haut on dis que le problème du x86 c'est justement que tu es limité pour la retro compatibilité, et que le x86_64 "disait" que tu étais mini en sse2", et donc que le compilo pouvait utiliser ce genre de registre
non ?
[^] # Re: Explications sur 64 bits
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
"La première sécurité est la liberté"
[^] # Re: Explications sur 64 bits
Posté par Obsidian . Évalué à 2.
C'est ce que j'explique au-dessus. C'est quelque chose dont on fait abstraction parce que l'on s'appuie sur le coprocesseur mathématique qui, lui, est effectivement en 64 bits depuis longtemps. Mais les données n'y passent pas leur vie.
Même chose.
.
Les long changent donc de format, les pointeurs aussi, et tout ce qui manipulé en interne à la compilation du code dans les registres. De toutes façons, ces formats de nombres concernent ici le langage C. Un changement d'architecture doit être examiné sur toutes les plateforme de développement.
Oui. Par moi. Relis bien.
[^] # Re: Explications sur 64 bits
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
Tu sais les IBM 360 utilise des pointeurs 128 bits... Faut dire aussi qu'il mappe automatiquement les HD en mémoire.
"La première sécurité est la liberté"
[^] # Re: Explications sur 64 bits
Posté par briaeros007 . Évalué à 1.
C'est moi ou il n'y a aucune relation entre le nombre de galaxie (visible) et le fait que tu puisse adresser de la mémoire au niveau atomique ?
Si tu disais 10**120, j'aurais pu comprendre : c'est supérieur au nombre d'atome dans l'univers, mais là...
[^] # Re: Explications sur 64 bits
Posté par Obsidian . Évalué à 2.
[^] # Re: Explications sur 64 bits
Posté par briaeros007 . Évalué à 1.
Idem pour "il me semble que 2^64 ne rentre pas dans un boitier de pc". Et pourquoi pas ?
pour m'amuser, je vais mettre des ordres de grandeurs :
si je me rapelle bien mes cours de maths, savoir combien 2^64 fait en puissance de 10 c'est :
log (2^64)/log(10)
ce qui me donne (d'après maxima) ~ 19.266
donc 10^20.
C'est si énorme que ca 10^20 atomes ?
Nombre de bactérie sur le corps humain : 10^15 ! ( http://en.wikipedia.org/wiki/Human_flora )
Il est nécessaire et suffisant alors que chaque bactérie soit composé de 10^5 atomes et on atteint, rien qu'avec les bactéries dans un corps humain, la limite imposé!
Et si je récupère mes souvenirs de physiques :
Masse molaire du carbone =12g.
Dans une mole de carbone, il y a N(nombre d'Avogadro) atomes de carbones.
C'est à dire :
N=6,0221415 × 10^23
On a déja dépassé notre 10^20 d'au moins 2 ordres de grandeur
[^] # Re: Explications sur 64 bits
Posté par Nicolas Boulay (site web personnel) . Évalué à 3.
Un atome a un diamètre moyen de 0,1 nanomètre (10^-10 m).
Donc 10^20 atomes rentre dans un cube de racine cubique de 10^20, sois 4.7 * 10^6 atomes, sois un cube de moins de 1 mm de coté...
"La première sécurité est la liberté"
[^] # Re: Explications sur 64 bits
Posté par Obsidian . Évalué à 3.
Ce que je voulais dire, c'est que si l'on suit une progression géométrique style loi de Moore, on va finir par rencontrer ce genre de souci dans un intervalle de temps comparable à celui qu'il a fallu pour passer de 16 à 32 bits, c'est-à-dire pas grand chose. Même avec mille atomes par bit de mémoire, ça reste compliqué à mettre en oeuvre.
Pour autant, ça ne remet pas en cause l'utilité d'une architecture 64 bits. On est même à 128 sur certaines machines (consoles de jeux, en particulier) parce que c'est pratique pour des utilisations ciblées et que celles-ci sont suffisamment rentables à elles seules pour justifier la conception de telles machines.
En ce qui concerne l'adressage proprement dit, 4 Go de mémoire sont déjà atteints et exploités depuis quelque temps. Rien que ça justifie le 64 bits. Par contre, en considérant 2^64 octets de mémoire, un facteur très limitant restera le temps qu'il faut pour y accéder.
Evidemment, on paralélisera, on fera des MMU plus puissantes, etc. M'enfin, j'espère que d'ici à ce que la limite soit atteinte, on sera passé à une autre architecture que celle d'un PC.
[^] # Re: Explications sur 64 bits
Posté par Nicolas Boulay (site web personnel) . Évalué à 3.
Si les besoins "maximum" sont aujourd'hui de 64Go (36 bits),on en a encore pour 35 ans avant d'arriver au maximum. C'est loin mais le verra.
"La première sécurité est la liberté"
# j'ai compris qq petites choses
Posté par Mars . Évalué à 5.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.