Il y as peu, relançant les Install Party dans le LUG local, nous avons été confronté à un problème : Notre trésorier, ayant préparé le matériel, et partant du principe que «Le 32 Bits ça passe partout» n'avais gravé aucune distribution en 64 Bits.
Mais si les version x86 (32 Bits) de Gnu/Linux posent moins de problèmes que leurs équivalent Microsoft (elle gérents facilement plus de 3,5 Go de mémoire Ram), elle n'incluent pas le boot sur des systéme UEFI .
Ceci nous ayant bloqué, temporairement, dans l'installation de nos machines.
Mais, à part une machine qui ne le supporterais pas (ce qui se fait rare), que justifierais l'utilisation d'une distribution 32 Bits en 2016 ?
C'est une petite réflexion que j'ai mené Ici sur mon blog personnel
# Correction
Posté par pasBill pasGates . Évalué à 4.
Un CPU 32bit peut ADDRESSER 4 milliard d'addresses (et un 64bit bien plus), le chiffre ne décrit pas la taille des 'mots' que le CPU peut traiter (genre faire des calculs avec des entiers jusqu'a 4 milliard), mais à combien d'addresses diffèrentes il peut accéder (= la taille du bus d'addresse)
[^] # Re: Correction
Posté par Fabrice Devaux . Évalué à 5.
En fait, et par coincidence, ça décrit à la fois l'espace d'adressage et la taille des GPR :)
(Parce qu'il faut pouvoir stocker les adresses dans les GPR.)
[^] # Re: Correction
Posté par lasher . Évalué à 3.
C'est pas vraiment une coïncidence. Le 386 avait deux variantes : SX et DX. Dans les deux cas le processeur avait des registres 32 bits, mais le bus du 386/SX était 16 bits (ce qui était une « bonne » chose pour ceux qui voulaient pouvoir réutiliser leur matos connecté à un 286, et qui ne comprenait que le 16 bits, ce qui permettait d'éviter de devoir récrire trop de pilotes). Le 386/DX était complètement 32 bits, y compris le bus d'adresses.
On m'a toujours dit que dire qu'un processeur était « X » bits se référait à la taille du mot pour un registre généraliste (les registres vectoriels/spécialisés ne comptent pas, vu que ben, ils sont spécialisés). Sinon, pourquoi ne pas considérer qu'un x64 récent est en fait un processeur 128 bits ou 256 bits ? Après tout, le bus qui va au cache fait bien 128 ou 256, voire 512 bits de large… :-)
[^] # Re: Correction
Posté par Anthony Jaguenaud . Évalué à 3.
C'est marrant, moi mon souvenir c'était que le DX embarquait un coprocesseur mathématique et pas le SX… Ça ne remet pas en question ton affirmation, juste qu'on ne garde pas les même souvenir.
[^] # Re: Correction
Posté par Troy McClure (site web personnel) . Évalué à 10.
En fait ça c'etait la distinction entre le 486DX et le 486SX
[^] # Re: Correction
Posté par flan (site web personnel) . Évalué à 10.
Un CPU x86 peut même utiliser sans problème 64 Go de RAM, y compris avec Windows (avec PAE). En revanche, un processus donné ne pourra pas utiliser plus de 4 Go de RAM. Bon, ok, on peut dire que c'est du bidouillage :)
Le x86-64 amène également plein d'autres avantages (dont plein de registres en plus).
[^] # Re: Correction
Posté par xcomcmdr . Évalué à -7.
Euh, SI la carte mère le veut bien autant de RAM et a la capacité physique.
Le PAE est un bricolage horrible qui ne sert à rien car il faut que le code de l'appli puisse l'exploiter, ce qui est 0,1% des applis.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Correction
Posté par ɹǝıʌıʃO . Évalué à 6.
D'une part, il y a des moyens très simples de l’exploiter, par exemple lancer plusieurs instances de memcached. D'autre part, la limite de 4 Go (en fait 3, mais peu importe) est par processus, et les programmes qui consomment beaucoup de RAM, à commencer par les serveurs d'applications, en lancent souvent plusieurs. Il est donc finalement assez facile d’exploiter une machine avec PAE, même si un processeur 64 bits est évidemment préférable.
[^] # Re: Correction
Posté par benja . Évalué à 1. Dernière modification le 29 juillet 2016 à 02:08.
Ça tombe sous le sens, mais oui effectivement.
… comme toute technologie. On peut remplacer PAE dans ta phrase par n'importe quelle autre techno, elle n'en sera pas plus fausse ou vraie. Par exemple, "SSE" ou "64bits", ou "x32", ou "OpenGL", ou "Wayland" (le dernier c'est pour troller ;-) ). Pour répondre à ta préoccupation d'esthétisme, je te dirais que quand on ouvre le capot d'une voiture, on s'aperçoit généralement que c'est assez "horrible", malheureusement cela vaut en fin de compte pour toute technologie.
[^] # Re: Correction
Posté par Maclag . Évalué à 3.
Toutes les technos ne se valent pas en termes d'élégance ni de simplicité.
Visiblement, PAE fait consensus sur son horreur, d'autres technos sont bien mieux accueillies par la communauté des développeurs, comme Wayland, par exemple (oui, je peux répondre pertinemment ET marcher dedans en même temps!).
[^] # Re: Correction
Posté par xcomcmdr . Évalué à -4.
A la différence près que personne n'utilise PAE. Donc à part faire du multiprocess, tu l'as dans l'os.
Et je vois pas l'intérêt d'évoquer le PAE en premier lieu alors que ça fait 10 ans qu'on est passé au 64 bits…
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Correction
Posté par pulkomandy (site web personnel, Mastodon) . Évalué à 7.
Je comprend pas bien…
Le PAE permet au noyau de l'OS de gérer plus de 4Go de RAM, tout en exposant à chaque application un espace de 4Go. Donc, pour les applications qui n'ont pas besoin de 4Go dans un seul process, c'est transparent et ça marche très bien (et côté noyau, franchement, on est plus à un truc moche près…).
L'espace RAM en plus peut aussi être utilisé avec un adressage 64bit par exemple pour des caches disque ou d'autres trucs dont le noyau aurait besoin.
Après, de nos jours, l'intérêt est discutable et je ne vois pas de raison de ne pas tout mettre en 64bit.
[^] # Re: Correction
Posté par xcomcmdr . Évalué à -3. Dernière modification le 29 juillet 2016 à 09:39.
… Ah, on me dit dans l'oreillette que j'associas à PAE sous Windows était en fait l'API AWE, et que Linux a toujours fait ce que tu décris.
Donc le PAE a encore moins d'intérêt que je croyais.
Si seulement c'était moche uniquement pour le noyau…
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Correction
Posté par benja . Évalué à 1.
Arf, PAE c'est ce qui permet justement de faire ton "AWE", d'ailleurs sous linux ça s'appelle mmap et y a pas besoin d'API spéciale, je ne comprends pas comment cela peut avoir moins d'intérêt.
(PS: le sens de ta première phrase ne m'est pas très clair non plus: je suppose qu'il manque un pronom démonstratif avant le "que" mais en l'ajoutant alors la deuxième partie me l'est encore moins).
[^] # Re: Correction
Posté par Ph Husson (site web personnel) . Évalué à 2.
Mmm tu mmap quoi pour faire ça?
[^] # Re: Correction
Posté par benja . Évalué à 2. Dernière modification le 29 juillet 2016 à 20:51.
Je l'ai écris pourtant: pour faire un équivalent à "AWE". Bien sûr qu'il faut aussi "munmap"per, mais fallait-il vraiment le spécifier ?
Bon comme le post grand-parent ne le dit pas, AWE est, selon le lien de ce post, un moyen pour un process de d'adresser plus de mémoire dans son address-space que la taille de celui-ci en demandant de mapper explicitement tel ou tel région de mémoire.
[^] # Re: Correction
Posté par benja . Évalué à 1.
NB: il me semble que ces mappings doivent être soutenus par des fichiers donc pas 100% un équivalent (je ne connais pas l'api AWE si ça se trouve c'est aussi soutenu par des fichiers ??). Mais bon que ce soit AWE ou un hack autour de mmap, l'intérêt d'une telle manip est vraiment discutable, ça c'est certain !
[^] # Re: Correction
Posté par Ph Husson (site web personnel) . Évalué à 2.
C'était justement ma question en fait…
Mon "quoi" demandait quel "fichier" utilisait comme backing-store.
[^] # Re: Correction
Posté par Fabrice Devaux . Évalué à 2.
Ça n'a complètement rien à voir avec PAE, mais l'idée c'est de créer un "fichier" temporaire dans /dev/shm (ou n'importe quel tmpfs), et de le mapper dans l'espace d'adressage de l'appli avec mmap. Cela permet de manipuler plus de mémoire physique que ce que l'espace virtuel permet, à condition de un-mapper à chaque fois qu'on a fini de s'en servir. En plus, les données peuvent être mises en swap par le noyau. Parfait quand l'appli veut se créer un cache de trucs qui sont pas utilisés souvent mais qui doivent être en mémoire.
En 64 bits, vu que l'espace virtuel est immense, on ne s'embête pas avec cette technique, mais en 32 bits c'est très utile.
[^] # Re: Correction
Posté par Fabrice Devaux . Évalué à 5.
Ah, au fait, il n'y a aucun rapport entre mmap et PAE. Aucun.
[^] # Re: Correction
Posté par benja . Évalué à -2.
Ca tombe bien je ne l'ai jamais dit. On a parlé d'AWE qui logiquement doit utiliser PAE. Ensuite j'ai dit qu'avec mmap on avait pas besoin d'une api style AWE si on voudrait essayer de faire quelque chose de similaire. On a juste besoin de PAE pour que ce soit performant (i.e. que le backing-store du mmap se retrouve in-fine en ram). Amha AWE est une mauvaise idée et l'émuler avec mmap est encore plus absurde. Donc venir dire que AWE est plus intéressant que PAE c'est de la débilité profonde je trouve (mais bon le commentaire de xcomcmdr était très difficile à interpréter donc c'est peut-être l'inverse qu'il voulait dire ?)
Ok ça n'est pas un match à 100% comme je l'ai dit plus haut, mais dire qu'il n'y a pas de rapport c'est manquer d'ingéniosité je trouve. On peut grosso-modo faire de l'AWE avec mmap, je sais pas comme me justifier plus. Donc désolé, il y a bien un rapport. On est juste méga hors-sujet, mais c'est pas moi qui aie commencé, na !
[^] # Re: Correction
Posté par xcomcmdr . Évalué à 2.
Pas selon la doc MS …?
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Correction
Posté par SlowBrain (site web personnel) . Évalué à 3.
Sauf que si certaines versions de Windows XP avais un équivalent du PAE, c'est une option qui n'existe plus sur les versions 32 Bits des Windows plus récents, qui restent donc cantonné à cette quantité de mémoire utilisable.
Ils savent le faire, mais il veulent pas.
[^] # Re: Correction
Posté par Guillaume Knispel . Évalué à 2.
Je crois que PAE reste activé en 32 bits, et a un interet pour d'autres features associée au changement de format de la page table, comme le bit NX. Ceci étant dit MS bride les Windows 32 bits clients à 4 GB de ram max, PAE ou pas PAE (et en pratique il se peut que moins de 4 GB soit exploitable)
[^] # Re: Correction
Posté par benja . Évalué à 3.
Heu au contraire, un mot est entendu pour être la taille préférentielle d'un entier traité de manière efficace par un cpu, pas la largeur du bus d'adresses. Et c'est cette même taille qu'indique 32 ou 64 bits dans la dénomination 32 ou 64 bits des processeurs x86* d'Intel/AMD. Comme l'indique Fabrice DEVAUX, un cpu doit aussi souvent utiliser des adresses de manière efficace, et donc elles sont généralement représentables dans (c.-à-d. de largeur inférieure ou égale à la largeur d') un mot CPU. Btw, le bus d'adresse d'un processeur x86_64 est en pratique toujours très largement inférieur au maximum théorique de 64bits que permet le jeu d'instructions, ce que tu semble dire par "(et un 64bit bien plus)" donc bref tu dis une chose et son contraire en même temps, une des deux ne peut donc pas être correcte ;-)
Ensuite on a toutes les bizarreries historiques tel que la mémoire à segmentation (bus d'adresse plus large qu'un mot d'un CPU 16 bits!), un WORD qui en fait vaut toujours 16bit sur tous les différents set d'instructions les x86 alors que la taille préférentielle en fonction du jeu d'instruction varie de 16 à 256 bits et donc s'appelle parfois un double/quatruple/octuple/hexa-uple(??) mot (merci MS/DOS et Intel je suppose), le modèle du C et les différentes ABI pour un cpu donné, etc. Mais ça c'est un autre débat.
[^] # Re: Correction
Posté par wismerhill . Évalué à 2.
Si c'est pour dire «seize fois», je dirais hexadécuple (mais je ne sais pas s'il faut le mettre en un ou deux mots).
[^] # Re: Correction
Posté par Marotte ⛧ . Évalué à 2. Dernière modification le 29 juillet 2016 à 20:42.
Un hexa-uple c’est "seize trucs", pas "seize fois".
EDIT:
Hexadécuple était bien le mot qu’il cherchait maintenant que je lis le post cela dit :)
[^] # Re: Correction
Posté par Nicolas Boulay (site web personnel) . Évalué à 4.
Le seul et unique cas ou le mot adressé n'est pas un octet, que j'ai vu, sont des anciens DSP de TI qui utilisait des mots de 16 bits à la place. Vu que "sizeof(char) = 1" par définition du langage C, et que un char utilise la plus petite unité de mémoire adressable, tu as des char 16 bits, avec "sizeof(char) = 1". Cela casse tellement de code C, qu'il y avait un mode avec le char en octet !
"La première sécurité est la liberté"
# x32
Posté par Spack . Évalué à 7.
Et pourquoi pas du x32 histoire de mélanger le meilleur des deux mondes ?
Je n'ai cependant pas entendu parlé d'une distribution se lançant dans cette direction.
[^] # Re: x32
Posté par Yth (Mastodon) . Évalué à 2.
C'est sympa comme idée.
Et dans le détail, il serait possible de compiler un logiciel en x32 et de le faire tourner sur une distrib x86_64 ?
Parce que pour l'ultra-optimisation, on pourrait avoir le meilleur de tout les mondes, avec les applis n'ayant jamais besoin de plus de 4Go, et pouvant profiter pleinement d'une optimisation d'utilisation du CPU, en x32, et les autres en x86_64.
Yth.
[^] # Re: x32
Posté par Minux13 . Évalué à 2. Dernière modification le 29 juillet 2016 à 14:10.
Oui. De la même manière que l'on peut compiler un soft x86 et le faire marcher sur une distribution x86_64.
En fait, dans Debian x32, le noyau est un x86_64 paché avec le support de x32ABI.
C'est même très intéressant pour le domaine de l'embarqué (empreinte mémoire réduite).
[^] # Re: x32
Posté par Yth (Mastodon) . Évalué à 2.
Donc sur le même principe que la compatibilité 32bits avec des bibliothèques 32bits compilées sur archi 64 bits, pour faire tourner des soft x86 sur x86_64, il faudrait un jeu de bibliothèques de compatibilité x32, et un soft x32 tournerait sur x86_64.
Bon, étant donné que mes serveurs type embarqué sont en ARM, tout de suite ça sert beaucoup moins, mais peut-être à garder en tête pour certains soft précis sur desktop/laptop.
Genre les logiciels de compression (gzip, bzip2, xz) qui n'ont pas besoin de 4Go de RAM mais font chauffer le CPU à mort, peut-être du ffmpeg aussi, et pourquoi pas un Apache en mode pre-fork, chaque processus n'ayant jamais besoin de quantité démesurée de RAM (ça doit probablement dépendre du site derrière cela-dit).
5 à 8% de gain en vitesse selon la page wikipédia, mine de rien c'est pas mal du tout !
Même X.org ne va pas monter très haut en RAM, 1Go c'est rare, faut sacrément bourriner.
Bref, c'est intéressant.
Yth.
[^] # Re: x32
Posté par Minux13 . Évalué à 3.
Debian propose une version x32ABI :
https://wiki.debian.org/X32Port
http://debian-x32.org/
Elle marchote, il y a encore du chemin à faire.
# Se tenir au courant ?
Posté par WhiteCat . Évalué à 10.
Tous les CPU de PC Desktop depuis 2004-2005 sont 64 bits. Pour les portables il a fallu peut-être attendre 1 ou 2 ans de plus, ce qui nous porte à 2006-2007 peut-être.
Certes on a rencontré pendant longtemps quelques portables ou mini-PC bas de gamme avec des Atom en 32 bits, mais bon c'est rare maintenant surtout qu'ils ne feraient même pas tourner une distribution actuelle (quand bien même en 32 bits). Je parle en connaissance de cause, je vois régulièrement tourner une CentOS 6 Desktop sur un Asus eeePC (Atom 32 bits, 1 Go de RAM), hé bien ça rame comme pas possible.
Bref, le 64 bits (x86-64) aujourd'hui c'est la norme, c'est plus performant, les grosses distributions songent depuis des mois (voire années) à l’abandonner, le 64 bits est plus fiable (car mieux testé), d'ailleurs il y a eu une polémique à la sortie de Fedora 23 car la compil 32 bits ne fonctionnait pas.
Pour finir quelques citations bien choisies de Linux Torvalds (et qui datent déjà de 2007…) source :
.
.
.
[^] # Re: Se tenir au courant ?
Posté par karchnu . Évalué à -5.
Les citations présentes ne constituent pas un argument, autre que « regardez, il y a des gens qui disent qu'il faut passer à x86-64 ». À ce compte là je peux aussi citer plein de gens qui disent que la science c'est moins crédible qu'une croyance et qu'il faut qu'on boive notre urine pour guérir de la malaria.
[^] # Re: Se tenir au courant ?
Posté par WhiteCat . Évalué à 8. Dernière modification le 29 juillet 2016 à 02:09.
Euh non, l’argument c'est plutôt « regardez, il y a un des meilleurs expert en "memory management" qui dit qu'il faut passer à x86-64, et il donne des détails techniques pour le prouver »
Quant à boire son urine pour soigner la malaria, si c'est mon médecin du coin, l'OMS, l'ANSES, la Croix Rouge et BFM TV qui le disent, certainement que j'y croirais.
[^] # Re: Se tenir au courant ?
Posté par benja . Évalué à -1. Dernière modification le 29 juillet 2016 à 02:53.
Le problème quand on ressort des phrases comme cela sans le contexte, c'est qu'on leur fait dire n'importe quoi. Reprenons.
("Quand vous atteignez 1GO de RAM, 32-bit de mémoire virtuelle n'est plus acceptable")
À aucun moment on ne parle de cpu 32bit ou 64bit et/ou du jeu d'instruction.
(Question à 5 francs: pourquoi choisit-il la valeur de 1 GO ?)
("Quiconque pense que "peu de gens ont réellement besoin de 64-bits" ne sait pas de quoi il parle")
Primo, peu ne veut pas dire aucun, Secundo, il ne dit pas que tout le monde a besoin de 64bits.
Ok PAE n'est peut-être pas très élégant. Mais dans une machine avec moins de 4GB de ram, est-ce qu'utiliser un jeu d'instruction 32 bits rend pertinent la nécessité d'utiliser PAE ? Et dans une machine avec 1GB ?
(pour la deuxième question, je peux affirmer que non, pour la première: voir la question à 5 francs…)
Et bien c'est bien dommage, car personne ne dit "il faut passer à x86-64, et il donne des détails techniques pour le prouver" (ou bien rester à 32 bits, FWIW), mais "étant donné le fonctionnement de la gestion de la mémoire sous linux et votre impératif fonctionnel d'utiliser tel quantité de mémoire de manière optimale, il n'est pas pertinent de vouloir utiliser PAE".
Pour reprendre votre analogie, c'est comme dire que "l'OMS dit que boire l'urine soigne la malaria" alors que l'OMS aurait en fait dit "Veuillez avant tout autre chose bien hydrater un malade souffrant de malaria. À défaut d'une source d'hydratation répondant à ces critère sanitaires minimum qui sont x, y et z, alors l'urine est un substitut convenable.".
Sans le contexte qui éclaire le choix d'un compromis plutôt qu'un autre, ces affirmations n'ont aucune valeur et les reproduire comme paroles sacrées en a d'autant moins. Il faut croire que je suis d'accord avec https://linuxfr.org/nodes/109592/comments/1666632 :-P
[^] # Re: Se tenir au courant ?
Posté par Fabrice Devaux . Évalué à 10.
Il y a une très bonne raison qui fait que même sur une machine x86 à partir de 1Go de mémoire physique, on peut commencer à vouloir activer PAE. En effet l'espace d'adressage virtuel d'une application est partagé entre le noyau et l'appli, traditionnellement en x86 selon un "split" 1G/3G. La quantité de mémoire utilisable sans PAE correspond à la quantité que le noyau peut adresser dans son "split", donc au maximum 1Go (et en fait un peu moins). Dès lors que tu as plus de 1Go de RAM en x86, il faut :
- soit changer le split, par exemple 2G/2G comme sous Windows (mais du coup, tu perds encore en espace d'adressage virtuel disponible pour l'appli, et 2Go c'est vraiment pas grand chose)
- soit activer PAE
- soit utiliser un CPU 64 bits pour ne plus avoir le problème
PAE est "utile" dès 1Go de RAM, et c'est bien le problème. Personne qui y a touché ne prétend sérieusement que c'est une "solution", au mieux une rustine parce qu'on ne savait pas faire mieux.
[^] # Re: Se tenir au courant ?
Posté par Kerro . Évalué à 2.
Je suis très étonné de cette explication. Mais alors vraiment trés étonné.
As-tu un lien stp ?
[^] # Re: Se tenir au courant ?
Posté par Fabrice Devaux . Évalué à 5.
Voir plus bas :
http://www.realworldtech.com/forum/?threadid=76912&curpostid=76980
[^] # Re: Se tenir au courant ?
Posté par benja . Évalué à -1.
Peut-être ou ne pas être utile dès 1GO, en fonction du besoin fonctionnel ! Par exemple complètement inutile si on besoin de peu de cache disque et le maximum de mémoire pour l'application tout en restant <3GB Cf, votre lien et mon autre post plus bas.
Une solution qui marche je ne sais pas comment on pourrait appeler cela différemment ? Ok le matos a évolué mais si mon problème est de faire du calcul symbolique (beaucoup de pointeurs) en ayant toujours besoin de moins 3GB de mémoire par process mais en voulant en lancer un nombre conséquent en parallèle sur la même machine, ben si ça se trouve i386 ou x32 sur du matos 64bit avec PAE activé sera plus performant qu'une autre solution.
[^] # Re: Se tenir au courant ?
Posté par WhiteCat . Évalué à 1.
En x32 c'est bien possible. En PAE j'en doute étant donné que le PAE rajoute une 3ème indirection mémoire que le CPU doit traiter en plus.
[^] # Re: Se tenir au courant ?
Posté par benja . Évalué à 2. Dernière modification le 30 juillet 2016 à 02:18.
Ça en fait toujours une de moins qu'en 64bits ;-) Puis bon je voulais dire un système full 32bits (donc pas un kernel 64 avec un userland 32). J'aurais du mettre i386 tout seul car je ne sais pas si ça existe déjà ou serait possible d'avoir 1) un kernel en x32 2) avec un support PAE (émulé ou non)… :p
[^] # Re: Se tenir au courant ?
Posté par WhiteCat . Évalué à 2.
C'est pas faux ;)
[^] # Re: Se tenir au courant ?
Posté par Fabrice Devaux . Évalué à 2.
Pardon—mon commentaire mélangeait HIGHMEM et PAE. Entre 1G et 4G en x86, le noyau se débrouille avec HIGHMEM et PAE n'est pas nécessaire, uniquement utile comme dit par quelqu'un en dessous pour le bit NX et quelques détails du genre.
[^] # Re: Se tenir au courant ?
Posté par benja . Évalué à 1.
Sans vouloir avoir l'air d'insister, mais quand même êtes-vous sûr de ce que vous avancez ? Selon ma compréhension, highmem permet au noyau d'utiliser la mémoire entre 1 et 4 en gérant des mapping à faire et à défaire à chaque transition noyau vers/de userland. Comme vous l'avez dit, une autre solution c'est de modifier la proportion du split, avec comme inconvénient de réduire l'espace d'adressage utilisable par les applications. Néanmoins, le noyau n'est pas obligé d'utiliser la mémoire > 1GB, donc amha il n'est ni nécessaire d'activer highmem ni de changer le split kva/uva lorsque l'on fait tourner linux/i386 sur machine qui a entre 1 et 4GB.
[^] # Re: Se tenir au courant ?
Posté par Guillaume Knispel . Évalué à 2.
Le noyeau doit pouvoir lire et écrire à des endroits arbitraires de l'espace d'adressage des processus userspace.
[^] # Re: Se tenir au courant ?
Posté par benja . Évalué à 2. Dernière modification le 30 juillet 2016 à 18:55.
Oui mais pas de façon "permanente". Il doit mapper l'adresse physique correspondante au mapping du process dans une kva. Ça il doit le faire de toute de façon. Juste qu'avec highmem il peut la mapper dans une KVA au dessus de 1GB (enfin en dessous de 4-1, bref…). Qu'est-ce qui m'échappe dans ce raisonnement ? Et d'ailleurs est-ce que dans ce cas là il faut qu'elle soit dans une kva ?
Aussi, je conçois que dans certains cas il peut sans doute éviter de devoir modifier le mapping pagetable en ayant un mapping fixe sur une partie de mémoire physique et simplement voir si l'UVA n'est pas swappée pour calculer son adresse physique et voir si elle tombe dans la partie d'office mappée, mais j'ai du mal à voir en quoi highmem facilite quoi que ce soit là dedans ?
[^] # Re: Se tenir au courant ?
Posté par Guillaume Knispel . Évalué à 2.
Je sais plus si il a une distinction avec l'highmem ou pas mais si tu passes ton temps à mapper et unmapper c'est plus lent.
[^] # Re: Se tenir au courant ?
Posté par benja . Évalué à 0.
Bon alors selon https://linux-mm.org/HighMemory
Ce qui a l'air de confirmer que CONFIG_HIGHMEM n'est pas nécessaire, et que de tout de façon pour accéder à la mémoire user qui se trouve au delà de l'adresse physique 896MB, le noyau doit d'office mapper/unmapper.
[^] # Re: Se tenir au courant ?
Posté par Guillaume Knispel . Évalué à 3.
Hm ? A priori cest justement ce que permet CONFIG_HIGHMEM, non ?
[^] # Re: Se tenir au courant ?
Posté par benja . Évalué à 1.
Effectivement, je vais retourner me cacher :p
[^] # Re: Se tenir au courant ?
Posté par groumly . Évalué à 1.
Se taper des pointers 64 bits (ou plus de 32 en tout cas) sur une archi 32 bits, c'est un peu la loose quand même.
Les cpus ont mieux à faire que de charger 2 registres/adresse mémoire/whatever à chaque fois que tu tapes un pointeur (c'est à dire tout le temps).
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: Se tenir au courant ?
Posté par pulkomandy (site web personnel, Mastodon) . Évalué à 3.
Sur x86 on a fait de l'adressage segment:offset pendant longtemps (avec donc des adresses logiques 32 bits, des adresses physiques 20 bits, puis plus tard 32 bits, et des registres d'une largeur de 16 bits). Ce n'est qu'à partir du 386 qu'une gestion un peu plus "moderne" de la mémoire a commencé à apparaître, avec des registres 32 bits et un espace mémoire également 32 bits.
Concrètement, il y a des pointeurs "near" (pointant dans le "même" segment), et des pointeurs "far" (pointant sur un segment spécifique). Avec différents modèles d'allocation de la mémoire aux applications (toute l'application dans un seul segment, un segment de code + un segment de données, plusieurs segments de chaque).
C'est pas des plus confortable, mais ça peut marcher.
[^] # Re: Se tenir au courant ?
Posté par benja . Évalué à 0.
Btw certaines archi (ppc, arm, etc. en gros celles avec un encodage de taille constante) n'ont pas de "far" pointer, enfin pas de manière immédiate. Un "goto far" sera toujours traduit par le compilo comme une séquence d'instruction afin de calculer correctement l'adresse, là ou pour d'autre archi l'assembleur pourra directement substituer une adresse constante. Il me semble aussi qu'OpenBSD utilise le mode à segmentation en x86_32 pour implémenter leur WX, idem pour le patch grsecurity. Aussi, avec la tendance PIE actuelle j'ai l'impression qu'on retombe aussi dans une sorte de mode à segmentation avec un adressage relatif à un registre dédié.
Bref, à côté du flat model amd64 il reste quand même un tas d'autres trucs bizaroïdes à gérer, la programmation c'est quand même un art bien gruiiik, qu'on soit PAE ou pas :D Bravo vous programmeurs qui contribuez de manière si généreuse !
[^] # Re: Se tenir au courant ?
Posté par WhiteCat . Évalué à 3.
Sans être un expert en zététique, il me semble qu'un argument d'autorité c'est quand on utilise une "figure" (genre Linus Torvalds) pour appuyer une opinion dans un domaine totalement différent (genre la médecine et la malaria par exemple). Je n'ai pas fais ça. Moi je cite Linus qui parle dans son domaine d'expertise.
C'était pas la mienne à la base.
[^] # Re: Se tenir au courant ?
Posté par barmic . Évalué à 4.
Non parce que tu peux t'appeler Albert Einstein et te tromper totalement quand tu parle de physique fondamentale. L'argumentation d'autorité c'est le fait d'accorder de l'importance à l'auteur plutôt qu'aux contenu des arguments avancés. Si Linus explique que le 32bits oblige le noyau à faire tel et tel actions dans le noyau qui pose problème, là il décrit un fonctionnement. Alors que quand il lâche : « le 32bits c'est pour les débiles », ça n'apporte rien (il exprime son avis).
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Se tenir au courant ?
Posté par WhiteCat . Évalué à 3.
C'est juste la conclusion de sa tirade contenant les explications techniques.
[^] # Re: Se tenir au courant ?
Posté par barmic . Évalué à 3.
Oui mais ce que toi tu as présenté c'est uniquement les conclusions. C'est ton argument qui est d'autorité. Tu aurais pu présenter les arguments à la place.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Se tenir au courant ?
Posté par WhiteCat . Évalué à 3.
Albert Einstein n'a pas créé/inventé lui-même les lois de la physique. Donc quand il en parle il peut se tromper oui, ça n'a rien d'étonnant.
Quand Linus parle de la gestion mémoire de l'architecture x86 et Linux, là ça serait étonnant qu'il se trompe dans ces propos.
[^] # Re: Se tenir au courant ?
Posté par benja . Évalué à -1.
Personne n'a dit qu'il se trompe. J'ai souligné le fait que son propos ne s'est pas limité à dire PAE ça pue: il l'a étayé (à sa façon ok mais n'empêche) et puis ensuite toi, avec ton esprit critique, tu vas évaluer les pro et les contres en fonction de ton besoin à toi.
Ta façon de reprendre ses phrases hors de leur contexte ne permet pas à ton lecteur de faire ce travail d'analyse. Je vais même ajouter qu'en lui autant cette autonomie tu traduis en quelques sortes une certaine forme de mépris pour ce même lecteur. C'est tout.
[^] # Re: Se tenir au courant ?
Posté par benja . Évalué à -1.
s/autant/ôtant/ !
[^] # Re: Se tenir au courant ?
Posté par barmic . Évalué à 4.
Linus n'est pas réputé pour sa neutralité. Il exprime souvent un point de vue (violemment et de manière très tranchée en principe).
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Se tenir au courant ?
Posté par WhiteCat . Évalué à 3.
Il l'explique ici : http://www.realworldtech.com/forum/?threadid=76912&curpostid=76980
[^] # Re: Se tenir au courant ?
Posté par benja . Évalué à -4.
Merci je savais très bien pourquoi, enfin j'apprécie ton élan pédagogique. Tu n'as pourtant pas répondu à la question de pourquoi faire, oui ou non, du PAE entre 1 et 4GB ? Je te préviens déjà (si tu ne l'aurais toujours pas compris) que je n'attends pas une réponse noir au blanc, et effectivement la réponse est indiquée dans ton lien (mais comme j'estime que la charge d'argumenter objectivement est de ton côté, je te laisse rédiger l'explication en français).
[^] # Re: Se tenir au courant ?
Posté par WhiteCat . Évalué à 5.
Je sais pas. J'ai pas l'impression que la réponse est dans mon lien, si ?
Le seul intérêt, je dirais, c'est de pouvoir utiliser le NX-bit.
[^] # Re: Se tenir au courant ?
Posté par benja . Évalué à -4.
OK donc tu envois un lien qui doit te donner des arguments et qui contient en effet les explications que je t'ai demandé, et puis tu réponds à côté de la plaque ? Tu l'as fait exprès ou tu ne lis juste pas ce que google te trouve ?
[^] # Re: Se tenir au courant ?
Posté par WhiteCat . Évalué à 4. Dernière modification le 29 juillet 2016 à 22:52.
Je réponds à côté de la plaque parce que j'ai pas du tout compris où tu voulais en venir avec tes explications sur le PAE.
Moi, avec mes extraits de citations, je voulais simplement indiquer que si un expert en memory management x86 dit que tout le monde (comprendre "Mme Michu") devrait tourner en 64 bits, alors je trouve un peu à côté de la plaque qu'un trésorier d'une asso Linux en 2016 grave encore des DVD 32 bits pour le grand public. C'est tout.
Et c'est pas pour autant que je souhaite le mort totale du 32 bits x86. J'espère que Debian le supportera longtemps encore (ça j'en suis presque sûr de toute façon), ça servira probablement toujours à quelqu'un.
[^] # Re: Se tenir au courant ?
Posté par benja . Évalué à 1.
Ok. Tu oublies juste de considérer que le objectifs de Linus et du trésorier sont différents.
Le problème du trésorier: quelle est la version de linux la plus compatible à offrir à mon publique -> satisfaction de Mme Michu.
Le problème de Linus: comment faire pour avoir un système le plus performant sur le matériel actuel -> est-ce vraiment pour Mme Michu ?
[^] # Re: Se tenir au courant ?
Posté par WhiteCat . Évalué à 3.
Et c'est bien pour ça que j'ai posté sur ce forum. Pour dire qu'à mon sens il se trompe. S'il veut veut offrir la meilleure expérience à Mme Michu, c'est certainement pas en lui installant un Linux 32 bits sur son portable Haswell 8 Go…
Et aussi le moins bugué. Or quand on essaye de faire tourner un OS sur une machine récente (avec beaucoup de RAM, genre + de 2 Go), l'AMD64 semble plus simple à gérer du point de vue de l'OS, donc moins de bug.
[^] # Re: Se tenir au courant ?
Posté par benja . Évalué à -1.
1) Est-ce que cela fonctionnera pas de manière satisfaisante ?
2) Quelle est la proportion de personnes qui vont arriver à son lug avec un portable dernier cri par rapport à un portable un peu plus agé ? Ou qui vont repartir avec le cd chez eux pour essayer de donner une seconde vie à un ordi qu'on avait depuis longtemps déclassé ?
Mwouais c'est vite dit hein, linux/i386 n'est pas réputé pour être plein de bug. Le contre-argument c'est que les bugs applicatifs en 32 bit sur votre machine dernier cri seront aussi moins pénibles: l'application va se faire killer beaucoup plus vite, sans swapper, alors que chez vous ça va se mettre à swapper jusqu'au moment où l'utilisateur va retirer la prise.
[^] # Re: Se tenir au courant ?
Posté par SlowBrain (site web personnel) . Évalué à 6.
Aujourd’hui un portable un peu plus âgé as un CPU en 64 Bits et 4/8 Go de RAM, et il est courant de voir de tels configurations dans les Install Party. Donc oui, on y voit de tout et il faut y prévoir des distributions en 32 Bits, tout comme il faut prévoir des distributions légères (certains apportant des machines vraiment vielle) mais pour moi ce n’est qu’en secours.
D’un autre côté le rôle d’un LUG est aussi de faire un peu d’accompagnement, et donc de voir s’il vaut mieux proposer un 64 ou un 32.
Ma politique est de proposer par défaut un 64 Bits, considérant que ce n’est pas simplement l’avenir, mais que c’est surtout le présent, contrairement aux systèmes 32 Bits.
[^] # Re: Se tenir au courant ?
Posté par Fabrice Devaux . Évalué à 1.
Ça n'est pas franchement mon impression…
[^] # Re: Se tenir au courant ?
Posté par benja . Évalué à 1. Dernière modification le 29 juillet 2016 à 21:07.
Çe me fait une belle jambe :p
Bref pour ceux qui essayeraient de suivre, PAE est nécessaire uniquement si l'on désire que le noyau utilise + de 1GB (de ces 4GB, cf. ma question no 2) ce qui peut-être utile soit par exemple pour du cache disque ou s'il doit réserver beaucoup d'espace pour le dma de certains périphériques. Dans les autres cas, on préfèrera que les application puisse utiliser complètement ces 3GB (ce qui explique pourquoi un autre split que 3/1 n'est pas forcément désirable (réponse à ma question no 1)) …
Merci pour l'effort de votre réponse au passage, J'avais secrètement espéré que WhiteCat eu pris plus le temps de nous expliquer le pourquoi de ses sacro-saintes vérités au lieu de nous dire "parce que c'est Mr Linus qui le dit que c'est vrai car c'est lui qui l'a fait et que c'est un Dieu",
[^] # Re: Se tenir au courant ?
Posté par Fabrice Devaux . Évalué à 3.
Non, tu n'as pas compris, et tu persistes dans l'erreur au lieu de lire les explications qui te sont présentées.
PAE est nécessaire pour que le système puisse utiliser plus de 1Go de RAM, à moins de changer le split 1G/3G. En pratique, en x86, on peut aller jusqu'à 2Go de RAM physique sans PAE, au delà il est nécessaire de l'activer car cela laisserait trop peu d'espace d'adressage virtuel aux applications.
C'est lié à une spécificité de l'implémentation du paging sous Linux, on pourrait très bien faire autrement et avoir 4G disponibles pour le noyau et pour les applis, mais ça porterait atteinte aux perfs.
Il y a une autre raison que personne n'a abordée jusqu'à présent, mais que la question du split 2G/2G amène : avoir un espace virtuel sur 32bits, c'est très petit, et ça devient rapidement limitant dans certaines applications. Ça a posé pas mal de problèmes sous Windows (qui utilise un split 2G/2G) dans les années qui ont précédé l'arrivée massive du x86-64.
[^] # Re: Se tenir au courant ?
Posté par benja . Évalué à 1.
Si par système tu entends le noyau, ok. Sinon je répète : il n'est pas toujours pertinent que le noyau aie besoin de plus de 1GB quand ta machine en a entre 1 et 4GB (p.e. un seveur de bdd, tu ne veux pas d'un double caching: cache fs + cache bdd). Donc le PAE n'est pas indispensable quand tu as entre 1 et 4GB, c'est un fait.
Tu t'emèles les pinceaux. L'espace virtuel des applications sur linux i386 est 3GB indépendamment de la quantité de ram physique, Toujours ! Sauf si tu changes le split.
Après c'est sympa de me dire que je n'ai rien compris, avoir de la délicatesse serait de pointer mes erreurs.
[^] # Re: Se tenir au courant ?
Posté par benja . Évalué à 1.
Comme je l'ai écris plus bas, tu ne peux pas avoir un split 0/1 (pour faire 4G-4G) car une partie de ton code kernel doit être mappée, sinon il se passera quoi à ton avis au sysenter ?
[^] # Re: Se tenir au courant ?
Posté par Fabrice Devaux . Évalué à 1.
https://lwn.net/Articles/39283/
[^] # Re: Se tenir au courant ?
Posté par benja . Évalué à 0.
=> 1/255. No comment.
[^] # Re: Se tenir au courant ?
Posté par Antoine . Évalué à 2.
Ah bon ? Tu expliqueras comment un CPU x86 32 bits peut efficacement proposer plus de 32 bits de mémoire virtuel…
[^] # Re: Se tenir au courant ?
Posté par benja . Évalué à 1.
Je dirais même plus, il parle uniquement de l'impossibilité pour le noyau de faire qq chose de cette mémoire >1GB (toujours à cause de ce fameux split). Il pourrait parler d'une ABI 36 bits qui tourne en mode compatibilité sur une archie 72bit avec un split 1/31 qu'il dirait identiquement la même chose. Il ne parle ni de CPU, et ni du jeu d'instruction (le sujet du journal), désolé je n'y peux rien.
Archi 32 bit (disons même i386) avec 32 bits de mémoire virtuelle ne veut pas dire KVA de 1GB. Donc votre question reformulée devient: en quoi dépasser un 1GB de KVA est hors de porté d'une archie 32bits ? Réponse simple: PAE.
Réponse compliquée et hors propos car elle ne serait jamais implémentée sous linux. Pour augmenter les KVA, soit tu changes le split, soit tu modifies le noyau pour faire avoir une partie non-mappée dans le process-user avec des modifs de la TBL supplémentaires à chaque entrée/sortie vers un process (ouille pour les perfs), soit tu fais une pagination interne au noyau avec différents sous-espaces d'adressage (un design plus proche d'un micro-noyau en quelque sortes). Mais c'est juste pas le design de linux, argumenter là-dessus serait perdre son temps, d'accord.
[^] # Re: Se tenir au courant ?
Posté par Nicolas Boulay (site web personnel) . Évalué à 5.
Dans tout votre baratin, vous oubliez un problème très chiant quand vous adressez un problème utilisant toute la RAM et qui s'approche du maximum en 32 bits. C'est la pénurie d'espace d'adressage.
En gros, linux va mapper des lib partagé un peu partout dans l'espace d'adressage virtuel. Ensuite, l'application va vouloir allouer un gros bloc de 2 Go : et bien il ne pourra pas ! Car l'espace virtuelle (virtuelle pas physique) est saturé. Le problème se pose aussi avec les applications 32 bits sous noyau 64 bits. Sous windows, il y a en plus des libs de converssion 32/64 qui fragmentent encore plus. Ce qui veut dire que des applications fonctionnent avec un windows 32 bits, mais plus avec un windows 64. Il y a même un problème temporel car plus le dernier reboot est loin, et plus de library sont chargés.
"La première sécurité est la liberté"
[^] # Re: Se tenir au courant ?
Posté par barmic . Évalué à 3.
J'ai du mal à comprendre. C'est un problème que les applications 32 bits ont quelque soit l'OS sous-jacent. Je suis en 32bits, j'essaie de gérer en mémoire plus de 2³²octets PAF !
La fragmentation pose un problème pour les performances, mais le noyau peut toujours te fournir un espace mémoire virtuel contiguë avec des pages physiques éparpillées.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Se tenir au courant ?
Posté par Nicolas Boulay (site web personnel) . Évalué à 5.
Tu n'as rien compris. Si tu es en 32 bits, avec 4 Go de ram, c'est pour les utiliser. Donc ton application va chercher à allouer des gros morceaux de mémoire contiguë en mémoire virtuelle. Or avant de faire son alloc, il y a déjà un paquet de truc présent dans l'espace mémoire virtuelle de l'application (alloc précédente, lib, code), et trouver des "gros morceaux" contiguë est difficile.
Le problème n'est pas la quantité, mais les tailles maximum des morceaux.
J'ai eu le problème avec une jvm embarqué qui alloue un gros morceau aux démarrages.
"La première sécurité est la liberté"
[^] # Re: Se tenir au courant ?
Posté par barmic . Évalué à 4.
Ok je comprends.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Se tenir au courant ?
Posté par Dinosaure (site web personnel) . Évalué à 2.
Tout s'explique.
[^] # Re: Se tenir au courant ?
Posté par Paul POULAIN (site web personnel, Mastodon) . Évalué à 3.
Je parie que c'était un troll ou du second degré. Ou les deux
[^] # Re: Se tenir au courant ?
Posté par WhiteCat . Évalué à 3.
Ça te choque ?
Donc si l'OMS, l'ANSES et ton médecin t'affirme qu'en buvant son urine on peut soigner la maria tu vas pouvoir les croire.
Par contre si BFM TV rediffuse cette même information à une grande audience, dans ce cas les affirmations de l'OMS, l'ANSES et ton médecin ne valent plus rien et sont décrédibilisées ?!
[^] # Re: Se tenir au courant ?
Posté par Dinosaure (site web personnel) . Évalué à 2.
L'argument d'autorité n'a jamais été valide - et c'est le point que je soulignais avec humour. Et il vaut mieux avoir une méfiance auprès des médias, en particulier BFMTV, dont la première ambition n'est pas de divulguer une information valide.
Après, si pour toi il te suffit qu'un tel dise une connerie pour y croire, très bien. Je préfère me renseigner de mon côté et recouper avec des institutions/médias alternatifs - cela ne veut pas dire que je considère comme factice, de facto, tout ce que peut dire l'[institution de votre choix] mais qu'il est certainement plus sain d'avoir la curiosité de comprendre réellement le propos.
Alors peut être que tu as raison (en vérité, j'y connais rien en PAE, mémoire et tout ça) mais ta manière d'argumenter ton propos n'est certainement pas la bonne - c'est du même niveau des pubs pour les produits amincissants où plusieurs personnes valident le propos en disant: "cela a changé ma vie" (et me dit pas que, c'est Linus Torvalds qui l'a dit donne plus de légitimité à ton propos, il en dit aussi des conneries ce messieurs - avec tout le respect que je lui dois).
[^] # Re: Se tenir au courant ?
Posté par benja . Évalué à -1.
Comme par hasard tu pointes vers la page des résultats qui conforte ton argumentaire. J'affirme que ça n'est pas toujours plus performant (cf. page 2 de ton lien, le bench xonotix ), et que la performance est largement due à l'utilisation des instructions de type SSE par le compilateur. Il est fort probable qu'un binaire 32 bits compilé pour utiliser ces même instructions sera aussi voire plus performant. Au même titre qu'un binaire compilé en -mcpu=avx2 sera plus performant qu'un simple binaire ubuntu 64bits…
Ha ha! Dis-moi, tu te mets au niveau rédac-sensationnel de ta source là ?
[^] # Re: Se tenir au courant ?
Posté par Kalenx . Évalué à 4.
Il faut bien entendu tenir compte de l'impact de l'utilisation des instructions SSE, mais tu vois le problème à l'envers. Pourquoi est-ce que le binaire 32 bits n'utilise (généralement) pas des instructions SSE? Parce que beaucoup des processeurs 32 bits ne supportent tout simplement pas ces instructions supplémentaires. Oui, il est possible de faire plusieurs paths différents selon l'architecture, mais en dehors de certains programmes très optimisés, ce n'est plus tellement utilisé (trop lourd à maintenir).
Au contraire, l'architecture x86-64 te garantit la présence des instructions SSE. C'est un effet de bord—autrement dit ce n'est pas directement lié au fait d'utiliser des mots de 64 bits—mais il faut néanmoins le prendre en compte.
D'ailleurs, en parlant d'effets de bord, le passage à 16 registres généraux et 16 registres Z/Y/XMM est un changement simplifiant grandement la tâche du compilateur et amenant un gain appréciable dans bien des contextes.
[^] # Re: Se tenir au courant ?
Posté par Renault (site web personnel) . Évalué à 4.
Maintenant il est possible avec GCC de définir deux fonctions identiques avec des drapeaux pour différents modèles de processeur afin qu'à l'exécution, suivant le processeur utilisé, il redirige tout seul vers la version de la fonction adaptée à ton processeur.
Cela simplifie grandement la donne, c'est récent, et nul doute que beaucoup de programmes vont en tirer bénéfice d'un tel mécanisme.
[^] # Re: Se tenir au courant ?
Posté par WhiteCat . Évalué à 6.
Hé oui j'ai voulu montrer la généralité. Regardes les benchmarks 32 vs 64 depuis 10 ans, la majorité montre des gains de performances plus ou moins significatifs en 64 bits.
Je ne vois pas pourquoi je devrais croire le contraire juste parce qu'effectivement il y a des rares contre-exemples… Dans l'article pointé, il y'a 14 graphiques. 12 d'entre eux montrent un gain en 64 bits (parfois très important). Dans les rares cas de baisses de perf, la baisse est de toute façon infime.
Oui mais on s'en fou. Quand tu télécharges une Ubuntu, Fedora ou ce que tu veux en 32 bits, t'auras des performances moindre que la même distrib' en 64 bits. Un point c'est tout. L'utilisateur final il s'en fou de savoir qu'il aurait des meilleures performances si un expert venait lui compiler sa distrib 32 bits avec du SSE2…
De plus, à mon avis, ce n'est pas tant le SSE2 qui améliore les performances, mais le doublement du nombre de registres. Et là en 32 bits tu ne peux pas les utiliser quoi qu'il en soit.
[^] # Re: Se tenir au courant ?
Posté par benja . Évalué à -2. Dernière modification le 29 juillet 2016 à 21:27.
Logique quand on fait de l'accélération d'algo de chiffrement avec des instructions spéciales. je ne crois pas que l'on puisse parler de comparer 32 vs 64. Un benchmark honnête serait par exemple de faire tourner x265 sans le code optimisé à la main… Enfin si phoronix savait comment faire des benchs ça se saurait :P
Probablement en général mais pas nécessairement cf. le jeu xonotix. Honnêtement l'utilisateur il s'en fout qu'openoffice tourne 1% plus vite, ou 10% tant bien même… Il veut juste que ça marche.
À balancer avec un doublement de la taille des pointeurs et de l'impacte sur les caches cpu. Bref ça n'est pas aussi tranché.
[^] # Re: Se tenir au courant ?
Posté par claudex . Évalué à 8.
Et de rajouter des sleep() aussi pour être sûr que 32bits soit plus rapide ?
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Se tenir au courant ?
Posté par benja . Évalué à -2.
En l'occurrence, ça m'étonnerait pas que x265 soit plus rapide en i386. Je vais t'apprendre un truc: c'est le même code assembleur qui sera utilisé en i386 ou en amd64, sur le même cpu, modulo le prologue qui change (obligé: ABI <>). C'est sympa de faire des remarques tonitruantes, enfin après il faudrait quand même essayer de se renseigner avant de raconter n'importe quoi hein…
[^] # Re: Se tenir au courant ?
Posté par Fabrice Devaux . Évalué à 1.
Oui, ça serait pas mal que tu te renseignes avant de raconter n'importe quoi.
C'est faux.
[^] # Re: Se tenir au courant ?
Posté par benja . Évalué à 2.
Non c'est vrai :D
https://bitbucket.org/multicoreware/x265/src/4be91b287e3ca9ee9c469b64a0f322243f439342/source/common/x86/?at=default
(Troisième fois, à ce niveau, ça devient une obsession ou quoi, sérieusement c'est si difficile d'essayer d'être factuel ?)
[^] # Re: Se tenir au courant ?
Posté par benja . Évalué à 1.
BTW j'espère que vous n'assumez aucune tâche pédagogique, parce que à part répéter que je me trompe, vous ne m'avez jamais offert le moyen de me corriger ou de me faire avancer dans la connaissance. Ni même avoir accusé le fait que vous vous étiez vous-même trompé, mais bon j'en demande pas tant non plus, même si ça peut arriver hein ;-)
[^] # Re: Se tenir au courant ?
Posté par Fabrice Devaux . Évalué à 7.
Dans le code que tu cites, deux macros, UNIX64 et WIN64, sont définies, et utilisées pour émettre du code qui est différent du 32 bits (et pas que en ce qui concerne l'ABI, en admettant ta supposition que la différence d'ABI "ne compte pas", ce qui est faux par ailleurs puisque ça a un impact sur les perfs). Le code est moins différent que ce qu'on pourrait croire (ce qui par ailleurs ne prouve rien à part que personne n'a pour l'instant fait l'effort, dans x265, d'écrire du code spécifique x86-64).
Et je ne parle même pas de PIC qui semble activé par x265 en x86-64 et pas en x86, ce qui va générer du code différent (sachant qu'un des avantages du x86-64 est justement qu'il permet de faire du PIC avec de meilleures perf que le x86 grâce à l'adressage RIP-relatif)… en d'autres termes, x265 désactive PIC en x86 pour pas se prendre une trop grosse claque en perf !
Mais si on retire tout ce qui gêne ton argumentation, alors oui, le code est le même. Et de la même façon, si on retire tous les avantages de x86-64, alors oui, x86 est supérieur. C'est ce qui semble être ton propos depuis le début, certainement motivé par l'intention de contredire les intervenants quel que soit leur propos, en étalant tes connaissances comme si tu étais le seul à en avoir.
x86-64 a quelques inconvénients qui à part dans certains cas très précis - auxquels tu as, semble-t-il, été confronté, de telle sorte que ça colore ton expérience et ton discours - sont largement compensés par les avantages. Je pose justement cette question en entretien d'embauche, et ça fait des "points bonus" de savoir dire que l'augmentation de la taille des pointeurs peut poser des problèmes en terme d'empreinte mémoire, mais pour l'instant on ne m'a jamais servi d'argument solide pour dire qu'il vaut mieux développer en x86. Le seul qui tiendrait la route c'est celui de maximiser la compatibilité avec les anciennes machines.
Au fait, gros malin, le jeu dont tu parles s'appelle Xonotic, pas Xonotix. Ça fait désordre pour ta crédibilité :)
Je crois qu'à ce stade, tout le monde sait à quoi s'en tenir, donc je m'arrête là.
[^] # Re: Se tenir au courant ?
Posté par benja . Évalué à -1. Dernière modification le 30 juillet 2016 à 16:48.
Je ne cherche à décrédibiliser personne et quand je le fais pour me défendre j'essaye de le faire avec des arguments objectifs. Par exemple tu admets que "Le code est moins différent que ce qu'on pourrait croire" (normal c'est le même, mmx,sse2,avx ça reste la même chose que le reste du code soit en 32bit ou en 64), mais tu écris quand même un paragraphe pour dire qu'un binaire i386 ne fonctionne pas de la même manière que amd64 : ben oui sinon on en discuterait pas /captain obvious/ !
Non, juste de démonter des pseudo-vérités. Oui amd64 est mieux plus sympa etc mais 1) pas toujours 2) la perf c'est pas l'objectif recherché.
Normal c'est pas le genre d'argument que l'on peut développer dans un entretient d'embauche. Un argument serait un proof of concept + un bench, pour une problématique donnée. Tout le reste ça n'est que du blabla.
Oui exactement, c'est à mon sens l'objectif que recherche le trésorier. Avec /peu/ d'inconvénient (voir aucun au niveau utilisation desktop) pour les machines actuelles. Maintenant c'est sûr que l'idéal serait de donner 2 cd à chacun en disant "essayer celui-là d'abord".
Bravo. Tu aurais pu mettre s/TBL/TLB, voir mieux pagetable, ou bien que chromium != que chrome. mais bon là c'est sûr je me suis encore bien ridiculisé :p
[^] # Re: Se tenir au courant ?
Posté par benja . Évalué à -1.
Il y a du code mmx. sse1-4, avx, avx2 mais il manquerait du code spécifique x86_64, vous êtes sérieux là ?
Bien sûr maintenant il y a du code différente en fonction de la plateforme qui n'est pas de l'ABI. Sérieusement ?
Normal j'appelle ça de l'ABI. Mais bon en s'en fout, x265 ne passe pas son temps à appeler des fonctions, ce qui au passage est plus lent en PIC et peut être vu comme un inconvénient sur amd64.
Encore heureux que nous n'ayons pas de relation professionnelle subordonnée !
Désolé pour ce commentaire fort peu pertinent finalement.
[^] # Re: Se tenir au courant ?
Posté par WhiteCat . Évalué à 2.
Je n'ai aucune raison rationnelle de croire cela.
Donc j’attends de voir un benchmark pour te croire sur parole.
[^] # Re: Se tenir au courant ?
Posté par benja . Évalué à 3. Dernière modification le 30 juillet 2016 à 22:52.
Tu fais bien ;-)
Sur un AMD A10 7800 16 GB ram (2.6G visible en mode 32).
Config 32 bits:
Config 64 bits:
Résultats (2 runs, le meilleur):
Bon je trouve curieux que l'on aie autant—~35%—de différence en utilisant le code asm par rapport avec le code C où il n'y a "que" ~16% d'avantage au 64bits, peut-être un problème d'alignement ?? Fin bref, je suis légèrement étonné. Ça pourrait être intéressant de voir avec un cpu d'une autre génération aussi. J'ai pas de kernel 4.6.4 PAE sous la main non plus, sait-on jamais :p
[^] # Re: Se tenir au courant ?
Posté par WhiteCat . Évalué à 3. Dernière modification le 30 juillet 2016 à 16:46.
Ça s'appelle pas un benchmark honnête, mais simplement un autre benchmark.
Phoronix est plutôt irréprochable sur la méthodologie de ses benchmarks. Personnellement je ne vois pas trop quoi y redire. Après c'est le choix des benchmarks qui semblent te poser problème, mais c'est un autre problème qui n'a rien à voir avec la méthodologie elle-même.
[^] # Re: Se tenir au courant ?
Posté par benja . Évalué à 3.
Le problème est que avec sa méthodologie on sait rarement déterminer l'origine des différences car il change plusieurs paramètres en même temps. Genre il va faire un article sur le fait que mesa a regressé en performance depuis un an, mais le bench utilise un noyau différent, un compilo différent, une version de llvm différente, une libc différente, etc. Aussi il ne suit pas les bonnes pratiques, comme désactiver les mécanismes d'économie d'énergie, ce qui lui a déjà permis de titrer "grave régression dans le noyau x.y.z" lorsque celui-ci a changé l'algo par défaut du pilote cpufreq. Ses bench filesystems sont aussi souvent dénués de sens ou avec des paramètres totalement arbitraires: qui ferait tourner une bdd sur fs2fs ou btrfs par exemple ? Aussi faire tourner un bench hyper-spécifique sur une configuration "stock" ça n'a pas beaucoup de sens non plus, on sait difficilement avoir une configuration qui fonctionne bien partout; ce n'est pas pour rien que certaines personnes sont payées pour tuner des systèmes et faire des benchmarks.
Ensuite, ce que je trouve dommage, c'est qu'il n'essaye jamais de donner une hypothéthique explication. Évidemment ça demande plus de temps d'investigation, une meilleur méthodologie et plus de connaissances. Mais je trouverais cela beaucoup plus intéressant ! C'est juste un choix éditorial de produire plus d'article d'une qualité discutable, j'imagine qu'il s'y retrouve comme ça et tant mieux pour lui, mais perso il est très rare que ce soient ses benchmarks qui soulève mon intérêt.
[^] # Re: Se tenir au courant ?
Posté par claudex . Évalué à 2.
Pour les titres je suis d'accord. Mais c'est justement un benchmark intéressant pour les utilisateurs, parce qu'ils auront ces options d'économies activées.
Brtfs est un FS que tu retrouves dans les serveurs, par exemple Suse ou oracle (ça arrivera sans doute sur d'autres). Il est intéressant de savoir quelle perte de performance tu vas avoir si ta db n'est pas critique (le cas de la plupart des db installées dans le monde), par exemple un site web peu fréquenté. Parce que ça ne vaut pas la peine d'avoir des options spécifiques pour un système si ça ne t'apporte rien.
D'après ce qu'il dit, s'il publiait moins d'articles, il aurait des problèmes d'argent, donc je ne dirais pas que c'est un choix.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Se tenir au courant ?
Posté par Nicolas Boulay (site web personnel) . Évalué à 4.
Je crois que tu as complètement oublier l'intérêt des benchs : savoir ce qui va le plus vite pour l'utilisateur, et pas seulement, pourquoi cela va plus vite.
Cela peut être intéressant de faire des microbenchmark pour mesurer l'effet d'un seul paramètre. Mais l'utilisateur s'en contre-fou : c'est la vitesse de son application qui comptent, dans les versions facilement accessibles. Par exemple, si son application n'utilise pas SSE, alors quelle le pourrait, le gain attendu sera faible. C'était le cas de beaucoup de code au lancement du x64, qui n'avait pas de routines en assembleur.
C'est aujourd'hui, plus le cas. De toute façon, le code x64 est plus rapide en général uniquement grâce au doublement du nombre de registres généraux disponible.
"La première sécurité est la liberté"
[^] # Re: Se tenir au courant ?
Posté par Marotte ⛧ . Évalué à 5.
Et au fait que tout le monde se penche sur ce code x64 alors que le code 32bit est clairement devenu une application de niche.
[^] # Re: Se tenir au courant ?
Posté par Nicolas Boulay (site web personnel) . Évalué à 5.
Maintenant oui, mais ma proposition était vrai aussi en 2005. Pour un même code C, j'avais en gros +20% de performance.
"La première sécurité est la liberté"
[^] # Re: Se tenir au courant ?
Posté par WhiteCat . Évalué à 3.
J'ai pas compris où tu voulais en venir.
[^] # Re: Se tenir au courant ?
Posté par benja . Évalué à -1.
Mettre en évidence "les grosses distributions songent sérieusement depuis quelques temps voire depuis des années à …" avec 6 liens (au passage tous issus, peu ou prou, du même site d'"information") alors qu'en réalité il n'y a que quelques individus—qui n'ont au demeurant pas de légitimité extraordinaire—qui se sont exprimés au sujet de deux distributions, je trouves ça faire du sensationnalisme, c'est du FUD quoi. Plus clair ?
Moi je parie qu'ubuntu ne va pas abandonner i386 avant 3-4 ans, Fedora je ne sais pas mais je ne pense pas que cela puisse arriver du jour au lendemain. Même si cette dernière s'est toujours plus positionnée en tant que distribution pour les développeurs que pour les utilisateur, le i386 est là et il va bien rester pendant un petit temps, m'étonnerait pas que le arm32 dégage avant. Chez Debian ça ne risque pas d'arriver avant un bon bout de temps, et certainement pas avant un éventuel départ de arm32.
[^] # Re: Se tenir au courant ?
Posté par denezpariz . Évalué à 4.
J'ai installé la dernière Lubuntu sur un netbook ACER Atom 32 bits 1 Go de RAM.
Evidemment c'est moins véloce que mon portable core i7 Skylake 8 Go de RAM et SSD mais c'est utilisable :
Donc cette machine me sert encore en mode road-warrior en brousse (camping) quand je n'ai pas trop envie de risquer d'endommager ma bécane de travail décrite ci-dessus (chute, humidité, vol, etc.) et même pour donner des cours de shell et commandes de bases (je suis formateur).
[^] # Re: Se tenir au courant ?
Posté par SlowBrain (site web personnel) . Évalué à 4. Dernière modification le 29 juillet 2016 à 18:45.
Si le CPU est en 32, la question ne se pose pas. Mais comme tu le signales toi-même, la configuration et l’usage que tu as de cette machine est aujourd’hui un cas à la marge.
J’allais presque dire que ce sont des configurations qui aujourd’hui n’existent plus … mais je sous-estimais l’industrie et la grande distribution à faire baisser les prix à tous les moyens.
Au vu des usages actuels ces configurations devrait se faire rares.
[^] # Re: Se tenir au courant ?
Posté par Nicolas Boulay (site web personnel) . Évalué à 5.
N’empêches que Intel a grave merdé d'avoir sorti de nouveau processeurs uniquement 32 bits, quand le 64 bits commençait à décoller. Cela a longuement retardé la bascule, et garder en vie windows XP bien trop longtemps.
"La première sécurité est la liberté"
[^] # Re: Se tenir au courant ?
Posté par xcomcmdr . Évalué à 4. Dernière modification le 04 août 2016 à 09:52.
Intel n'y est pour pas grand chose.
Windows XP est resté en vie principalement à cause du retard de Windows Vista (le fameux projet Blackcomb / Vienna, qui est reparti de zéro au bout de quelques années. Et beaucoup de fonctionnalités annoncées ont été abandonnés; telles que WinFS).
1990 = Windows 3
1992 = Windows 3.1
1995 = Windows 95
1996 = Windows 95 OSR 1 et OSR 2 (pour les OEM)
1997 = Windows 95 OSR 2.5 (pour les OEM)
1998 = Windows 98 PE
1999 = Windows 98 SE
2000 = Windows 2000 et Windows ME
2001 = Windows XP
Entre-temps : Pas grand chose si ce n'est des service packs pour XP. Dont la modification profonde de XP qu'est le SP2, sorti en 2004 en réponse à Blaster / I Love You et consorts. Ça provoquera aussi un changement notable dans la culture d'entreprise de MS. (Vista fut annoncé comme étant super ultra sécurisé, et il fut très chiant avec son UAC paranoïaque)
Et il y a eu aussi Windows Serveur 2003, une simple version Serveur de XP. Et aussi l’anecdotique Windows XP x64, en 2005, basé sur XP SP2.
fin 2006 (pour les entreprises) / début 2007 (pour le grand public) = Vista
2009 = Windows 7
2012 = Windows 8
2013 = Windows 8.1
2015 = Windows 10
On voit une publication d'un Windows grand public environ tous les 3 ans. Sauf entre XP et Vista, là où ça a pris 6 ans.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Se tenir au courant ?
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
Disons que sans le succès de ses petites machines 32 bits only, il y aurait eu une pression énorme pour tout passer au 64 bits. Là, il avait toujours une excuse pour dire, "on va se couper d'une partie des utilisateurs non négligeable".
"La première sécurité est la liberté"
[^] # Re: Se tenir au courant ?
Posté par xcomcmdr . Évalué à 5. Dernière modification le 04 août 2016 à 10:02.
Même de ce point de vue, Intel n'y est pour pas grand chose.
Microsoft a et a toujours eu une énorme culture de rétro-compatibilité. Pression ou pas, ils auraient pris le temps de garder la compatibilité avec les applications 32 bits.
D'ailleurs, dès Windows XP x64, Win64 était tout à fait compatible avec les applications 32 bits.
Par ailleurs, Windows a depuis les premières versions 64 bits de Windows, une version 32 bits et 64 bits d'une même version (même Windows 10).
Et la version 32 bits est compatible avec les applications Windows 16 bits (ça permet de prendre en charge énormément de vieux installeurs d'applications 32 bits).
Donc, pas de coupure. Microsoft sait très bien qu'un OS sans applications ne se vend pas.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Se tenir au courant ?
Posté par WhiteCat . Évalué à 4.
Basé sur Windows 2003 Server plutôt (noyau NT 5.2).
[^] # Re: Se tenir au courant ?
Posté par steph1978 . Évalué à 5.
Mon eeepc tourne encore très bien en Debian 8.3.
Et je suis triste de voir que certain produit ne sont plus distribué en 32bit (par exemple Docker, alors que LXC existe).
[^] # Re: Se tenir au courant ?
Posté par Narann (site web personnel) . Évalué à 1.
J'ai un portable de 2009 Vostro 1310, il est uniquement en 32 bits et fonctionne très bien (debian jessie), le seul et unique truc qui est lourd c'est le javascript des sites. Sinon aucun soucis. Je trouve bizarre de devoir jeter du matériel qui fonctionne très bien sous le prétexte seul de l'innovation. Un des trucs qui m'a beaucoup séduit dans Linux et le logiciel libre c'est que justement on peux utiliser un système digne de ce nom sans se faire mettre au visage l’ancienneté du matériel.
# pourtant j'aurais juré que...
Posté par Maclag . Évalué à 5.
32bits should be sufficient for everyone!
----> [ ]
[^] # Re: pourtant j'aurais juré que...
Posté par Ph Husson (site web personnel) . Évalué à 1.
Techniquement la citation globalement connue, c'était 640ko, donc 20 bits (enfin 16 + 4)
[^] # Re: pourtant j'aurais juré que...
Posté par xcomcmdr . Évalué à 5.
C'est une citation apocryphe
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: pourtant j'aurais juré que...
Posté par stopspam . Évalué à 4.
Merci pour cette minute culture, je ne connaissais pas ce mot ;)
[^] # Re: pourtant j'aurais juré que...
Posté par papap . Évalué à -2.
On parle d'appli qui auraient besoin de 1Go ou plus de RAM,mais dans un sens,est-ce que ce ne sont pas des appli mal faites justement ? On utilise des moteurs ou des langages de hauts niveaux qui mangent une quantité considérable de mémoire. Il est là le vrai problème. Quand je vois firefox qui bouffe 300Mo à lui tout seul,j'ai envie de dire : "flute, ce n'est pas du bon travail ça". Désolé si ça ne plait pas, ce que je dis, mais c'est la vérité : en voulant travailler vite,on fait du travail gaspilleur de RAM.
[^] # Re: pourtant j'aurais juré que...
Posté par xcomcmdr . Évalué à 6.
1.Mozilla Firefox est écrit avec des langages natifs, pas avec une techno dépendant d'une VM comme Java ou .NET
2.Un navigateur Web, aujourd'hui c'est quasiment un OS du fait de l’essor des technos Web (WebGL, HTML5, Javascript, CSS, SSL, "WebApps", …)
3.La moindre machine d'entrée de gamme a 6 Go de RAM aujourd'hui. Bon allez, mettons 4 Go.
Sur 4 Go, 300 Mo c'est 7%. Ça me semble raisonnable.
4.Et dans ces conditions de "navigateur OS", Firefox s'en sort très bien !
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: pourtant j'aurais juré que...
Posté par Moonz . Évalué à 4. Dernière modification le 29 juillet 2016 à 16:39.
Lenovo ideapad 100s : 2 GiB de RAM. Idem pour les modèles HP/Acer équivalents. Ne parlons même pas des Raspberry (1 GiB), je sais très bien quelle réponse va m’être offerte (truc de geeks, osef, parlons de madame Michu…)
[^] # Re: pourtant j'aurais juré que...
Posté par xcomcmdr . Évalué à 2. Dernière modification le 29 juillet 2016 à 18:35.
2 gb de RAM c'était le standard y'a 10 ans. Tu te fais arnaquer avec cette configuration, surtout au vu du prix de la RAM.
Et la configuration avec 6 Go d'office que j'ai vu se vendait à 240 €. Pour un PC desktop, c'est vraiment un prix très bas.
Quant à firefox avec 2 Go tu passes à 14 pour cent avec les 300 Mo d'utilisation mémoire citées. C'est pas la mort, loin de là.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: pourtant j'aurais juré que...
Posté par SlowBrain (site web personnel) . Évalué à 3.
C'est surtout que le Raspberry n’est pas sur un CPU x86 (sujet de ce journal), mais qu'il est sur de l'ARM, ce qui est assez différent au niveau du fonctionnement (sans que j’en connaisse les détails).
De plus, mis à part le RPi version 3 c’est de l’ARM 32 Bits.
Pour la config que tu donnes en exemple, c’est aberration de vendre encore ça aujourd’hui. Mais si on gratte, on peut même trouver pire (OK, c’est d’occasion)
[^] # Re: pourtant j'aurais juré que...
Posté par Sufflope (site web personnel) . Évalué à 9.
Et pour des applis qui ont besoin de manipuler énormément de données (appli multimédia, jeux…) avec la HD et la 4k, c'est la faute des écrans qui sont mal codés, ils devraient se contenter de 640x480 ?
# Compatibilité 64 bits
Posté par MTux . Évalué à 10.
Pour certains l'abandon du 32 bits a déjà commencé.
Par exemple tu ne pourra pas installer Chrome.
Et je suis totalement d'accord, 2016, soit 13 ans d'exploitation commerciale grand public du 64 bits, il serait peut-être temps d'y passer.
[^] # Re: Compatibilité 64 bits
Posté par Bernez . Évalué à 4.
Tout à fait. C'est un argument qui n'est pas donné dans le blog, mais qui pourrait finir par peser : un système 64 bits peut généralement faire tourner des applications 64 bits ET 32 bits, mais un système 32 bits ne peut faire tourner que des applications 32 bits. Quand une application n'existe qu'en 64 bits, il faut un système 64 bits.
[^] # Re: Compatibilité 64 bits
Posté par Minux13 . Évalué à -2.
Sauf dans le cas de Debian.
Dans sa version 32 bits (i386), il est possible d'installer et d'utiliser un noyau Linux x86_64.
Et du coup on peut installer (grâce au multiarch) et utiliser des programmes 64 bits.
C'est tordu mais ça marche.
[^] # Re: Compatibilité 64 bits
Posté par claudex . Évalué à 7.
Sauf que ça devient un système 64bits du coup.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Compatibilité 64 bits
Posté par benja . Évalué à -2.
Correction: tu ne pourras pas trouver une version officielle de chrome. Bien sûr qu'il restera possible d'utiliser chrome en 32bits !
[^] # Re: Compatibilité 64 bits
Posté par Narann (site web personnel) . Évalué à 1.
Et on fait quoi de notre ordinateur 32 bits qui fonctionne encore parfaitement?
[^] # Re: Compatibilité 64 bits
Posté par Sufflope (site web personnel) . Évalué à 2.
Bien vrai. C'est comme les places de parking en centre-ville, toujours trop petites pour ma calèche, pourtant mes chevaux pètent le feu.
[^] # Re: Compatibilité 64 bits
Posté par lasher . Évalué à 2.
Mon experience est qu'il y a plus de gens non-informaticiens avec du matériel recent que d'informaticiens. Du coup, toi en tant qu'infoteux ou en tout cas amateur éclairé, tu sais déjà comment installer un linux sur ta machine. Mais les gens qui font la transition vers Linux, meme si leur matos est relativement vieux, auront vraisemblablement un processeur 64 bits.
Pour répondre à ta question du coup : il "suffirait" de demander à l'utilisateur de s'amener avec une clef USB vierge, et d'avoir sur ton poste 2 ISO, l'une 32 bits, l'autre 64. Tu pourrais meme collecter des stats, pour voir combien de PC avec processeur x86 32 bits te sont passés sous les yeux.
# 2x plus de mémoire
Posté par phoenix (site web personnel) . Évalué à -1.
Sure un serveur, avec moins de 2 go de ram. Le passage de 32 à 64 bits ma faut consommer deux fois plus de mémoire. Et alors que la machine était large au niveau mémoire. J'ai même commencé à swapper.
Je pense que ça peut jouer
[^] # Re: 2x plus de mémoire
Posté par MTux . Évalué à 4. Dernière modification le 29 juillet 2016 à 12:17.
90€ (ttc) la DDR3 ECC en 8GB, ça peut valoir le coup d'investir.
# Du 64 bits dans les systèmes libres
Posté par Benoît Sibaud (site web personnel) . Évalué à 8.
Parmi les systèmes libres moins usités que les GNU/Linux et autres *BSD, on peut citer :
[^] # Re: Du 64 bits dans les systèmes libres
Posté par pulkomandy (site web personnel, Mastodon) . Évalué à 5.
Pour Haiku, c'est en train de changer dourcement. On a peu de resources et on se concentre sur la version 32 bits (et gcc2!) pour le moment car c'est la seule compatible avec BeOS. Dès qu'on aura le support des applications 32bits sur un noyau 64, on n'hésitera pas à passer plus sérieusement au 64bit.
C'est donc un cas particulier lié à un héritage historique et des contraintes de compatiblité.
(et pour MenuetOS, il vaut peut être mieux regarder du côté du fork KolibriOS qui semble un peu plus actif et impliqué dans le libre en général).
On peut aussi citer AROS et ReactOS mais j'ai la flemme d'aller voir où en est leur support du 64-bits :)
[^] # Re: Du 64 bits dans les systèmes libres
Posté par Benoît Sibaud (site web personnel) . Évalué à 5.
KolibriOS se dit 32 bits.
AROS ne parle que de ports i386-* apparamment pourtant il est aussi question de x86_64.
ReactOS existe en 64 bits.
[^] # Re: Du 64 bits dans les systèmes libres
Posté par MTux . Évalué à 2.
Pourquoi garder la compatibilité BeOS ?
Au début des années 2000 d'accord, mais en 2016 il y a déjà des gens qui vous ont dit "pfiou, s'il n'y avait pas eu la compatibilité BeOS, nous n'aurions pas migré notre entreprise sur Haiku !" ?
J'ai quand même du mal à comprendre, c'est comme si Windows était resté en 16 bits + FAT pour garder la compatibilité DOS.
# Rien à voir
Posté par xcomcmdr . Évalué à 1. Dernière modification le 29 juillet 2016 à 09:47.
Aucune différence sur ce point entre Windows et Linux : tu vas forcément réserver de la RAM pour adresser le matériel.
Sinon, tu n'as pas un ordinateur exploitable, mais une brique.
Voilà ce que ça rapport à Windows d'être honnête (car il dit "xx,xx mémoire installée (xx,xx utilisable)" : on fait croire qu'il ne sait pas gérer la mémoire…
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Rien à voir
Posté par pulkomandy (site web personnel, Mastodon) . Évalué à 2.
C'est un des problèmes réglés par le PAE. Quand il faut absolument tout faire rentrer dans des adresses 32 bits, y compris les adresses physiques, on ne peut avoir que 4Go d'espace mémoire.
Avec PAE, les adresses logiques (donc les pointeurs vus par les applications) sont toujours en 32 bits, par contre les adresses physiques sont en 64 bits. Du coup, on peut mapper toute la RAM (même s'il y a 4Go ou plus) plus les périphériques sans problème. Ensuite, chaque application dispose d'une ou plusieurs fenêtres qui permettent de voir des morceaux de cet espace (la RAM qu'elles ont allouées, les périphériques auxquels elles ont le droit d'accéder). Et du coup, toute la RAM peut être utilisée, du moment qu'elle est partagée entre plusieurs applications (ce qui est quand même souvent le cas).
# Pour les logiciels propriétaires...
Posté par Wawet76 . Évalué à 2.
Perso j'ai une Debian en 32bit uniquement pour le client du site de poker Winamax. Avec une Debian 64bit malgré tous mes efforts il y avait des trucs qui déconnaient (le son entre autre).
Bon récemment j'ai voulu installer Chrome pour tester un truc, j'ai du me faire une machine virtuelle en 64bit…
Bref comme d'hab, si tu n'utilise que du libre tout est plus simple.
[^] # Re: Pour les logiciels propriétaires...
Posté par dj_ (site web personnel) . Évalué à 2.
dans le sens contraire, le machin gratuit de CAO de chez Dassault (draftsight) est dispo sous linux uniquement en 64 bits
[^] # Re: Pour les logiciels propriétaires...
Posté par Wawet76 . Évalué à 2.
Ou tout simplement Chrome.
[^] # Re: Pour les logiciels propriétaires...
Posté par SlowBrain (site web personnel) . Évalué à 3.
Je trouve justement (mon avis perso, au doigt mouillé) que sur les systèmes de la famille des Linux, le x86_64 est le standard et que le x86 n'est proposé qu'en seconde option quand il l'est : Pour tout ce qui n'est pas libre et directement disponible dans les dépôts (ou à ce niveau tu ne fais généralement que suivre ce que la distro te propose)
[^] # Re: Pour les logiciels propriétaires...
Posté par Wawet76 . Évalué à 2.
Ici je causais d'un logiciel Windows que j'ai installé avec Wine. Sur une Debian en 64 bits ça marchait mal.
[^] # Re: Pour les logiciels propriétaires...
Posté par Cᴬᴾᵀ Samavor . Évalué à 1.
Sauf chez Mageia où des paquets sont disponibles qu'en i586 et je ne parle pas d'un obscur émulateur codé en ASM qui ne tournerai pas sur un processeur 64 bits, mais genre de tout Qt, exemple : https://madb.mageia.org/package/show/name/libqt5core5/application/0/arch/x86_64
Je sait pas comment ils se débrouillent pour la version amd64 de leurs distrib, multilib ?
[^] # Re: Pour les logiciels propriétaires...
Posté par Tibo cocoecolo (site web personnel) . Évalué à 3.
Pour la version x86_64, le paquet s’appelle différemment : lib64qt5core5.
https://madb.mageia.org/package/show/arch/x86_64/application/0/name/lib64qt5core5
[^] # Re: Pour les logiciels propriétaires...
Posté par Cᴬᴾᵀ Samavor . Évalué à 1.
Merci ça va m’être utile !
Ah ben c'est pratique ça, non seulement quand tu cherche libtruc tu ne le trouves pas, mais en plus il faut bourrer ton spec de %ifarch, comme si c'était pas déjà assez le merdier dans ces machins.
[^] # Re: Pour les logiciels propriétaires...
Posté par BAud (site web personnel) . Évalué à 2.
cela permet d'installer en parallèle les deux paquets et donc proposer le 32 bits sur une installation x86_64.
c'était soit une convention lib32/lib, soit lib/lib64 qui a été retenu :-) (soit modifier rpm un peu plus en profondeur pour le multi-arch)
[^] # Re: Pour les logiciels propriétaires...
Posté par Sufflope (site web personnel) . Évalué à 3. Dernière modification le 31 juillet 2016 à 01:18.
Sous Fedora ça fait je ne sais combien d'années et de versions que tu peux installer libtruc.i386 et libtruc.x86_64 (et si tu veux que ça juste marche t'installes juste libtruc qui prend ton archi) alors il doit être méchamment antédiluvien le rpm de Mageia.
# Correction : compatibilité
Posté par xcomcmdr . Évalué à 2.
Windows 64 bits est toujours incompatible avec les applications 16 bits. Ça n'a jamais changé depuis ses débuts.
Le sous-système 16 bits n'est livré qu'avec la version 32 bits de Windows.
De nos jours, on utilise Windows 3.11 dans DOSBox ou autre solution de virtualisation pour faire tourner des application Win16 sous Win64.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Correction : compatibilité
Posté par WhiteCat . Évalué à 4.
Il me semblait que c'était pas spécifique à Windows, mais à l'architecture AMD64 qui ne permet pas de faire tourner du code 16 bits en mode 64 bits. Non ?
[^] # Re: Correction : compatibilité
Posté par xcomcmdr . Évalué à 2.
C'est la raison derrière cet état de fait, oui.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.