Bonjour,
Lu ici (apres suivi d'un lien donné par MELMOTH sur fr.comp.os.ms-windows):
http://www.01net.com/editorial/380253/windows-seven-10-pistes-a-suivre-par-microsoft-pour-effacer-l-echec-vista/?di=2&play=0#debutDiaporama
" A titre d'exemple, Windows Vista en 32 bits ne supporte en théorie que
4 Go de RAM, légèrement plus de 3 Go dans les faits. Sa version 64 bits
peut utiliser 8 Go pour l'édition Basic, 16 Go pour la Premium à plus de
128 Go de RAM pour les éditions Intégral, Professionnel et Entreprise."
Ils veulent en venir ou avec ces limitation à la con?
Attention: Suivi là ou il faut.
PS: qui veut lancer les paris (sur Usenet) sur l'année de sortie
publique du successeur de Vista?
Sur fr.comp.os.linux.debats, Michel Talon s'est exprimé ainsi :
Pour des usages non scientifiques, le facteur majeur en faveur du 64 bits est évidemment le fait qu'on peut gérer plus de 4 Gigs de mémoire.
La fonctionnalité PAE permet de s'affranchir de cette valeur, non ? Par contre conserve-t-on la taille maximum d'un processus ?
Si je ne m'abuse, PAE permet de rajouter de l'espace d'adressage
physique, +4 ou 5 bits d'adresses, mais au sein d'un process, on est encore en 32bits, non ?
-- IT'S ALL YOUR FAULT!!!
JKB
Le 28-05-2008, à propos de Re: les versions de vista: limitations à la con, Thierry B. écrivait dans fr.comp.os.linux.debats :
--{ Stéphan Peccini a plopé ceci: }--
Sur fr.comp.os.linux.debats, Michel Talon s'est exprimé ainsi :
Pour des usages non scientifiques, le facteur majeur en faveur du 64 bits est évidemment le fait qu'on peut gérer plus de 4 Gigs de mémoire.
La fonctionnalité PAE permet de s'affranchir de cette valeur, non ? Par contre conserve-t-on la taille maximum d'un processus ?
Si je ne m'abuse, PAE permet de rajouter de l'espace d'adressage
physique, +4 ou 5 bits d'adresses, mais au sein d'un process, on est encore en 32bits, non ?
Ça, c'est parce qu'on le veut bien. J'ai des souvenirs de programmes qui utilisaient plus d'un mégaoctet de données et codés en Fortran77 sous UniFLEX. Le processeur était un 6809 avec sa MMU et le système était capable d'utiliser 2 Mo de mémoire, un truc énorme, de façon totalement transparente. Pour les djeunz, le 6809 est un 8/16 bits capable d'adresser nativement 64 Ko de mémoire.
Il n'y a _aucune_ raison de limiter la taille d'un processus à 2 Go sr une architecture 32 bits sauf à ne pas vouloir s'emmerder à coder un OS capable de faire mieux ou a utiliser une architecture assez mal foutue pour ne pas pouvoir outrepasser la limite en 32 bits. Je ne vois pas en quoi il serait impossible de faire aujourd'hui avec les composants modernes ce qu'on faisait il y a vingt-cinq ans !
JKB
-- Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre masse corporelle, mais disperse à lui seul 25% de l'énergie que nous consommons tous les jours.
Le 28-05-2008, à propos de
Re: les versions de vista: limitations à la con,
Thierry B. écrivait dans fr.comp.os.linux.debats :
--{ Stéphan Peccini a plopé ceci: }--
Sur fr.comp.os.linux.debats, Michel Talon s'est exprimé ainsi :
Pour des usages non scientifiques, le facteur majeur en faveur du 64
bits est évidemment le fait qu'on peut gérer plus de 4 Gigs de mémoire.
La fonctionnalité PAE permet de s'affranchir de cette valeur, non ? Par
contre conserve-t-on la taille maximum d'un processus ?
Si je ne m'abuse, PAE permet de rajouter de l'espace d'adressage
physique, +4 ou 5 bits d'adresses, mais au sein d'un process, on
est encore en 32bits, non ?
Ça, c'est parce qu'on le veut bien. J'ai des souvenirs de programmes
qui utilisaient plus d'un mégaoctet de données et codés en Fortran77
sous UniFLEX. Le processeur était un 6809 avec sa MMU et le système
était capable d'utiliser 2 Mo de mémoire, un truc énorme, de façon
totalement transparente. Pour les djeunz, le 6809 est un 8/16 bits
capable d'adresser nativement 64 Ko de mémoire.
Il n'y a _aucune_ raison de limiter la taille d'un processus à 2 Go
sr une architecture 32 bits sauf à ne pas vouloir s'emmerder à coder
un OS capable de faire mieux ou a utiliser une architecture assez
mal foutue pour ne pas pouvoir outrepasser la limite en 32 bits. Je
ne vois pas en quoi il serait impossible de faire aujourd'hui avec
les composants modernes ce qu'on faisait il y a vingt-cinq ans !
JKB
--
Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre
masse corporelle, mais disperse à lui seul 25% de l'énergie que nous
consommons tous les jours.
Le 28-05-2008, à propos de Re: les versions de vista: limitations à la con, Thierry B. écrivait dans fr.comp.os.linux.debats :
--{ Stéphan Peccini a plopé ceci: }--
Sur fr.comp.os.linux.debats, Michel Talon s'est exprimé ainsi :
Pour des usages non scientifiques, le facteur majeur en faveur du 64 bits est évidemment le fait qu'on peut gérer plus de 4 Gigs de mémoire.
La fonctionnalité PAE permet de s'affranchir de cette valeur, non ? Par contre conserve-t-on la taille maximum d'un processus ?
Si je ne m'abuse, PAE permet de rajouter de l'espace d'adressage
physique, +4 ou 5 bits d'adresses, mais au sein d'un process, on est encore en 32bits, non ?
Ça, c'est parce qu'on le veut bien. J'ai des souvenirs de programmes qui utilisaient plus d'un mégaoctet de données et codés en Fortran77 sous UniFLEX. Le processeur était un 6809 avec sa MMU et le système était capable d'utiliser 2 Mo de mémoire, un truc énorme, de façon totalement transparente. Pour les djeunz, le 6809 est un 8/16 bits capable d'adresser nativement 64 Ko de mémoire.
Il n'y a _aucune_ raison de limiter la taille d'un processus à 2 Go sr une architecture 32 bits sauf à ne pas vouloir s'emmerder à coder un OS capable de faire mieux ou a utiliser une architecture assez mal foutue pour ne pas pouvoir outrepasser la limite en 32 bits. Je ne vois pas en quoi il serait impossible de faire aujourd'hui avec les composants modernes ce qu'on faisait il y a vingt-cinq ans !
JKB
-- Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre masse corporelle, mais disperse à lui seul 25% de l'énergie que nous consommons tous les jours.
JKB
Le 28-05-2008, à propos de Re: les versions de vista: limitations à la con, nicolas vigier écrivait dans fr.comp.os.linux.debats :
On 2008-05-28, Stephane TOUGARD wrote:
J'ai un AMD 64 ici. Je l'ai essaye en 32 et en 64bits. J'ai pas vu de difference flagrante. Certains benches que j'ai lu laissent meme penser que le 32bits serait plus rapide (ou pas plus lent).
Bah, c'est comme tout : cela dépend de l'usage.
Et quel usage justifie le 64bit ?
La bonne question c'est plutot quel usage justifie le 32 bits sur un cpu 64 bits ?
Il faut demander à Sun (et aussi à DEC^WCompaq^WHP). Sur tous les CPU qui demandent des alignements mémoires (et qui ne les font pas en interne), la mémoire devient assez rapidement un gruyère. Il suffit de compiler un soft sur Sparc en 32 et en 64 bits pour s'en convaincre. Sur les Sparc's actuelles, le noyau est 64 bits, mais le userland est mixte et on ne passe en 64 bits pour les applications que si on prévoit que la mémoire de celle-ci (la vraie, pas celle qui inclut les fichiers ouverts) va dépasser la limite de 4 Go. Passer une application en 64 bits grève ses performances de 5 à 6 %. Ceci est aussi vrai pour Linux sur les mêmes architectures. Le seul vrai bénéfice du passage à 64 bits sur ces architectures est outre le design du processeur et ses 'new features', le nombre accru de registres.
Les 5 à 6 % de pertes s'expliquent essentiellement par les problèmes d'accès à la mémoire (alignements) et par les écroulements de pipe-lines lors des prédictions de saut.
Je sais que je vais déclancher les foudres de ceux qui partent encore du principe que l'alignement mémoire n'est pas nécessaire et je ne _répondrai_ pas à ces posts.
Cordialement,
JKB
-- Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre masse corporelle, mais disperse à lui seul 25% de l'énergie que nous consommons tous les jours.
Le 28-05-2008, à propos de
Re: les versions de vista: limitations à la con,
nicolas vigier écrivait dans fr.comp.os.linux.debats :
On 2008-05-28, Stephane TOUGARD <stephane@unices.org> wrote:
J'ai un AMD 64 ici. Je l'ai essaye en 32 et en 64bits. J'ai pas vu de
difference flagrante. Certains benches que j'ai lu laissent meme penser
que le 32bits serait plus rapide (ou pas plus lent).
Bah, c'est comme tout : cela dépend de l'usage.
Et quel usage justifie le 64bit ?
La bonne question c'est plutot quel usage justifie le 32 bits sur un
cpu 64 bits ?
Il faut demander à Sun (et aussi à DEC^WCompaq^WHP). Sur tous les
CPU qui demandent des alignements mémoires (et qui ne les font pas
en interne), la mémoire devient assez rapidement un gruyère. Il
suffit de compiler un soft sur Sparc en 32 et en 64 bits pour s'en
convaincre. Sur les Sparc's actuelles, le noyau est 64 bits, mais le
userland est mixte et on ne passe en 64 bits pour les applications
que si on prévoit que la mémoire de celle-ci (la vraie, pas celle
qui inclut les fichiers ouverts) va dépasser la limite de 4 Go.
Passer une application en 64 bits grève ses performances de 5 à 6 %.
Ceci est aussi vrai pour Linux sur les mêmes architectures.
Le seul vrai bénéfice du passage à 64 bits sur ces architectures est
outre le design du processeur et ses 'new features', le nombre accru
de registres.
Les 5 à 6 % de pertes s'expliquent essentiellement par les problèmes
d'accès à la mémoire (alignements) et par les écroulements de pipe-lines
lors des prédictions de saut.
Je sais que je vais déclancher les foudres de ceux qui partent
encore du principe que l'alignement mémoire n'est pas nécessaire et
je ne _répondrai_ pas à ces posts.
Cordialement,
JKB
--
Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre
masse corporelle, mais disperse à lui seul 25% de l'énergie que nous
consommons tous les jours.
Le 28-05-2008, à propos de Re: les versions de vista: limitations à la con, nicolas vigier écrivait dans fr.comp.os.linux.debats :
On 2008-05-28, Stephane TOUGARD wrote:
J'ai un AMD 64 ici. Je l'ai essaye en 32 et en 64bits. J'ai pas vu de difference flagrante. Certains benches que j'ai lu laissent meme penser que le 32bits serait plus rapide (ou pas plus lent).
Bah, c'est comme tout : cela dépend de l'usage.
Et quel usage justifie le 64bit ?
La bonne question c'est plutot quel usage justifie le 32 bits sur un cpu 64 bits ?
Il faut demander à Sun (et aussi à DEC^WCompaq^WHP). Sur tous les CPU qui demandent des alignements mémoires (et qui ne les font pas en interne), la mémoire devient assez rapidement un gruyère. Il suffit de compiler un soft sur Sparc en 32 et en 64 bits pour s'en convaincre. Sur les Sparc's actuelles, le noyau est 64 bits, mais le userland est mixte et on ne passe en 64 bits pour les applications que si on prévoit que la mémoire de celle-ci (la vraie, pas celle qui inclut les fichiers ouverts) va dépasser la limite de 4 Go. Passer une application en 64 bits grève ses performances de 5 à 6 %. Ceci est aussi vrai pour Linux sur les mêmes architectures. Le seul vrai bénéfice du passage à 64 bits sur ces architectures est outre le design du processeur et ses 'new features', le nombre accru de registres.
Les 5 à 6 % de pertes s'expliquent essentiellement par les problèmes d'accès à la mémoire (alignements) et par les écroulements de pipe-lines lors des prédictions de saut.
Je sais que je vais déclancher les foudres de ceux qui partent encore du principe que l'alignement mémoire n'est pas nécessaire et je ne _répondrai_ pas à ces posts.
Cordialement,
JKB
-- Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre masse corporelle, mais disperse à lui seul 25% de l'énergie que nous consommons tous les jours.
Patrice Karatchentzeff
"Thierry B." a écrit :
Si je ne m'abuse, PAE permet de rajouter de l'espace d'adressage physique, +4 ou 5 bits d'adresses, mais au sein d'un process, on est encore en 32bits, non ?
Si je ne m'abuse, PAE permet de rajouter de l'espace d'adressage
physique, +4 ou 5 bits d'adresses, mais au sein d'un process, on
est encore en 32bits, non ?
Si je ne m'abuse, PAE permet de rajouter de l'espace d'adressage physique, +4 ou 5 bits d'adresses, mais au sein d'un process, on est encore en 32bits, non ?
Bonjour, Lu ici (apres suivi d'un lien donné par MELMOTH sur fr.comp.os.ms-win dows): http://www.01net.com/editorial/380253/windows-seven-10-pistes-a-suivre- par-microsoft-pour-effacer-l-echec-vista/?di=2&play=0#debutDiaporama
" A titre d'exemple, Windows Vista en 32 bits ne supporte en théorie que 4 Go de RAM, légèrement plus de 3 Go dans les faits. Sa versio n 64 bits peut utiliser 8 Go pour l'édition Basic, 16 Go pour la Premium à plus de 128 Go de RAM pour les éditions Intégral, Professionne l et Entreprise."
Ils veulent en venir ou avec ces limitation à la con?
[ ... ]
640k is more RAM than anyone will ever need. -- Bill Gates, 1981
Bonjour,
Lu ici (apres suivi d'un lien donné par MELMOTH sur fr.comp.os.ms-win dows):
http://www.01net.com/editorial/380253/windows-seven-10-pistes-a-suivre- par-microsoft-pour-effacer-l-echec-vista/?di=2&play=0#debutDiaporama
" A titre d'exemple, Windows Vista en 32 bits ne supporte en théorie
que 4 Go de RAM, légèrement plus de 3 Go dans les faits. Sa versio n 64
bits peut utiliser 8 Go pour l'édition Basic, 16 Go pour la Premium
à plus de 128 Go de RAM pour les éditions Intégral, Professionne l et
Entreprise."
Ils veulent en venir ou avec ces limitation à la con?
[ ... ]
640k is more RAM than anyone will ever need.
-- Bill Gates, 1981
Bonjour, Lu ici (apres suivi d'un lien donné par MELMOTH sur fr.comp.os.ms-win dows): http://www.01net.com/editorial/380253/windows-seven-10-pistes-a-suivre- par-microsoft-pour-effacer-l-echec-vista/?di=2&play=0#debutDiaporama
" A titre d'exemple, Windows Vista en 32 bits ne supporte en théorie que 4 Go de RAM, légèrement plus de 3 Go dans les faits. Sa versio n 64 bits peut utiliser 8 Go pour l'édition Basic, 16 Go pour la Premium à plus de 128 Go de RAM pour les éditions Intégral, Professionne l et Entreprise."
Ils veulent en venir ou avec ces limitation à la con?
[ ... ]
640k is more RAM than anyone will ever need. -- Bill Gates, 1981
Il n'y a _aucune_ raison de limiter la taille d'un processus à 2 Go sr une architecture 32 bits sauf à ne pas vouloir s'emmerder à coder un OS capable de faire mieux
Le problème n'est pas l'OS : pour pouvoir dépasser 4 Go par processus en 32 bits, il faut que les programmes eux-mêmes gèrent la segmentation de leur espace mémoire. Et ça, c'est l'horreur absolue.
Il y a quinze ans, c'était inévitable, parce que la mémoire typique d'un ordinateur a dépassé 64 ko bien avant que les processeurs 32 bits ne détrônent les 16 bits, donc c'était inévitable de devoir se farcir ça. Mais maintenant, les 64 bits sont là avant que la mémoire typique dépasse 4 Go, alors se farcir la segmentation, ce serait une connerie monumentale.
JKB , dans le message <slrng3sm14.il3.knatschke@rayleigh.systella.fr>, a
écrit :
Il n'y a _aucune_ raison de limiter la taille d'un processus à 2 Go
sr une architecture 32 bits sauf à ne pas vouloir s'emmerder à coder
un OS capable de faire mieux
Le problème n'est pas l'OS : pour pouvoir dépasser 4 Go par processus en
32 bits, il faut que les programmes eux-mêmes gèrent la segmentation de leur
espace mémoire. Et ça, c'est l'horreur absolue.
Il y a quinze ans, c'était inévitable, parce que la mémoire typique d'un
ordinateur a dépassé 64 ko bien avant que les processeurs 32 bits ne
détrônent les 16 bits, donc c'était inévitable de devoir se farcir ça. Mais
maintenant, les 64 bits sont là avant que la mémoire typique dépasse 4 Go,
alors se farcir la segmentation, ce serait une connerie monumentale.
Il n'y a _aucune_ raison de limiter la taille d'un processus à 2 Go sr une architecture 32 bits sauf à ne pas vouloir s'emmerder à coder un OS capable de faire mieux
Le problème n'est pas l'OS : pour pouvoir dépasser 4 Go par processus en 32 bits, il faut que les programmes eux-mêmes gèrent la segmentation de leur espace mémoire. Et ça, c'est l'horreur absolue.
Il y a quinze ans, c'était inévitable, parce que la mémoire typique d'un ordinateur a dépassé 64 ko bien avant que les processeurs 32 bits ne détrônent les 16 bits, donc c'était inévitable de devoir se farcir ça. Mais maintenant, les 64 bits sont là avant que la mémoire typique dépasse 4 Go, alors se farcir la segmentation, ce serait une connerie monumentale.
Nicolas George
JKB , dans le message , a écrit :
Je sais que je vais déclancher les foudres de ceux qui partent encore du principe que l'alignement mémoire n'est pas nécessaire et
Le fait est que les x86_64 vont plus vite. Ce n'est pas plus compliqué que ça.
je ne _répondrai_ pas à ces posts.
Bonne idée.
JKB , dans le message <slrng3smln.il3.knatschke@rayleigh.systella.fr>, a
écrit :
Je sais que je vais déclancher les foudres de ceux qui partent
encore du principe que l'alignement mémoire n'est pas nécessaire et
Le fait est que les x86_64 vont plus vite. Ce n'est pas plus compliqué que
ça.
Je sais que je vais déclancher les foudres de ceux qui partent encore du principe que l'alignement mémoire n'est pas nécessaire et
Le fait est que les x86_64 vont plus vite. Ce n'est pas plus compliqué que ça.
je ne _répondrai_ pas à ces posts.
Bonne idée.
JKB
Le 29-05-2008, à propos de Re: les versions de vista: limitations à la con, Nicolas George écrivait dans fr.comp.os.linux.debats :
JKB , dans le message , a écrit :
Je sais que je vais déclancher les foudres de ceux qui partent encore du principe que l'alignement mémoire n'est pas nécessaire et
Le fait est que les x86_64 vont plus vite. Ce n'est pas plus compliqué que ça.
C'est faux, les Integrity sous VMS détrônent tous les x86_64 du monde.
je ne _répondrai_ pas à ces posts.
Bonne idée.
Il ne fallait pas me chercher !
JKB
-- Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre masse corporelle, mais disperse à lui seul 25% de l'énergie que nous consommons tous les jours.
Le 29-05-2008, à propos de
Re: les versions de vista: limitations à la con,
Nicolas George écrivait dans fr.comp.os.linux.debats :
JKB , dans le message <slrng3smln.il3.knatschke@rayleigh.systella.fr>, a
écrit :
Je sais que je vais déclancher les foudres de ceux qui partent
encore du principe que l'alignement mémoire n'est pas nécessaire et
Le fait est que les x86_64 vont plus vite. Ce n'est pas plus compliqué que
ça.
C'est faux, les Integrity sous VMS détrônent tous les x86_64 du
monde.
je ne _répondrai_ pas à ces posts.
Bonne idée.
Il ne fallait pas me chercher !
JKB
--
Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre
masse corporelle, mais disperse à lui seul 25% de l'énergie que nous
consommons tous les jours.
Le 29-05-2008, à propos de Re: les versions de vista: limitations à la con, Nicolas George écrivait dans fr.comp.os.linux.debats :
JKB , dans le message , a écrit :
Je sais que je vais déclancher les foudres de ceux qui partent encore du principe que l'alignement mémoire n'est pas nécessaire et
Le fait est que les x86_64 vont plus vite. Ce n'est pas plus compliqué que ça.
C'est faux, les Integrity sous VMS détrônent tous les x86_64 du monde.
je ne _répondrai_ pas à ces posts.
Bonne idée.
Il ne fallait pas me chercher !
JKB
-- Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre masse corporelle, mais disperse à lui seul 25% de l'énergie que nous consommons tous les jours.
JKB
Le 29-05-2008, à propos de Re: les versions de vista: limitations à la con, Nicolas George écrivait dans fr.comp.os.linux.debats :
JKB , dans le message , a écrit :
Il n'y a _aucune_ raison de limiter la taille d'un processus à 2 Go sr une architecture 32 bits sauf à ne pas vouloir s'emmerder à coder un OS capable de faire mieux
Le problème n'est pas l'OS : pour pouvoir dépasser 4 Go par processus en 32 bits, il faut que les programmes eux-mêmes gèrent la segmentation de leur espace mémoire. Et ça, c'est l'horreur absolue.
Il y a quinze ans, c'était inévitable, parce que la mémoire typique d'un ordinateur a dépassé 64 ko bien avant que les processeurs 32 bits ne détrônent les 16 bits, donc c'était inévitable de devoir se farcir ça. Mais maintenant, les 64 bits sont là avant que la mémoire typique dépasse 4 Go, alors se farcir la segmentation, ce serait une connerie monumentale.
Sauf qu'à l'époque, c'est l'OS qui se tapait ça, et pas les applications. Je n'ai _jamais_ fait de segmentation mémoire explicite dans un de mes codes, c'était le boulot du compilo et de l'OS. Et sous UniFLEX, il n'y avait pas de modèles mémoire comme sous DOS.
JKB
-- Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre masse corporelle, mais disperse à lui seul 25% de l'énergie que nous consommons tous les jours.
Le 29-05-2008, à propos de
Re: les versions de vista: limitations à la con,
Nicolas George écrivait dans fr.comp.os.linux.debats :
JKB , dans le message <slrng3sm14.il3.knatschke@rayleigh.systella.fr>, a
écrit :
Il n'y a _aucune_ raison de limiter la taille d'un processus à 2 Go
sr une architecture 32 bits sauf à ne pas vouloir s'emmerder à coder
un OS capable de faire mieux
Le problème n'est pas l'OS : pour pouvoir dépasser 4 Go par processus en
32 bits, il faut que les programmes eux-mêmes gèrent la segmentation de leur
espace mémoire. Et ça, c'est l'horreur absolue.
Il y a quinze ans, c'était inévitable, parce que la mémoire typique d'un
ordinateur a dépassé 64 ko bien avant que les processeurs 32 bits ne
détrônent les 16 bits, donc c'était inévitable de devoir se farcir ça. Mais
maintenant, les 64 bits sont là avant que la mémoire typique dépasse 4 Go,
alors se farcir la segmentation, ce serait une connerie monumentale.
Sauf qu'à l'époque, c'est l'OS qui se tapait ça, et pas les
applications. Je n'ai _jamais_ fait de segmentation mémoire
explicite dans un de mes codes, c'était le boulot du compilo et de l'OS.
Et sous UniFLEX, il n'y avait pas de modèles mémoire comme sous DOS.
JKB
--
Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre
masse corporelle, mais disperse à lui seul 25% de l'énergie que nous
consommons tous les jours.
Le 29-05-2008, à propos de Re: les versions de vista: limitations à la con, Nicolas George écrivait dans fr.comp.os.linux.debats :
JKB , dans le message , a écrit :
Il n'y a _aucune_ raison de limiter la taille d'un processus à 2 Go sr une architecture 32 bits sauf à ne pas vouloir s'emmerder à coder un OS capable de faire mieux
Le problème n'est pas l'OS : pour pouvoir dépasser 4 Go par processus en 32 bits, il faut que les programmes eux-mêmes gèrent la segmentation de leur espace mémoire. Et ça, c'est l'horreur absolue.
Il y a quinze ans, c'était inévitable, parce que la mémoire typique d'un ordinateur a dépassé 64 ko bien avant que les processeurs 32 bits ne détrônent les 16 bits, donc c'était inévitable de devoir se farcir ça. Mais maintenant, les 64 bits sont là avant que la mémoire typique dépasse 4 Go, alors se farcir la segmentation, ce serait une connerie monumentale.
Sauf qu'à l'époque, c'est l'OS qui se tapait ça, et pas les applications. Je n'ai _jamais_ fait de segmentation mémoire explicite dans un de mes codes, c'était le boulot du compilo et de l'OS. Et sous UniFLEX, il n'y avait pas de modèles mémoire comme sous DOS.
JKB
-- Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre masse corporelle, mais disperse à lui seul 25% de l'énergie que nous consommons tous les jours.
Nicolas George
JKB , dans le message , a écrit :
Sauf qu'à l'époque, c'est l'OS qui se tapait ça, et pas les applications.
Tu te trompes.
Je n'ai _jamais_ fait de segmentation mémoire explicite dans un de mes codes
Alors tes codes ne devaient pas manipuler plus de 64 ko à la fois.
JKB , dans le message <slrng3u6gd.il3.knatschke@rayleigh.systella.fr>, a
écrit :
Sauf qu'à l'époque, c'est l'OS qui se tapait ça, et pas les
applications.
Tu te trompes.
Je n'ai _jamais_ fait de segmentation mémoire
explicite dans un de mes codes
Alors tes codes ne devaient pas manipuler plus de 64 ko à la fois.
