Lors de la sortie de la version 64 bits des x86 faite par AMD, il y avait eu des tas de benchmarks pour étudier les performances entre le mode 32 bits et le mode 64 bits du CPU, avec des résultats variés: gain pour certaines applications (jusqu'à 20%!!) grâce au nombre supérieur de registres visibles par le compilateur, au calcul 64 bits natif, aux appels système rapide mais perte aussi pour d'autres applications principalement a cause de la taille supérieure des pointeurs (ce qui occupe plus de bande passante mémoire et réduit l'efficacité des caches mémoire).
Notons aussi qu'à l'époque certaines applications avaient de l'assembleur codé manuellement pour le mode 32 bit mais pas pour le mode 64 bit, ce qui réduit les performances de manière "artificielle" dans un comparatif..
Pour essayer d'optimiser les performances, le nombre d'application ayant besoin de plus de 4 GO de RAM étant faible, des développeurs Linux proposent une nouvelle ABI nommée x32 permettant d'utiliser des pointeurs 32 bits tout en gardant le CPU en mode 64 bits ce qui permet de maximiser les performances des applications (nombre supérieur de registre visible, calcul 64 bits natif, appel système rapide ET pointeurs 32 bits).
Cette ABI nécessite bien sûr le support du noyau Linux et de GCC, le support GCC n'étant pas encore finalisé, on ne peut pas vraiment faire de mesure de l'amélioration des performances à l'heure actuelle.
Et une question se pose alors: quelle taille utiliser pour time_t dans cette nouvelle ABI?
Si on veut la compatibilité maximale avec les applications 32 bit actuelle, il serait logique de laisser time_t en mode 32 bit cependant Linus s'y est opposé de manière catégorique à cause du bug de l'an 2038.
L'article sur LWN rendre beaucoup plus en détail sur l'implémentation de cette nouvelle ABI sur Linux, à votre avis vas-t'il y avoir une migration vers x32 dans le futur?
Affaire à suivre!
# C'est quoi une ABI ?
Posté par blobmaster . Évalué à 5.
Si c'est ABI je comprend juste un peu.
Si c'est autre chose, je comprend rien.
[^] # Re: C'est quoi une ABI ?
Posté par reno . Évalué à 7.
Tu as raison j'aurais du clarifier, mais tu as bien trouvé ABI==Application Binary Interface.
# 0xc0000000
Posté par neologix . Évalué à 6.
En fait, l'espace d'adressage pour un processus est limité à 3Go sur 32-bit.
A partir de PAGE_OFFSET (0xc0000000), c'est mappé par le noyau (en fait à cause des différentes zones tas/mmap/stack ça peut être moins, par exemple le tas était longtemps limité à environ 1Go). Et ça peut filer vite, par exemple dans un programme multi-thread (taille réservée pour la stack de chaque thread), ou en Java :-)
[^] # Re: 0xc0000000
Posté par reno . Évalué à 5.
En mode x86 normal oui, dans les commentaires de l'article sur LWN il est marqué qu'il y a 4 Go avec x32, j'ignore si c'est correcte mais ça me parait possible: le noyau est en mode 64-bit lui..
[^] # Re: 0xc0000000
Posté par Damien Thébault . Évalué à 2.
Oui je pense que c'est ça, le kernel a déjà de la place pour lui dans l'espace 64-bits, donc les applications peuvent utiliser la totalité des 32-bits des adresses pour elles toutes seules.
[^] # Re: 0xc0000000
Posté par Laurent Go . Évalué à 3.
Pas tout à fait vrai: avec les extensions PAE (et le noyau adéquat), il est possible d'avoir des processus qui utilisent plus de 3Go, même sur des plateformes x86 comme mentionné sur la page wikipedia
[^] # Re: 0xc0000000
Posté par galactikboulay . Évalué à 3.
Non, PAE permet d'utiliser des adresses physiques sur 36 bits. Les adresses virtuelles sont toujours limitées à 32 bits, ce qui fait que l'espace adressable maximum pour un processus ne dépasse pas les 4 Go, PAE ou pas PAE.
[^] # Re: 0xc0000000
Posté par YBoy360 (site web personnel) . Évalué à -3.
relis son poste. Tu peux adresser plus de 3 (pas 4) Go en 32-bit avec un noyau PAE.
[^] # Re: 0xc0000000
Posté par galactikboulay . Évalué à 6.
C'est toi qui ne comprend pas. L'espace d'adressage virtuel d'un processus n'a rien à voir avec l'utilisation ou non du PAE. La page Wikipedia parle de mémoire physique, en aucun cas de mémoire virtuelle. Avec un noyau en PAE, on a beau pouvoir adresser jusqu'à 64 Go (36-bits) au niveau physique, ça ne change strictement rien pour les processus.
[^] # Re: 0xc0000000
Posté par neologix . Évalué à 6.
Je faisais allusion au mode 32-bit "standard". Avec x32, je n'ai pas regardé en détail mais il est probablement possible de mapper jusqu'à 4Go en usermode.
Non.
PAE permet d'exploiter jusqu'à 64Go de mémoire au total, mais un processus donné ne peut pas adresser plus de 4Go (en fait 3Go):
Pour Linux, il existe un patch dit 4/4 qui permet de mapper 4Go en usermode, mais au détriment des performances (tu dois invalider le TLB et changer la table des pages à chaque changement de contexte usermode/kernel).
Mais tout ça reste un hack, la vrai solution c'est le passage à 64-bit...
[^] # Re: 0xc0000000
Posté par reno . Évalué à 2.
galactikboulay et toi interprétez mal le post de Laurent Go: il dit que la limitation a 3Go n'existe pas avec PAE ce qui est vrai, il n'a pas parlé de celle de 4Go..
[^] # Re: 0xc0000000
Posté par neologix . Évalué à 8.
Non, c'est faux.
http://www.redhat.com/archives/rhelv5-list/2008-November/msg00097.html
http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/5/html/Deployment_Guide/ch-kernel.html
C'est pour ça qu'on a inventé le split 4G/4G (RHEL appelle ça kernel-hugemem).
Tu peux faire le test...
[^] # Re: 0xc0000000
Posté par YBoy360 (site web personnel) . Évalué à 0.
tu parles du kernel-PAE lorsque d'autres parlent d'une caractéristique d'un processeur x86. Ton kernel-hugemem utilise le support PAE du processeur non?
[^] # Re: 0xc0000000
Posté par ckyl . Évalué à 4.
Non il a raison. Le patch 4/4 n'a pas besoin de PAE. La ruse c'est de garder uniquement 16MB dans l'espace d'adressage du processus pour le noyau et de flusher le TLB quand tu passes en code système. Sur un noyau classique au dessus de PAGE_OFFSET tu as tout ce qu'il faut (même mapping pour tout les processus). Du coup le patch est très couteux pour les processus qui font beaucoup d'aller retour entre code utilisateur et noyau. Après 4/4 est souvent couplé à PAE par ce qu'il est généralement utilisé sur les systèmes avec plus de 4G de RAM. Mais on pourrait très bien avoir 4G de RAM et vouloir donner cet 4G à un unique processus et donc justifié un noyau 4/4 sans PAE.
Je crois que j'avais écrit une petite doc sur le fonctionnement de tout les patchs de cette époque là (vers 2004). Faudrait que je cherche si ca intéresse quelqu'un. Autrement tout doit toujours être dispo dans les archives de kerneltrap.
[^] # Re: 0xc0000000
Posté par Laurent Go . Évalué à 0.
Arf, les joies des commentaires trop laconiques...
Donc, dans ma phrase, je mentionne deux choses (séparées par et, ce qui implique la présence des deux):
- un kernel adéquat: c'est le fameux kernel 4G/4G mentionné par neologix
- les extensions PAE: pas nécessaires en théorie, mais dans la pratique si car utiliser 4Go pour un processus n'a d'intérêt que si la machine possède plus de 4Go de mémoire et que le noyau est capable de l'utiliser.
Exemple: il y a quelques années au boulot, on ne disposait pas de machines 64bits mais uniquement 32bits avec 8Go, et aussi de grosses bases de données pour lesquelles un 1Go en plus faisait une énorme différence, donc utilisation du noyau spécial (quant à la présence des extensions PAE, celles-ci remontent au Pentium pro, une éternité presque...)
Désolé pour la confusion, la prochaine fois, je serai plus précis.
(Et je rassure tout le monde, on est très vite passé au 64bits et à des processus utilisant plus de 4Go)
# J'approuve
Posté par fearan . Évalué à 10.
On est jamais trop prudent ! Dans les années 80 on a codé sur deux chiffres (BCD) les années, et lors du passage à l'an 2000, il a fallu revoir le code; certains se contentant d'un if ( x < ??? ) then ... les ??? pouvant êtres 20, 30, 40, 50, ??? 58 ???, 60... laissant le soin au futur mainteneur de gérer le cas lorsqu'il se reproduirai.
Loin de moi l'idée de retirer du travail aux futures génération (où à moi même), mais si on peut éviter ce bug à la con, c'est bien. Surtout que le bug de l'an 2000, il est facile à expliquer; celui de 2038 est plus ardu pour un non informaticien.
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
[^] # Re: J'approuve
Posté par swilmet . Évalué à 1.
Si on utilise un nombre non-signé pour représenter le nombre de secondes depuis le 1er janvier 1970, on tiendrait jusqu'en 2106, ce qui est déjà beaucoup mieux.
Le bug de l'an 2038, c'est pcq c'est un nombre signé qui est utilisé, et donc en théorie, avec ce système, on peut dire qu'un fichier date de 1902. Ou mieux, envoyer un mail datant de 1902, ce qui serait assez rigolo (mais je n'ai pas été lire la RFC pour voir si c'était possible, et si ça tombe le mail se base sur une autre unité).
[^] # Re: J'approuve
Posté par Altor . Évalué à 9.
En parlant de date, un truc rigolo c'est excel et les dates. Je vous fais un copie-coller d'un mail envoyé à des collègues qui ne comprenaient plus rien.
[^] # Re: J'approuve
Posté par nud . Évalué à 2.
Le mail (tant SMTP que IMAP) se repose sur une représentation textuelle des dates, donc tu pourrais même théoriquement envoyer un e-mail daté de l'an 1, de l'ère préhistorique ou du cinquième millénaire sans émouvoir le protocole.
Après la question c'est plutôt de savoir comment les différents programmes en présence vont réagir à une date non représentable par un timestamp. Tout dépend de s'ils se préoccupent de la date en question et de la façon dont ils vont la représenter en interne.
[^] # Re: J'approuve
Posté par Krunch (site web personnel) . Évalué à 3.
Comment tu représentes une date avant l'an 0 dans un e-mail ?
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: J'approuve
Posté par nud . Évalué à 2.
Effectivement, pour la RFC 2822 une année doit compter 4 chiffres et être supérieure à 1900. Donc on a droit aux dates comprises entre 1970 et 9999. Mon côté marseillais a peut-être pris le dessus.
Ceci n'enlève cependant rien à l'argument, vu qu'un timestamp non signé n'est pas capable de représenter une date avant 1970, alors que le format le permet.
# ABI Gaël
Posté par Prae . Évalué à -2.
C'est moi où l'ABI de Linux change tout le temps ?
[^] # Re: ABI Gaël
Posté par ymorin . Évalué à 10.
Oui, elle change tout le temps. Mais uniquement par ajouts. Donc, pour un programme écrit à un instant
t₀, le noyau lui garantit que l'ABIsera toujours compatible àt₁>t₀, au point que même un bug présent dans cetteABIsera toujours présent. C'est la grosse problématique de l'ABIdu noyau : une fois publiée, elle sera maintenue ad-libitum.Cependant, là, il faut plutôt voir ça comme une nouvelle
ABI. C'est à dire, un nouvel ensemble desyscall, un nouveau format de passage des paramètres dans les registres, etc... C'est un (tout petit) peu comme si on inventait un nouveau processeur, et qu'il fallait définir sonABI.Hop,
Moi.
[^] # Re: ABI Gaël
Posté par phxonx . Évalué à -8.
C'est d'ailleurs pour celà que les modules compilés avec une version du noyau fonctionne parfaitement avec toutes les versions suivantes, que les fabriquant de cartes graphiques n'ont jamais besoin de te faire sous compiler des wrappers à la con pour leur pilote proprios, que les progs codés à l'époque de l'alsa 0.8 font des sons absolument parfait encore aujourd'hui et que les ni les appels systèmes de sécurité (genre SE-Linux) ni les appels pilotes génériques (genre WLan) n'ont besoin d'être intégralement réécrits tous les deux mois.
Tu as fumé quoi au juste ?
Une ABI Linux tu es content (mais alors vraiment content) quand elle tient deux mois, même les ABI d'abstractions (genre IDE, SATA,WLan, AGP etc.) elles défilent plus vites que les étoiles filantes un soir d’août.
Déjà que les API tiennent pas 6 mois pour la plupart, alors les ABI tu penses.
Alors je t'accorde le bénéfice du doute, tu as confondu API (le code reste compatible, mais il faut recompiler), avec ABI (les binaires restent compatibles). Mais ceci étant, même au niveau API c'est une véritable valse. A part les API Posix qu'on ne peut que difficilement changer (et encore certaines interprétations par le noyau Linux laissent songeur), les API Linux pur ont tendance à avoir une sacrée bougeotte (à part OSS, qui est l'API la plus stable qui soit bien qu'elle entre dans sa sixième année de deprecation)
[^] # Re: ABI Gaël
Posté par Guillaume Knispel . Évalué à 10.
Vous ne parlez pas de la même ABI.
Il n'y a pas de stabilité de l'ABI interne de Linux.
L'ABI dont on parle ici est l'ABI kernel user. Ça aurait du être évident vu le contexte.
[^] # Re: ABI Gaël
Posté par phxonx . Évalué à 2.
Tu veut dire comme l'APM, l'ACPI, Alsa, OSS, MTTR, DRM/DRI, V4L2, SELinux etc.
Il y a combien de trucs qui n'ont pas grand chose à voir avec le fonctionnement interne du kernel, mais que tu peux pas vraiment compiler si tu n'as pas les sources à jour du kernel ?
Ca l'était. Je peux comprendre qu'on me reproche d'avoir parlé des modules, même si je ne parlais que des modules qui se pluguent sur une interface générique (là aussi ca aurait du être évident); mais pour le reste...
Même fsck a du mal à suivre les évolutions VFS/Ext4 sans une recompilation régulière.
[^] # Re: ABI Gaël
Posté par BFG . Évalué à -1.
Je suis entièrement d'accord avec vous, pour utiliser OSS, il faut appeler des fonctions qui changent absolument tout le temps, comme par exemple open(2), write(2) et autres choses rarissimes.
[^] # Re: ABI Gaël
Posté par phxonx . Évalué à -1.
Cf mon post (moinsé)plus haut.
Pour info, la personne me dit que je me trompe de type d'ABI alors que mon post antérieur parlait bien des bonnes ABI.
[^] # Re: ABI Gaël
Posté par Pinaraf . Évalué à 5.
Dommage, on aurait pu croire que tu t'y connaissais…
Mais comme fsck utilise grosso modo rien du code du noyau (sauf cas spécifiques), et en particulier n'a rien à voir avec le VFS…
[^] # Re: ABI Gaël
Posté par phxonx . Évalué à -1.
Un truc super ultra rare, comme un partitionnement EFI ?
C'est clair que de bosser sur des devices virtuels sans aucune geométrie ca n'influe pas vraiment sur fsck. Et puis corriger un superblock VFS ou remapper les inodes, ca n'a rien à voir avec le boulot de fsck non plus..
[^] # Re: ABI Gaël
Posté par Pinaraf . Évalué à 1.
Hum, il dit qu'il voit pas le rapport ?
Déjà tu expliqueras ce qu'est un «superblock VFS», qu'on rigole…
Et puis comme tu l'as dit, c'est le boulot de fsck, donc le noyau s'en tamponne le coquillard avec une babouche. fsck prend le FS sans utiliser le module noyau requis, pour justement réparer et rendre à nouveau le FS utilisable…
[^] # Re: ABI Gaël
Posté par phxonx . Évalué à 0.
Tout système de fichier monté en VFS (ie tout système de fichier ou presque de nos jours) se voit attribuer un superblock VFS, qui contient entre autre le nom du device correspondant, les pointeurs inodes, la taille des blocks, les pointeurs vers les fonctions du FS, le type de fichier et les pointeurs vers les spécifiques du FS.
Il ne va pas utiliser les fonctions du FS, mais il va quand même devoir se taper une petite tranche de causette avec la couche VFS pour savoir ce quel est le FS sous-jacent. Il accède pas vraiment aux devices en raw non plus.
[^] # Re: ABI Gaël
Posté par Etienne Bagnoud (site web personnel) . Évalué à 5.
Mais fsck doit être lancé sur un système de fichier non-monté (ext2/3/4, voir
man 8 e2fsck, XFS voirman 8 xfs_repair, ...), je vois pas ce que la couche VFS vient faire là-dedans ?"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
[^] # Re: ABI Gaël
Posté par phxonx . Évalué à -4.
Sauf si du RAID soft s'en mêle. Auquel cas un certains nombres d'opérations doivent être faite en mono-utilisateur avec les systèmes montés en read-only. Notamment quand on change la taille des disques RAID ou que l'on étend une grappe à un nouveau disque.
Dans ce cas là VFS sert pas mal, notamment si il y a un superblock persistant RAID à mettre en place ou à corriger.
[^] # Re: ABI Gaël
Posté par Etienne Bagnoud (site web personnel) . Évalué à 6.
De nouveau, le RAID logiciel est dans une couche inférieure au système de fichier et le contrôle du système de fichier se fait toujours avec le système de fichier non-monté (sauf système de fichier prévu pour le contrôle à chaud (comme OCFS2, mais c'est uniquement pour empêcher les autres nœuds d'accéder au système de fichier durant le contrôle)).
Ensuite l'agrandissement c'est un cas particulier, comme la défragmentation d'ailleurs, qui va dépendre du système de fichier. Mais, normalement, les systèmes ext3/4 et XFS peuvent être redimensionné à chaud, donc interaction avec le noyau ... mais bon on parlait de fsck et lui fonctionne sans intervention du noyau.
Et le RAID logiciel de Linux, pratiquement toutes les opérations peuvent être faite à chaud en continuant à utiliser le système de fichier, monter ou démonter le système de fichier, ajouter ou supprimer un disque du RAID, voir modifier le type de RAID. Il n'est même pas nécessaire d'avoir un RAID fonctionnel pour faire un fsck ...
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
[^] # Re: ABI Gaël
Posté par phxonx . Évalué à -5.
Premièrement le système RAID est un FS (un genre de) lui-même et il utilise un certain nombre de mécanismes VFS lui même. Deuxièmement en single user il est possible de faire un check d'un système de fichier si il est monté en R/O et c'était bien pratique (jusqu'en 2008/2009) pour la récupération d'infos sur un RAID primaire boot. A ma connaissance ca existe toujours (je n'utilise quasiment plus Linux depuis 18 mois, mais ca m'étonnerai franchement que ca ait disparu)
Je rappelle ce que j'ai dit, à savoir que fsck a du mal à suivre toute les variations du noyau, principalement avec les modifs ext4 et VFS.
Déjà fsck peut fonctionner sans intervention du noyau, mais généralement il utilise quand même pas mal les interface que lui fourni le noyau.
Typiquement sur une partition RAID soft, fsck doit pouvoir faire la différence entre les cas suivant (entre autres):
Sinon il ne peut que faire des conneries, et généralement ca fini par un superblock corrompu au reboot.
Après fsck a été modifié plusieurs fois au cours des dernières années pour prendre en compte tout un tas d'évolutions, par exemple les devices sans géométrie, les variations de superblock persistant, les modifications d'ext4 (avec un grosse flopée de bugs fin 2009 début 2010 notamment sur les OS 64bits).
A aujourd'hui je n'utiliserais pas un fsck de 2009 pour checker une bête partition ext2 des familles sur un kernel 2.6.30 ou plus. En théorie ca devrait marcher, en pratique des fois il y a des surprises. Et si la partition est un poil exotique (par exemple du RAID ou du chiffrement par dessus) je déconseille vraiment.
[^] # Re: ABI Gaël
Posté par Etienne Bagnoud (site web personnel) . Évalué à 7.
Le RAID logiciel travail en terme de bloque de données, pour lui un fichier, un répertoire, les droits et autres attributs étendus n'existent pas, la swap peut être sur un RAID. VFS, Virtual File System, représente l'arborescence des fichiers et répertoires (et autres) dans le noyau, c'est simplement une couche d'abstraction où vont se greffer les différents systèmes de fichiers selon leur point de montage; ce qui permet au noyau de travailler de manière identique avec XFS et ext3 par exemple.
Le système de fichier s'occupe de gérer la structure que les données auront sur le disque (ou autre média).
Pour le contrôle en lecture seul, c'est évidemment possible de le faire et même monté en écriture, c'est juste déconseillé car fsck va modifier la structure sur le disque et la couche VFS ne sera pas au courant de ces modifications. Alors oui, quand tu fais ton contrôle au démarrage du système de fichier monté en lecture seul ça va fonctionner car ton système de fichier va être remonté en lecture-écriture un peu plus tard.
fsck se soucie du RAID autant que moi des morpions du pape. fsck contrôle que la structure, sur un média donné, d'un système de fichier, corresponde à ce qui est attendu. Après il évident qu'il faut avoir accès à la partition où se trouve le système de fichier pour lancer fsck. Mais fsck ne sait même pas que le RAID existe, que le système est chiffré ou qu'il s'agisse d'un fichier d'image de disque.
Tu contrôles le système de fichier à la main ? Bon si tu t'obstines à faire des contrôles sur des partitions montées, je comprend que tu aies des surprises, mais sinon ça fonctionne. Regarde ce que dis la page de manuel de e2fsck :
En gros elle dit que tu dois arrêter de faire des fsck sur des partitions montées.
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
[^] # Re: ABI Gaël
Posté par phxonx . Évalué à -3.
Tout à fait, c'est pour cela que j'ai dit "un certain nombre de mécanismes". Par exemple, le superblock et les blocksizes.
J'imagine que tu voulais dire "Ce qui permet au noyau de présenter les mêmes interfaces pour XFS et ext3"
Oui, alors le média il a pas de géométrie, il est monté - éventuellement en mode forcé sans les pilotes - dans une zone non standard et en plus il possède deux superblocks à la queueleuleu. Et pour finir le blocksize réel est indépendant du blocksize hardware ou du blocksize détecté dans le premier superblock.
Je te jure que ca nécessite un peu de code spécifique pour gérer ça.
Sauf si je suis sur de savoir ce que je fais. Vu le nombre de moins que je prend je dois être un rigolo, mais vu le nombre de RAID-5 cassés que j'ai récupéré sur des Linux, je dois être un rigolo avec beaucoup de chance.
[^] # Re: ABI Gaël
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 3.
Tu veux sans doute parler d'une GUID Partition Table, plutôt ? Ce n'est pas rare du tout.
[^] # Re: ABI Gaël
Posté par Guillaume Knispel . Évalué à 5.
C'est une vision partielle des choses. Certaines vielles ABI moisies sont graduellement dépréciées et supprimées de Linux ou modifiées pour quelque chose de meilleur. Les syscall restent là, et évidemment les passages de params sont gravés dans le marbre une fois pour toute au début, mais ce qu'il y a dans /proc ou /sys ou /dev (etc) fait aussi partie de l'ABI et peut doucement bouger, même si la règle est effectivement de garder de la retrocompatibilité à moyen/long terme même pour tout ça.
[^] # Re: ABI Gaël
Posté par Nicolas Boulay (site web personnel) . Évalué à 8.
On parle d'API noyau et utilisateur.
L'ABI, définit seulement la manière de gérer les appels de fonctions C : dans quel registres sont les arguments, qui sauve les registres temporraires entre l'empelant et l'appeler (callee-save vs caller-save), comment est gérer la pile, comment les types C sont traduit en registre (promotion des char en int par exemple).
Bref, rien à voir avec les appels systèmes.
"La première sécurité est la liberté"
[^] # Re: ABI Gaël
Posté par Gof (site web personnel) . Évalué à 2.
L'ABI du noyaux ce sont les appels systèmes. (c.-à.-d. l'interface entre le mode utilisateur et le mode noyaux)
La manière de gérer les appels de fonctions et l'utilisation des registres est plutôt dictée par L'ABI du langage ou du compilateur
[^] # Re: ABI Gaël
Posté par Guillaume Knispel . Évalué à 2.
ABI est un terme générique que l'on emploie dès que l'on parle d'un sujet qui a un impact sur une compatibilité binaire. Quelques soient les binaires en question. Savoir précisément de quoi on parle quand on dit "ABI" nécessite donc de prendre en compte le contexte. Pour avoir lu tout le thread d'origine, je suis à 200% certain que l'ABI dont il est question ici est l'interface kernel user, avant tout les syscalls, mais il a été aussi évoqué des adaptations dans /sys dépendant de l'architecture, donc l'ABI dont on parle est bien celle complète de la définition classiquement utilisée par les kernel hackers parlant d'interface kernel user.
# ...
Posté par M . Évalué à 2.
Pour essayer d'optimiser les performances, le nombre d'application ayant besoin de plus de 4 GO de RAM étant faible,
C'est pas tout a fait vrai pour la memoire virtuel avec le prelink (qui essaye de charger chaque bibliothèque a des adresses différentes)
# compatibilité avec le X64 ?
Posté par Nicolas Boulay (site web personnel) . Évalué à 1.
J'espère qu'ils vont pouvoir faire une compatibilité avec le X64 pour pouvoir utiliser tout de même des lib 64 bits et éviter les duplications.
"La première sécurité est la liberté"
[^] # Re: compatibilité avec le X64 ?
Posté par Buf (Mastodon) . Évalué à 4.
J'ai du mal à voir comment on pourrait garder la compatibilité avec des tailles de pointeur différentes.
[^] # Re: compatibilité avec le X64 ?
Posté par Nicolas Boulay (site web personnel) . Évalué à -1.
Il suffit de définir un moyen de passer de l'un à l'autre. Mais c'est vrai que définir 2 type de pointeur de manière implicite risque de produire des effets étranges.
"La première sécurité est la liberté"
[^] # Re: compatibilité avec le X64 ?
Posté par Buf (Mastodon) . Évalué à 1.
Outre les difficulté techniques que ça représenterait (je suis même pas sûr que ça soit faisable), ça ferait perdre tout son intérêt à ce truc.
De base, le gain de performance de ce mode bâtard 32/64 bits risque d'être au mieux marginal pour la plupart des applications (par rapport à du vrai 64 bits). Si en plus on ajoute un système de conversion de pointeurs pour appeler du code situé dans des bibliothèques 64 bits (qui ne vont donc pas profiter du gain de performance apporté par les pointeurs 32 bits), il ne restera plus aucun intérêt.
[^] # Re: compatibilité avec le X64 ?
Posté par dinomasque . Évalué à 4.
Avec une technologie magique et révolutionnaire (et brevetée) !
BeOS le faisait il y a 20 ans !
[^] # Re: compatibilité avec le X64 ?
Posté par windu.2b . Évalué à 6.
Mais par contre, il faut tout racheter !
[^] # Re: compatibilité avec le X64 ?
Posté par dinomasque . Évalué à 1.
Rholala, c'est vendredi !
Y'en a qui feraient bien d'acheter l'app Humour sur leur AppStore ...
BeOS le faisait il y a 20 ans !
# ABI 32 bits et time_t
Posté par nud . Évalué à 3.
Je peux parfaitement comprendre qu'un programme compilé sur une archi i686 puisse toujours fonctionner si on rajoute des nouveaux registres, ils seront juste pas utilisés.
Par contre, si on change la taille du type time_t, on casse l'ABI et un programme compilé pour i686 (avec un time_t de 32 bits) ne pourra pas interragir avec une lib x32 (avec un time_t de 64 bits) et inversement.
Donc, vous emballez pas les gars, x32 ne sera pas plus compatible avec x86 que x84 ne l'est, et cela ne vous permettra pas d'utiliser tout le potentiel de votre core 2 duo installé du temps où x64 était réservé aux téméraires sans le réinstaller...
Du coup l'intérêt est relativement limité. Tant qu'à réinstaller, autant réinstaller du x64 directement...
[^] # Re: ABI 32 bits et time_t
Posté par Troy McClure (site web personnel) . Évalué à 4.
Pour moi l'interet c'est de l'avoir installé en même temps x86_64 (voire aussi i686 pour la compatibilité avec les vieilles applis 32-bits). L'abi est de toute façon differente de i686, on ne peut pas faire utiliser une lib i686 à une appli x32 , mais les differents systemes peuvent coexister ensembles et ça c'est interessant puisque chaque abi a ses avantages et ses inconvenients
[^] # Re: ABI 32 bits et time_t
Posté par nud . Évalué à 2.
Oui, alors on peut déjà installer des programmes i386 avec un noyau x64. Je ne pense pas que le fait de gagner des clopinettes dans des cas très rares justifie le fait de maintenir une nouvelle infrastructure au sein du noyau et d'installer une troisième copie de tout le système.
Je peux voir l'intérêt théorique (se faire travailler les méninges sur quelque chose que personne d'autre n'a fait) mais pour qu'une infra se développe, soit maintenue et soit correctement supportée, il faut également qu'elle ait un intérêt pratique évident, ce qui aurait probablement été davantage le cas si l'infra x32 remplaçait "au vol" l'infra x86 en étant compatible avec les anciens programmes.
[^] # Re: ABI 32 bits et time_t
Posté par Gof (site web personnel) . Évalué à 3.
Les programmes sont recompilé de manière à utiliser plus de registres, un time_t de 64bit, et plein d'autre trucs de la nouvelle architecture, mais en utilisant des pointeur de 32 bit au lieu de 64 bit.
Avantage: moins d'utilisation de mémoire (et donc moins de cache-miss)
En effet, si tu as une structure du genre:
Chaque node utilise 24 octets si les pointeurs font 64 bits, mais seulement 12 octests avec des pointeurs en 32bits. S'il y a beaucoup de node, tu perds énnormément en mémoire.
[^] # Re: ABI 32 bits et time_t
Posté par Gof (site web personnel) . Évalué à 5.
Cependant, d'après mon expérience, en réalité, les pointeurs n'occupent pas tellement de mémoire comparé au reste (pixmaps, images, chaîne de caractères, autres données)
Je parle ici principalement d'applications desktop. Peut-être que d'autre type d'applications utilisent plus de pointeurs. Les benchmarks nous dirons si ça vaux le coup.
Mais j'en profite quand même pour citer Donald Knuth
[^] # Re: ABI 32 bits et time_t
Posté par galactikboulay . Évalué à 3.
C'est tout à fait vrai, cela dit on peut avoir besoin d'un espace mémoire virtuel sur 64-bits sans pour autant avoir besoin de quantités de RAM astronomiques, par exemple lorsqu'on mappe des gros fichiers en mémoire (via mmap()).
[^] # Re: ABI 32 bits et time_t
Posté par nud . Évalué à 1.
Moui, après, les spécifications du matos ont suivi le passage vers les 64 bits, et le lien du journal semble indiquer qu'il n'y a pas vraiment de gain et qu'on met une tonne d'indirections dans tous les sens.
# ABI 16 bits?
Posté par ʭ ☯ . Évalué à 5.
Et tant qu'à faire, pourquoi pas une ABI 16 bits pour économiser encore plus de mémoire sur les pointeurs?
Mieux, je propose l'ABI la plus économe du monde : 1 bit. Cherchons maintenant, amis Shadocks, l'utilité d'un pointeur qui ne peut viser que deux adresses.
⚓ À g'Auch TOUTE! http://afdgauch.online.fr
[^] # Re: ABI 16 bits?
Posté par reno . Évalué à 3.
Il n'y pas tant que ça d'applications qui ont besoin de moins de 64 Mo de mémoire..
[^] # Re: ABI 16 bits?
Posté par Nicolas Boulay (site web personnel) . Évalué à 3.
64 Ko de mémoire...
"La première sécurité est la liberté"
[^] # Re: ABI 16 bits?
Posté par ʭ ☯ . Évalué à 1.
J'ai faux si je calcule qu'on adresse 2¹⁶ zones de 2 octets soit 130ko? Mais le processeur 286 pouvait adresser 16Mo de RAM...
⚓ À g'Auch TOUTE! http://afdgauch.online.fr
[^] # Re: ABI 16 bits?
Posté par ckyl . Évalué à 4.
D'après la doc, le 286 n'a pas un bus d'adresse de 16 bits mais de 24 bits et de la segmentation.
[^] # Re: ABI 16 bits?
Posté par ʭ ☯ . Évalué à 3.
Ben tout le foisonnement de petits outils unix, non? Et puis aussi les services, etc.
⚓ À g'Auch TOUTE! http://afdgauch.online.fr
[^] # Re: ABI 16 bits?
Posté par claudex . Évalué à 2.
Pour les petits outils, ça veut dire limiter la taille de fichier qu'on leur donne, ça risque d'être souvent limité. Pour les services, il doit pas y en avoir beaucoup en dessous de 130ko.
« 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: ABI 16 bits?
Posté par zebra3 . Évalué à 3.
Remarque, les buffers overflow seront plus simples à éviter.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
# Idée trés bonne
Posté par phoenix (site web personnel) . Évalué à 2.
Personnellement je trouve l'idée très bonne.
J'ai une machine 64-bit mais j'ai ré-installé un linux 32-bit (et je perd donc l'intérêt du 64-bit) car je n'ai que 2Go de RAM et qu'en 32-bit j'ai deux fois plus de RAM libre qu'en 64 bit (ou je me retrouve avec une mémoire pleine et un PC qui swap).
Pourtant j'utilise des outils Desktop :
- KDE 4 (KMail, ...)
- Kdevelop pour le développement.
Donc si je pouvais me retrouver avec une machine 64-bit mais avec des pointeurs 32-bits, je serais super content.
Maintenant est-ce que sera une architecture supplémentaire ? une option ?
Est-ce que debian va créer un x32-64 ?
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.