(Troisième fois, à ce niveau, ça devient une obsession ou quoi, sérieusement c'est si difficile d'essayer d'être factuel ?)
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 ;-)
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 ?
it moves the GDT, IDT, TSS, LDT, vsyscall page and kernel stack up into
a high virtual memory window (trampoline) at the top 16 MB of the
4GB address space. This 16 MB window is the only area that is shared
between user-space and kernel-space pagetables.
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…
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 !
Posté par benja .
En réponse au journal x86 ou x86_64 ?.
É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
on pourrait très bien faire autrement et avoir 4G disponibles pour le noyau et pour les applis, mais ça porterait atteinte aux perfs
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 ?
PAE est nécessaire pour que le système puisse utiliser plus de 1Go de RAM
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.
au delà [de 2GO de mémoire physique] il est nécessaire de l'activer [PAE] car cela laisserait trop peu d'espace d'adressage virtuel aux applications.
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.
Ah, au fait, il n'y a aucun rapport entre mmap et PAE. Aucun.
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 ?)
mmap() creates a new mapping in the virtual address space of the call-
ing process. The starting address for the new mapping is specified in
addr.
AWE is a set of APIs that allows a process to allocate nonpaged physical memory and then dynamically map portions of this memory into the virtual address space of the process.
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 !
("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.
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.
Ah bon ? Tu expliqueras comment un CPU x86 32 bits peut efficacement proposer plus de 32 bits de mémoire virtuel…
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.
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 !
PAE est "utile" dès 1Go de RAM, et c'est bien le problème.
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.
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.
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.
Posté par benja .
En réponse au journal x86 ou x86_64 ?.
Évalué à -2.
Dernière modification le 29 juillet 2016 à 21:27.
montrent un gain en 64 bits (parfois très important).
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
en 32 bits, t'auras des performances moindre que la même distrib' en 64 bits
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.
mais le doublement du nombre de registres
À balancer avec un doublement de la taille des pointeurs et de l'impacte sur les caches cpu. Bref ça n'est pas aussi tranché.
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 ?
Posté par benja .
En réponse au journal x86 ou x86_64 ?.
É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",
Posté par benja .
En réponse au journal x86 ou x86_64 ?.
É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.
Donc le PAE a encore moins d'intérêt que je croyais.
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).
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).
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.
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.
Bref, le 64 bits (x86-64) aujourd'hui […] c'est plus performant,
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…
les grosses distributions songent depuis des mois (voire années) à l’abandonner,
Ha ha! Dis-moi, tu te mets au niveau rédac-sensationnel de ta source là ?
Posté par benja .
En réponse au journal x86 ou x86_64 ?.
É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.
when you hit 1GB of RAM, 32-bit virtual memory is no longer acceptable.
("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 ?)
anybody who still thinks that "not that many people need 64-bits" is simply not aware of what he's speaking of.
("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.
PAE was a total and utter disaster. […] Yes, Linux supported it, and probably did so better than anybody else. But "better than anybody else" still wasn't very good. […] I'm not at all surprised that Windows didn't push PAE either. It was a total braindamage.
PAE didn't ever really fix anything. It was a mistake. It was just a total failure, and the result of hw engineers not understanding software.
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…)
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.
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 benja . En réponse au journal x86 ou x86_64 ?. É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 benja . En réponse au journal x86 ou x86_64 ?. É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 . En réponse au journal x86 ou x86_64 ?. É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 benja . En réponse au journal x86 ou x86_64 ?. Évalué à 0.
=> 1/255. No comment.
[^] # Re: Se tenir au courant ?
Posté par benja . En réponse au journal x86 ou x86_64 ?. É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 benja . En réponse au journal x86 ou x86_64 ?. É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 benja . En réponse au journal x86 ou x86_64 ?. É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: Compatibilité 64 bits
Posté par benja . En réponse au journal x86 ou x86_64 ?. É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: Se tenir au courant ?
Posté par benja . En réponse au journal x86 ou x86_64 ?. É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 benja . En réponse au journal x86 ou x86_64 ?. É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: Correction
Posté par benja . En réponse au journal x86 ou x86_64 ?. É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: Se tenir au courant ?
Posté par benja . En réponse au journal x86 ou x86_64 ?. É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: Correction
Posté par benja . En réponse au journal x86 ou x86_64 ?. É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: Se tenir au courant ?
Posté par benja . En réponse au journal x86 ou x86_64 ?. É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 benja . En réponse au journal x86 ou x86_64 ?. É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 benja . En réponse au journal x86 ou x86_64 ?. É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 benja . En réponse au journal x86 ou x86_64 ?. É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: Correction
Posté par benja . En réponse au journal x86 ou x86_64 ?. É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: Se tenir au courant ?
Posté par benja . En réponse au journal x86 ou x86_64 ?. Évalué à -1.
s/autant/ôtant/ !
[^] # Re: Correction
Posté par benja . En réponse au journal x86 ou x86_64 ?. É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: Se tenir au courant ?
Posté par benja . En réponse au journal x86 ou x86_64 ?. É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 benja . En réponse au journal x86 ou x86_64 ?. É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 . En réponse au journal x86 ou x86_64 ?. É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 benja . En réponse au journal x86 ou x86_64 ?. É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 benja . En réponse au journal x86 ou x86_64 ?. É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