Il y a un an ou deux, installer un noyau 64 bits pouvait s'avérer problématique surtout si on devait utiliser des applis proprios, généralement uniquement compilées pour 32 bits. (Il y'avait Flash, Skype, Lotus Notes, des machins de ce genre).
Disposant d'un PC avec 4 Go de Ram, j'avais installé un noyau 64 bits avant de tout réinstaller en 32 bits pour un truc du genre décrit plus haut (un flasheur de firmware, je pense, je ne me souviens plus).
Aujourd'hui, je suis toujours en 32 bits, utilisant mes 4 Go de RAM grâce à un noyau PAE, automatiquement installé par Ubuntu.
Ma question est donc: qu'aurais-je à gagner à réinstaller une distrib 64 bits ?
- En performance ?
- En autonomie ?
- En n'importe quoi d'autre ?
Et quel serait le prix à payer ?
J'ai même lu des rumeurs comme quoi le 64 bits serait plus gourmant et donc boufferait plus vite la batterie. Qu'en est-il ?
Et vous, pourquoi êtes-vous en 64 ou 32 bits ?
# Noyau / espace utilisateur
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 10.
Déjà, tu peux distinguer noyau et espace utilisateur, parce que Linux amd64 est parfaitement capable de lancer des processus i386. En particulier, il est tout à fait possible d'installer une distribution i386 avec un noyau amd64.
[^] # Re: Noyau / espace utilisateur
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 9.
Et ça permet d'utiliser plus de 4 Gio de mémoire sans passer par les PAE, donc probablement de façon plus efficace. Bien évidemment, chaque processus ne peut accéder à plus de 4 Gio, en revanche.
[^] # Re: Noyau / espace utilisateur
Posté par Eric P. . Évalué à -3.
A propos:
Il n'y a pas besoin de PAE pour utiliser 4 Go de RAM. L'extension PAE est necessaire pour en addresser plus (mais ne changera rien au fait que chaque processus est limite a 4 Go).
Excusez l'absence d'accents dans mes commentaires, j'habite en Australie et n'ai pas de clavier francais sous la main.
[^] # Re: Noyau / espace utilisateur
Posté par pipo_molo . Évalué à 5.
Me semble que si. Y'a pas que la RAM dans l'espace adressable.
https://secure.wikimedia.org/wikipedia/en/wiki/Memory-mapped_I/O
[^] # Re: Noyau / espace utilisateur
Posté par foutaises . Évalué à 1.
Je confirme.
Sans le noyau pae, debian/ubuntu ne détecte pas toute ma ram.
[^] # Re: Noyau / espace utilisateur
Posté par BB . Évalué à 1.
Alors, je viens d’en acheter 4Go et de me renseigner.
En fait c’est un peu plus compliqué que ça et ça dépend des options de compilations du noyau. Je n’y ai rien compris, à part que c’est un petit peu au bonheur la chance. Grosso modo il y a une certaine quantité de mémoire réservée par le matos et le noyau, on peut se retrouver, avec ou sans PAE, avec plus ou moins de mémoire en fonction (machine — processeur et matériel —, bios, noyau — ça vaut pour windows aussi, suivant l’édition — et pour le noyau en fonction des options de config. et des patchs — je soupçonne Ubuntu qui cible le desktop de changer ça par rapport à Debian).
[^] # Re: Noyau / espace utilisateur
Posté par Marotte ⛧ . Évalué à 1.
C'est vrai que sur la page d'accueil on a une écran de desktop et un laptop mais Ubuntu server.
Je ne suis pas sûr que Canonical cible seulement le desktop avec Ubuntu.
[^] # Re: Noyau / espace utilisateur
Posté par Sébastien Koechlin . Évalué à 6.
On peut d'ailleurs noter que certains développeurs du noyau prévoient un mode x32. Ce mode doit combiner le meilleur des deux modes:
Lire http://lwn.net/Articles/456731/ et voir https://sites.google.com/site/x32abi/
# Mémoire et performance
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 10.
Des logiciels en amd64 consomment un peu plus de mémoire, puisqu'ils utilisent des pointeurs sur 64 bits au lieu de 32.
En revanche, ils sont probablement un peu plus rapide, parce qu'ils ont accès à plus de registres, ce qui évite des opérations de permutation.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 10.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Mémoire et performance
Posté par zerkman (site web personnel) . Évalué à 3.
on perd d'un côté, on gagne de l'autre, pas sûr que l'empreinte mémoire soit si augmentée que ça.
et pour les calculs intensifs, on gagne facilement 20% en effet.
Je rajouterai qu'en 64 bits le FPU est définitivement enterré (il est inaccessible), c'est le SSE qui est utilisé pour les calculs flottants, donc adieu le format interne de 80 bits même pour les variables de type float, mais du coup bonjour les incompatibilités binaires d'exécution entre 32 et 64 bits... Par contre, pour le calcul en float 32-bits pur, ça torche.
Remarquez qu'on peut aussi utiliser le SSE au lieu du FPU sous pour le calcul flottant en 32 bits, avec l'option -mfpmath=sse de gcc.
[^] # Re: Mémoire et performance
Posté par Troy McClure (site web personnel) . Évalué à 4.
le x87 n'est pas inaccessible, il est juste deprecié à la faveur de sse2, mais a priori on peut continuer à l'utiliser, je pense d'ailleurs que le type long double continue à l'utiliser.
cf par exemple http://www.virtualdub.org/blog/pivot/entry.php?id=107
[^] # Re: Mémoire et performance
Posté par oinkoink_daotter . Évalué à 0.
Les perfs ne sont pas pathétiques de chez pathétique dans ce cas la ? Si je me rappelle bien, le P4 n'avait déjà plus qu'une sombre émulation du x87
[^] # Re: Mémoire et performance
Posté par lasher . Évalué à 2.
Les perfs sont moins bonnes. Cependant, parfois, l'important c'est la reproductibilité des résultats. J'ai bossé avec des partenaires industriels qui refusaient mes optimisations parce que l'ordre des opérations sur les flottants n’était plus garanti. En pratique ca n'aurait rien du changer (les instructions SSE2 et plus sont effectuées sur 80 bits en interne), mais du coup la norme IEEE754 sur 64 bits n’était plus respectée, et malgré des résultats plus précis, ils ne pouvaient plus passer les tests de régression de leurs clients... Du coup : FPU.
[^] # Re: Mémoire et performance
Posté par Troy McClure (site web personnel) . Évalué à 3.
Tu voulais dire FPU à la place de SSE2 et SSE2 à la place de FPU, non ?
[^] # Re: Mémoire et performance
Posté par lasher . Évalué à 2.
Non non. FPU == 64 bits "purs" là où SSE2+ == 80 bits en interne lors de l’opération.
[^] # Re: Mémoire et performance
Posté par zerkman (site web personnel) . Évalué à 2.
c'est peut être en 80 bits en interne en SSE2 (mais je doute), mais dans tous les cas les résultats intermédiaires sont stockés en 64 bits, contrairement au x87 où les valeurs contenues dans les registres sont sur 80 bits. d'où l'incompatibilité.
[^] # Re: Mémoire et performance
Posté par lasher . Évalué à 0.
Tu peux douter tant que tu veux, ça reste vrai. :) L’unité flottante utilisée par les instructions SSE est sur 80 bits en interne, avec accumulation potentielle si tu peux "pipeliner" les opérations (d'ou une meilleure précision). Sauf que le client de nos partenaires utilisait des machines "vectorielles" NEC qui se contentaient de la norme stricte IEEE, et donc les tests échouaient malgré une précision accrue.
De plus, si tu utilises le compilateur d'Intel (ce qui était mon cas), a partir du moment ou du spécifies -mieee-strict (ou un truc du genre), la plupart des optimisations qui devraient etre legales (puisque + et * sont commutatifs) deviennent "illégales" du point de vue d'icc (justement à cause des problèmes d'arrondis), et icc génère du code x87.
[^] # Re: Mémoire et performance
Posté par lasher . Évalué à 1.
Breaking news. Alors j'ai pigé. Apparemment il est possible de forcer la FPU x87 à se limiter à 64 bits, alors que pour l’unité SSE, c'est tout simplement pas possible.
[^] # Re: Mémoire et performance
Posté par Troy McClure (site web personnel) . Évalué à 4.
franchement je pense que tu te trompes. SSE2 c'est 64 bits en double precision, et c'est tout. Des problemes de non-conformité ieee peuvent survenir avec les instructions fused mult-add , mais elles n'existaient pas en sse2. Je te laisse chercher une url qui va dans ton sens, a mon avis tu vas avoir du mal.
[^] # Re: Mémoire et performance
Posté par lasher . Évalué à 1.
Bon, the intraweb a l'air de te donner raison. Cependant, je me donne le droit de questionner la réalité et de revenir ici avec plus d'informations.
[^] # Re: Mémoire et performance
Posté par Troy McClure (site web personnel) . Évalué à 3.
Comme précisé par ouasse , c'est bien le fpu x87 qui a des registres sur 80-bits. Heureusement intel n'a pas réédité cette colossale connerie avec le SSE2 dont les registres 128 bits contiennent deux reels en double précision, et qui effectue des calculs conformes a IEEE754.
[^] # Re: Mémoire et performance
Posté par dlewin . Évalué à 3.
donc un pointeur <64 prend 64 de tout façon, c'est ça ?
Il n'est donc pas possible, comme c'est le cas dans l'ARM Cortex de mixer pour avoir des données de tailles différentes alignées en mémoire pour prendre moins de place ?
# Commentaire supprimé
Posté par Anonyme . Évalué à 7.
Ce commentaire a été supprimé par l’équipe de modération.
# Commentaire supprimé
Posté par Anonyme . Évalué à 3.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Quels avantages à installer un noyau 64 bits ?
Posté par Sébastien Koechlin . Évalué à 10.
Ok, c'est parti.
Le PAE (Extension d'adresse physique) est un principe plutôt simple: le MMU (Unité de gestion mémoire) qui fait la conversion entre adresse logique et adresse physique est étendu afin que les adresse physiques soient codées sur 36 bits (64Gio). Les adresses logiques restent sur 32 bits (4gio), ce qui explique que les processus soient limités à 4Go.
Lorsque le processeur accède à une case mémoire, l'adresse logique sur 32 bits est convertie en adresse physique sur 36 bits via le TLB (Translation Lookaside Buffer) et tout le monde est content. De ce coté, ça n'a quasiment aucun impact.
Pour le kernel, les choses sont moins roses. Lui aussi est limité à 4Gio car toutes les adresses sont sur 32 bits. Or le kernel a globalement besoin d'accéder à toute la mémoire de tous les processus (pour mapper les pages du programme, des fichiers, lire ou écrire les données réseau, disque etc...) et comme on a plus de 4 Gio de mémoire, il est impossible de faire tout rentrer dans l'espace d'adressage de 32 bits du kernel.
Ça oblige à revenir aux joies de la mémoire paginées. Le kernel modifie en permanence les réglages de la MMU pour accéder, morceaux par morceaux, aux pages mémoires dont il a besoin. Opération très couteuse parce qu'elle oblige à vider un certain nombre de cache, en particulier le cache TLB qui conditionne tous les accès à la mémoire.
Bref, un bricolage pas très élégant.
[^] # Re: Quels avantages à installer un noyau 64 bits ?
Posté par Martin Peres (site web personnel) . Évalué à 4.
Tu veux pas dire segmentée? C'est bien comme ça qu'on l'appelle quand on a un segment:offset, non?
# Autre question
Posté par tuxicoman (site web personnel) . Évalué à 10.
Dans le cas où tu dois installer/réinstaller une distro, quel est intérêt de rester en 32bits?
Je ne suis passé au 64bits que récemment (sortie de Debian Squeeze) et je n'ai jamais eu à me plaindre depuis. Tout fonctionne (Flash, les jeux 32bits sous wine, etc...)
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à -4.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Autre question
Posté par Troy McClure (site web personnel) . Évalué à 3.
D'ailleurs dans les minimum systeme requirements de windows 8, c'est
1 Go de ram en 32-bit
2 Go de ram en 64-bit
[^] # Re: Autre question
Posté par VictorAche . Évalué à 5.
Ouais, enfin ça veut strictement rien dire, Microsoft Propaganda Inside.
"The trouble with quotes on the internet is that it’s difficult to discern whether or not they are genuine.” Abraham Lincoln
[^] # Re: Autre question
Posté par steph1978 . Évalué à 6.
Et où tu as vu que M$ faisait de l'informatique ?
Ils font du marketing, du commerce, du juridique, du lobbying ; le tout saupoudré de FUD.
[^] # Re: Autre question
Posté par Troy McClure (site web personnel) . Évalué à 2.
moi je veux bien que ce soit de la propagande ou du marketting mais dans quel but ? pourquoi artificiellement gonfler les prérequis de la version 64-bit ?
[^] # Re: Autre question
Posté par steph1978 . Évalué à 5.
je ne serai pas allé jusque là.
imho, juste que en effet, la 64bit nécessite logiquement plus de RAM que la 32bit, donc comme il faut bien donner des pré requis, on va prendre un chiffre simple pour 32bit et le doubler pour 64bit. On est plus dans une approche marketing je pense.
[^] # Re: Autre question
Posté par lasher . Évalué à 2.
Je pense que tu as raison. Il ne faut pas oublier que s'il est vrai que les adresses doublent en taille, mais que pour une application multimédia (DVD, jeu, etc.) par exemple, ce qui consomme le plus de place, ce sont les données, qui elles ne changent pas. La partie purement code et adresses devient anecdotique au fur et à mesure que la somme de données a récupérer grandit.
[^] # Re: Autre question
Posté par Nicolas Boulay (site web personnel) . Évalué à 7.
il y a 2x plus de registre le code est plus rapide.
Si tu as plus de 4 Go de mémoire, le noyau sait utiliser correctement la mémoire en plus pour en faire du cache disque.
SSE2 est inclus d'office ce qui évite de se poser mille question sur la présence ou non de certaines instructions.
"La première sécurité est la liberté"
[^] # Re: Autre question
Posté par tuxicoman (site web personnel) . Évalué à 2.
Tes applis sont pas compilées avec les mêmes optimisations par défau (i386 vs x86-64). la taille des registres, pas besoin de te prendre la tête si tu rajoutes de la RAM...
Après faudrait sortir les benchs plutôt que parler.
[^] # Re: Autre question
Posté par oinkoink_daotter . Évalué à 2.
C'est pire que ça. Ca prend aussi plus de place sur disque si tu veux utiliser du 32 bits et du 64 bits. Ben wii, il te faut l'userland 64 bits plus toute une palanquée de trucs 32 bits pour les programmes 32 bits \o/
# Un avis totalement subjectif et non technique
Posté par redo_fr . Évalué à 1.
Je suis passé en 64bits natif... Parce que mon processeur le pouvait et que je voulais voir s'il y avait vraiment une différence.
Bilan: A mon niveau (usage quotidien: Internet, mail, bureautique, un peu de synthèse 3D, films, musique,...) aucun changement significatif des performances.
La différence, pour moi, réside dans le nombre de cœurs (deux au lieu d'un) et quelques paramètres de noyau "tuné" (IO scheduler, etc...), où je ressent vraiment une plus grande réactivité de l'interface.
Prix à payer: Aucun (si le proc, mais... :) ) Tous mes logiciels habituels fonctionnent (recompilés, car je suis sur "gentoo")
Comme c'est un PC "fixe", je ne peux pas répondre pour la batterie.
Celui qui pose une question est bête cinq minutes, celui qui n'en pose pas le reste toute sa vie.
[^] # Re: Un avis totalement subjectif et non technique
Posté par Vador Dark (site web personnel) . Évalué à 4.
Comment le passage au 64 bits peut-il "activer" un coeur ? Peut-être ne parlais-tu pas de coeurs de processeurs?
[^] # Re: Un avis totalement subjectif et non technique
Posté par redo_fr . Évalué à 4.
Non, non je voulais dire que je suis passé d'un mono-coeur 32 bits à un double coeur 64 bits par changement physique des composants :)
Celui qui pose une question est bête cinq minutes, celui qui n'en pose pas le reste toute sa vie.
# Commentaire supprimé
Posté par Anonyme . Évalué à 9.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Quels avantagesàinstaller un noyau 64 bits ?
Posté par Juke (site web personnel) . Évalué à 7.
Le mercredi 28 septembre 2011 à 16:36 +0200, Effet Rageant a écrit :
> J'avais posé la question il y a environ 6 mois sur La 3Bune ©
Tu refuses donc les conditions d'utilisation ? ©
# Plus mieux bien !
Posté par patrick_g (site web personnel) . Évalué à 6.
En général on gagne en performances (l'extension du nombre de registres fait plus que compenser la taille des pointeurs).
J'ai aussi vu pas mal de mails sur la LKML qui disaient que le code 64 bits était souvent plus propre.
Dans tous les cas on gagne en sécurité (cf la dernière phrase de ce post de Kees Cook).
[^] # Re: Plus mieux bien !
Posté par Altor . Évalué à 4.
Oui, mais comme on est obligé d'installer un système multilib si tu utilises wine, skype ou virtualbox tu risques aussi d'en perdre.
[^] # Re: Plus mieux bien !
Posté par Vador Dark (site web personnel) . Évalué à 4.
Il me semble que l'un des intérêts aussi, pour les non gentooistes, c'est d'avoir des binaires exploitant les jeux d'instructions un peu avancé. Car les distribs 32 bits se doivent d'être compatible avec d'anciennes archis. En plus des nouveaux registres, et des registres plus large, évidemment.
[^] # Re: Plus mieux bien !
Posté par khivapia . Évalué à 10.
Car les distribs 32 bits se doivent d'être compatible avec d'anciennes archis.
N'oublions tout de même pas que même Debian a droppé le support de l'architecture 386 au profit du 486 !
-----------> []
# argumentaire en béton armé
Posté par bubar🦥 (site web personnel) . Évalué à 7.
C'est possible, c'est faisable, c'est fait.
[^] # Re: argumentaire en béton armé
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 2.
C'est d'ailleurs faisable depuis avant l'existence de processeurs physiques x86-64, tout comme l'USB 3.0. :-)
# flash 64
Posté par fredix . Évalué à 6.
Pour flash il suffit d'utiliser ce binaire qui fonctionne très bien :
Download plug-in for Linux 64-bit (TAR.GZ 6.7 MB)
http://labs.adobe.com/downloads/flashplayer11.html
le .so est à copier dans ~/.mozilla/plugins
[^] # Re: flash 64
Posté par gnumdk (site web personnel) . Évalué à 4.
Mwai, ici il me freeze la mach
# ~ +30% de perf en encodage
Posté par goom . Évalué à 10.
Il y a quelques temps j'avais comparé le temps d'encodage d'un CD extrait en wav en ogg. Passer d'un noyau 32 bits à 64 bits me faisait gagner environ 30% de temps d'encodage.
Je n'ai pas réitéré dernièrement des tests notamment pour du dématriçage d'image au format raw en format jpg, j'ai supposé que les gains de temps étant dans les mêmes eaux que ce que j'avais constaté avec l'encodage.
Au final j'utilise Mageia en 64 bits parce que mon processeur est 64 bits et que je suppose que ça apporte quelques plus de l'utiliser ainsi plutôt qu'en 32 bits.
# L'intérêt de ce type de question sur un journal ?
Posté par Refuznik . Évalué à 5.
Tu sais il y a des forums pour répondre à ce type de question.
Nonobstant je vois deux choses contradictoires.
Un tu n'as même pas cherché que l'on pouvait lancer des applications 32 bits dans un environnement 64 bits.
Deux tu cherches une justification a rester sur tes propres impressions/arguments sans même chercher à comprendre comment fonctionne un OS.
Bref ton proc est il 32 ou 64 bits ?
Si il est en 32 tu restes en 32, si il 64 tu l'as mets en 64.
[^] # Re: L'intérêt de ce type de question sur un journal ?
Posté par ploum (site web personnel, Mastodon) . Évalué à 5.
"Un tu n'as même pas cherché que l'on pouvait lancer des applications 32 bits dans un environnement 64 bits."
Si, et je l'ai déjà fait. Mais c'est lourd, chiant, demande du bricolage et ne s'intègre pas avec les mises à jours de ta distrib. De plus, ça casse souvent quand tu mets des librairies système à jour. Quand tu as un repository 32 bits (et pas de 64 bits) et que tu veux bosser, utiliser 32 bits est vachement plus simple.
"Bref ton proc est il 32 ou 64 bits ?
Si il est en 32 tu restes en 32, si il 64 tu l'as mets en 64."
Mon proc est en 64 bits. Ma distrib 32 bits. Et je n'ai pas vu le moindre argument en faveur d'installer une distrib 64 bits étant donné que je ne fait pas de l'encodage ni du calcul intensif.
"Deux tu cherches une justification a rester sur tes propres impressions/arguments sans même chercher à comprendre comment fonctionne un OS."
Tu as cherché à poster vite fait sans même prendre le temps de comprendre ma question. ;-)
Mes livres CC By-SA : https://ploum.net/livres.html
[^] # Re: L'intérêt de ce type de question sur un journal ?
Posté par patrick_g (site web personnel) . Évalué à 2.
Et l'argument de la sécurité ?
[^] # Re: L'intérêt de ce type de question sur un journal ?
Posté par ploum (site web personnel, Mastodon) . Évalué à 1.
oui, c'est vrai. D'ailleurs, je suis en 64 bit sur mon serveur. Sur mon laptop, j'estime ça moins crucial.
Mes livres CC By-SA : https://ploum.net/livres.html
[^] # Re: L'intérêt de ce type de question sur un journal ?
Posté par Refuznik . Évalué à 6. Dernière modification le 29 septembre 2011 à 15:31.
???
Déjà il n'y a pas de liens entre les mises à jours de tes appli. 64 bits et 32 bits donc en aucun cas ça ne peut casser quelque chose entre elles. Sur debian, centos, redhat ou fedora (arch est hors course puisque en rolling) j'ai rarement vu une mise à jour casser quelque chose à part bien sur lorsque l'on change de version de distribution. Ou alors j'ai vu aussi un comportement assez idiot qui est d'utiliser ndiswrapper quant le paquet en 64 bits est dispos.
Bref à part si tu compiles toi-même tes versions 32 ou 64 bits ou récupère une application non dispos dans les dépots ; une mise à jour peut poser problème mais c'est aussi à toi de regarder les mises à jour que tu fais et ne pas faire dans le syndrome press button.
Pour résumer :
si ça casse quelque chose dasn une utilisation normale ça veut dire que le paquet à été mal fait (qu'il n'a pas à être dans les dépots) et tu as tout à fait le droit de le reporter sur le bugzilla de ta distribution. Ceci est aussi valable sur les distribution only 32 que 64 bits. Dernièrement j'ai encore le cas du paquet libmtp qui met en l'air la reconnaissance des sondes spyder mais c'est aussi valable si tu avais une version seulement 32 bits.
Si ça casse quelque chose parce que l'utilisateur s'amuse à faire n'importe quoi (interface, chaise, clavier) pas besoin de reporter sur un système qui fonctionne correctement jusqu'à preuve du contraire.
ps ==> on ne dit pas librairies
[^] # Re: L'intérêt de ce type de question sur un journal ?
Posté par Ludo . Évalué à 6.
Si tu as une distrib qui fait bien les choses pour 64 bits comme Arch Linux, tu as les librairies 32bits sous forme de package, donc pas de soucis. Ça fait bien 2 ans que je suis en 64bits, jamais eu un soucis pour lancer un programme en 32bits.
[^] # Re: L'intérêt de ce type de question sur un journal ?
Posté par Frédéric COIFFIER . Évalué à 1.
Et idem pour Gentoo (aucun souci depuis près d'1 an et je me suis même demandé pourquoi les gens étaient si frileux à passer en 64-bits).
[^] # Re: L'intérêt de ce type de question sur un journal ?
Posté par Antoine . Évalué à 2.
Ben si, ça marche. En tout cas avec Mageia.
# Un désavantage du 64bits, même si ce n'est pas sa faute
Posté par BeberKing (site web personnel) . Évalué à 2.
Effectivement tout marche bien en 64bits depuis quelques années/mois. On y gagne un peu pour quelques gros calculs à mon avis même si je ne vois pas la différence au quotidien.
J'ai quand même un problème notable avec le 64 bits : ndiswrapper a besoin d'un pilote windows 64bits (forcément) fonctionnel, ce qui est souvent très difficile à trouver, et la compatibilité avec ndiswrapper est plus rare. Conclusion pour certaines cartes wifi foireuses, le passage en 64 bits peut poser problème, voire carrément rendre indisponible le pilote wifi.
# saitmieux
Posté par Patrick Lamaizière (site web personnel) . Évalué à 7.
64 bits c'est mieux pour ZFS.
(je suis déjà dehors).
les pixels au peuple !
[^] # Re: saitmieux
Posté par briaeros007 . Évalué à 2.
pourquoi tu sors ?
(ce commentaire est totalement inutile ^^)
# Consommation de batterie
Posté par TuxGasy (site web personnel) . Évalué à -3.
J'ai récemment installé LMDE en 64bits, j'ai effectivement remarqué que ma batterie se décharge plus vite par rapport à avant (à savoir Debian Squeeze en 32bits).
[^] # Re: Consommation de batterie
Posté par BeberKing (site web personnel) . Évalué à 2.
Tu es sûr que ce n'est pas du aux problèmes récents de consommation du noyau ?
[^] # Re: Consommation de batterie
Posté par TuxGasy (site web personnel) . Évalué à -2.
Pas au courant du problème! Une source?!
LMDE est à base de Squeeze, donc, ça ne doit pas être dû au noyau, non?
[^] # Re: Consommation de batterie
Posté par windu.2b . Évalué à 2.
On en a parlé ici-même
Mais LMDE, tout comme Squeeze, a forcément un noyau ! Donc il se peut que le noyau inclus dans Squeeze et/ou dans LMDE soit un de ceux concernés par le bug...
[^] # Re: Consommation de batterie
Posté par Enoch (site web personnel) . Évalué à 3.
Euh il me semble que LMDE est basé sur Debian Testing ... donc c'est pas la même version de noyau ni les même versions d'appli que sur ta squeeze (sans compter la "surcouche" de Linux Mint).
Du coup je suis pas sur que la différence d'autonomie que tu as remarqué ai un quelconque rapport avec le 64 bits.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 3.
Ce commentaire a été supprimé par l’équipe de modération.
# Sur les distributions compilées....
Posté par georgeswwbush . Évalué à 0.
Je rejoins le commentaire plus haut, les distributions / OS qui se recompilent (Gentoo, BSD, etc...) bénéficient des améliorations des compilateurs en 64 bits.
Certes, l'utilisation mémoire est plus importante, mais on peut gagner quelques cycles d'horloges pour certaines opérations, qui lorsque très sollicitées, peuvent apporter un plus.
Corrélation avec une DB Oracle:
- nombre d'IOs total: 100 000 / heure
- j'ai deux requêtes SQL:
-- une mal foutue (full scan) qui bouffe 25 000 IOs chaque exécution, mais qui est pas souvent exécutée -> une fois par heure,
-- une bien foutue, qui bouffe seulement 5 IOs par exécution, mais est souvent exécutées -> 4 fois par secondes (total cumulé par heure=environ 75 000 IOs)
Moralité: si j'arrive à ne diminuer que de 1 ou 2 blocs la petite requête, je gagnerais beaucoup plus que si j'optimise la grosse requête.
Et avec le 64 bits, par exemple avec un serveur web qui sert des milliers de petites requêtes, le gain peut être significatif.
Enfin, pour le end-user, rappelons qu'un système n'est qu'un petit nombre de petites fonctions appelées très souvent....
Moralité: de nos jours, la plupart des puces travaillent bien en 64 bits, et les compilateurs savent optimiser de mieux en mieux cette architecture, d'où l’intérêt d'un OS qui se recompile sur sa cible, ou dont les paquets binaires ont été optimisés.
Si la puce Itanium avait pu émerger, nous aurions du vrai 64 bits sur nos laptops, et on serait dans un monde meilleur.
[^] # Re: Sur les distributions compilées....
Posté par lasher . Évalué à 6.
En attendant, les machines à base d'Itanium 2 ont un double emploi : calcul haute-performance bien sûr, mais aussi table-basse chauffante (quand tu as la version "mini-armoire" et pas un rack).
[^] # Re: Sur les distributions compilées....
Posté par pasScott pasForstall . Évalué à -3.
Plus que ça encore, avec un serveur d'appli qui traite un minimum de volume de données, le faire tourner sur 4 a 8 Go est souvent un minimum syndicale, et la, en dehors du 64 bits, point de salut.
Apres, ça reste un cas particulier quand meme.
If you can find a host for me that has a friendly parrot, I will be very very glad. If you can find someone who has a friendly parrot I can visit with, that will be nice too.
# La killer feature
Posté par small_duck (site web personnel) . Évalué à 1.
En 64 bits, les entiers natifs OCaml passent sur 63 bits, ce qui permet de résoudre bien plus de problèmes de Project Euler sans avoir à passer en Int64 ou en BigInt, dont les syntaxes sont moches et les performances pas terribles.
[^] # Re: La killer feature
Posté par BFG . Évalué à 10.
Quelle avancée prodigieuse ! Il est possible d'utiliser 63 bits sur les 64 pour les nombres !
Quand on utilise un langage où
1. + 1.ne compile pas car il faut écrire1. +. 1.(et qu'évidemment1 +. 1ne fonctionne pas non plus), il est vraiment curieux que l'on se permette de faire des remarques sur la beauté d'une quelconque syntaxe.[^] # Re: La killer feature
Posté par small_duck (site web personnel) . Évalué à 3.
Maintenant, il est vrai que +. pour les flottants, ce n'est pas bien pratique, et c'est un gros défaut du langage, d'autant plus dommage que Haskell résout le problème fort élégamment avec les type classes. Mais ça serait dommage de jeter bébé avec l'eau du bain: une fois que l'on a compris où vont les point virgules, OCaml est un langage avec lequel il est très agréable de programmer.
# Qui peut le plus ?
Posté par Enzo Bricolo 🛠⚙🛠 . Évalué à -5.
64 en force.
Après 3 ans d'OS 64 bits (Vista puis Seven) sur le portable professionnel (Lenovo T410), le changement de boulot et le retour à XP 32 bits (Lenovo L512), ça pique.
[^] # Re: Qui peut le plus ?
Posté par gUI (Mastodon) . Évalué à 10.
Oui moi aussi j'ai connu ça. Je suis passé d'une 306HDi (rouge) à une Laguna V6 (grise). Et bien je confirme :
- une Renault ça avance bcp plus vite qu'une Peugeot
- un moteur atmosphérique est bcp plus puissant qu'un moteur turbo
- une voiture grise est plus confortable qu'une voiture rouge
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: Qui peut le plus ?
Posté par windu.2b . Évalué à 9.
Vous avez tout à fait raison Thérèse parce que le gris et bordeaux ça va avec tout alors, vous ne risquez pas de vous tromper.
[^] # Re: Qui peut le plus ?
Posté par Jokernathan . Évalué à 3.
Il me fallait justement quelque chose pour descendre les poubelles :-D
# On peut vraiment??
Posté par Maclag . Évalué à 4.
Mettre 4Go de RAM dans un N800 à la boulangerie du coin?
---------------> [ ]
# Avantages et inconvénients
Posté par Christie Poutrelle (site web personnel) . Évalué à -5.
Pour madame Michu, la question c'est plutôt "Quels avantages à rester en 32 bits". Je pense honnêtement aujourd'hui que la réponse est aucun: tu installes n'importe quelle distribution digne de ce nom en 64 bits et les potentiels problèmes de Mr. Tout Le Monde sont résolus par cette dernière (le Flash qui ne marche qu'en 32 bits par exemple est utilisé avec nspluginwrapper de manière transparente).
Pour un serveur, ou un utilisateur avancé, il faut savoir plusieurs choses: le 64 bits a priori est censé être plus performant pour tout ce qui est gros traitement de données (registres 48 bits je crois au lieu de 32) je suis pas trop sûr des détails, mais normalement c'est plus rapide.
Par contre, désavantage: la taille des pointeurs est plus élevée, donc tu consommes plus de mémoire.
Pour les administrateurs système, il faut savoir que des logiciels (comme le serveur de base de données clé-valeur Redis, par exemple) va stoquer tous ses entiers en 64 bits si l'OS est en 64bits, et en 32 bits sinon. Conclusion: il va utiliser beaucoup plus de mémoire pour le stockage de ces données (et un système de stockage clé valeur va potentiellement être utilisé pour stoquer des compteurs en masse, choses du genre).
Donc personnellement, j'ai pas de réponse universelle; Par contre, pour Mme Michu, la vraie question c'est "Pourquoi pas?".
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.