Je ne sais pas si NetBSD a le truc qui va bien, mais la difficulte d'emuler les solaris recents, c'est leur nouveau mecanisme de communication inter-processus, les doors (decrit entre autre dans Stevens): ce mecanisme est incontournable pour l'emulation, vu qu'il est maintenant utilise par le DNS sous Solaris...
Ce n'est qu'un détail mineur par rapport au fait que la libc de Solaris est threadée, et que ni NetBSD ni OpenBSD n'émulent les appels systèmes relatifs aux lwp.
Avec le support SA dans NetBSD-CURRENT, ce serait chose possible, mais personne n'a encore convaincu Emmanuel Dreyfus de se pencher sur le problème.
Pour les aspects 32 bits, pour autant que je sache, OpenBSD est 64 bits pur sur sparc64. Aucune idee du travail necessaire pour emuler des binaires 32 bits en plus.
C'est pénible et source de problèmes. Chez OpenBSD, il y a eu consensus pour dire «on nettoie locore.S qui en a bien besoin d'abord, après on abordera la compatibilité 32 bits et la compatibilité Solaris». Sauf que le manque de temps, etc, fait que locore.S est encore plein de bugs subtils pourris...
Je ne sais pas si NetBSD a le truc qui va bien, mais la difficulte d'emuler
les solaris recents, c'est leur nouveau mecanisme de communication
inter-processus, les doors (decrit entre autre dans Stevens): ce mecanisme
est incontournable pour l'emulation, vu qu'il est maintenant utilise par
le DNS sous Solaris...
Ce n'est qu'un détail mineur par rapport au fait que la libc de Solaris
est threadée, et que ni NetBSD ni OpenBSD n'émulent les appels systèmes
relatifs aux lwp.
Avec le support SA dans NetBSD-CURRENT, ce serait chose possible, mais
personne n'a encore convaincu Emmanuel Dreyfus de se pencher sur le
problème.
Pour les aspects 32 bits, pour autant que je sache, OpenBSD est 64 bits
pur sur sparc64. Aucune idee du travail necessaire pour emuler des
binaires 32 bits en plus.
C'est pénible et source de problèmes. Chez OpenBSD, il y a eu consensus
pour dire «on nettoie locore.S qui en a bien besoin d'abord, après on
abordera la compatibilité 32 bits et la compatibilité Solaris». Sauf que
le manque de temps, etc, fait que locore.S est encore plein de bugs
subtils pourris...
Je ne sais pas si NetBSD a le truc qui va bien, mais la difficulte d'emuler les solaris recents, c'est leur nouveau mecanisme de communication inter-processus, les doors (decrit entre autre dans Stevens): ce mecanisme est incontournable pour l'emulation, vu qu'il est maintenant utilise par le DNS sous Solaris...
Ce n'est qu'un détail mineur par rapport au fait que la libc de Solaris est threadée, et que ni NetBSD ni OpenBSD n'émulent les appels systèmes relatifs aux lwp.
Avec le support SA dans NetBSD-CURRENT, ce serait chose possible, mais personne n'a encore convaincu Emmanuel Dreyfus de se pencher sur le problème.
Pour les aspects 32 bits, pour autant que je sache, OpenBSD est 64 bits pur sur sparc64. Aucune idee du travail necessaire pour emuler des binaires 32 bits en plus.
C'est pénible et source de problèmes. Chez OpenBSD, il y a eu consensus pour dire «on nettoie locore.S qui en a bien besoin d'abord, après on abordera la compatibilité 32 bits et la compatibilité Solaris». Sauf que le manque de temps, etc, fait que locore.S est encore plein de bugs subtils pourris...
Miod Vallat
En fait c'est ce que j'ai fait, c'est sur une Ultra1, j'ai installé un OpenBSD 3.4 mais je regrette un peu le NetBsd que j'avais sur la Station5 (en 32 bits), en particulier le rc.d que je trouve impeccable, serait bien inspiré de le copier chez Open.
Ce point a déjà été débattu, et jusqu'à présent se heurte à un refus catégorique, essentiellement motivé par le caractère ultra-conservateur et fort en gueule de certaines personnes chez OpenBSD (je ne vise personne en particulier ici, contrairement à ce dont vont me taxer certains).
En fait c'est ce que j'ai fait, c'est sur une Ultra1, j'ai installé un
OpenBSD 3.4 mais je regrette un peu le NetBsd que j'avais sur la Station5
(en 32 bits), en particulier le rc.d que je trouve impeccable, serait bien
inspiré de le copier chez Open.
Ce point a déjà été débattu, et jusqu'à présent se heurte à un refus
catégorique, essentiellement motivé par le caractère ultra-conservateur
et fort en gueule de certaines personnes chez OpenBSD (je ne vise
personne en particulier ici, contrairement à ce dont vont me taxer
certains).
En fait c'est ce que j'ai fait, c'est sur une Ultra1, j'ai installé un OpenBSD 3.4 mais je regrette un peu le NetBsd que j'avais sur la Station5 (en 32 bits), en particulier le rc.d que je trouve impeccable, serait bien inspiré de le copier chez Open.
Ce point a déjà été débattu, et jusqu'à présent se heurte à un refus catégorique, essentiellement motivé par le caractère ultra-conservateur et fort en gueule de certaines personnes chez OpenBSD (je ne vise personne en particulier ici, contrairement à ce dont vont me taxer certains).
manu
Marc Bellon wrote:
Visiblement oui, ou alors faire tourner les packages binaires sparc en compatibilité binaire 32 bits, mais bon c'est moins bien.
Hum, hum ! Est-ce possible ?
Je veux dire, sous Solaris, il existe un système de duplication intégrale des librairies partagées, plus certains modules du noyau, pour pouvoir supporter parallèlement des applications 64 et 32 bits.
Pour NetBSD: tu compiles un kernel avec COMPAT_NETBSD32, et tu installes les librairies de NetBSD/sparc dans /emul/netbsd32. Si tu es pressé et que tu ne veux pas faire dans le détail, tu déballes tout le base.tgz de NetBSD/sparc, et ca ira bien.
Mais si c'est pour utiliser les packages de NetBSD/sparc, tu sais que tu peux les compiler en natif sur sparc64, hein... le pkgsrc est là pour ca. Je l'utilise a tout bout de champ, ca fonctionne.
-- Emmanuel Dreyfus Publicité subliminale: achetez ce livre! http://www.eyrolles.com/php.informatique/Ouvrages/9782212112443.php3
Marc Bellon <bellon@lpthe.jussieu.fr> wrote:
Visiblement oui, ou alors faire tourner les packages binaires sparc en
compatibilité binaire 32 bits, mais bon c'est moins bien.
Hum, hum !
Est-ce possible ?
Je veux dire, sous Solaris, il existe un système de duplication
intégrale des librairies partagées, plus certains modules du noyau,
pour pouvoir supporter parallèlement des applications 64 et 32 bits.
Pour NetBSD: tu compiles un kernel avec COMPAT_NETBSD32, et tu installes
les librairies de NetBSD/sparc dans /emul/netbsd32. Si tu es pressé et
que tu ne veux pas faire dans le détail, tu déballes tout le base.tgz de
NetBSD/sparc, et ca ira bien.
Mais si c'est pour utiliser les packages de NetBSD/sparc, tu sais que tu
peux les compiler en natif sur sparc64, hein... le pkgsrc est là pour
ca. Je l'utilise a tout bout de champ, ca fonctionne.
--
Emmanuel Dreyfus
Publicité subliminale: achetez ce livre!
http://www.eyrolles.com/php.informatique/Ouvrages/9782212112443.php3
manu@netbsd.org
Visiblement oui, ou alors faire tourner les packages binaires sparc en compatibilité binaire 32 bits, mais bon c'est moins bien.
Hum, hum ! Est-ce possible ?
Je veux dire, sous Solaris, il existe un système de duplication intégrale des librairies partagées, plus certains modules du noyau, pour pouvoir supporter parallèlement des applications 64 et 32 bits.
Pour NetBSD: tu compiles un kernel avec COMPAT_NETBSD32, et tu installes les librairies de NetBSD/sparc dans /emul/netbsd32. Si tu es pressé et que tu ne veux pas faire dans le détail, tu déballes tout le base.tgz de NetBSD/sparc, et ca ira bien.
Mais si c'est pour utiliser les packages de NetBSD/sparc, tu sais que tu peux les compiler en natif sur sparc64, hein... le pkgsrc est là pour ca. Je l'utilise a tout bout de champ, ca fonctionne.
-- Emmanuel Dreyfus Publicité subliminale: achetez ce livre! http://www.eyrolles.com/php.informatique/Ouvrages/9782212112443.php3
manu
Miod Vallat wrote:
Je ne sais pas si NetBSD a le truc qui va bien, mais la difficulte d'emuler les solaris recents, c'est leur nouveau mecanisme de communication inter-processus, les doors (decrit entre autre dans Stevens): ce mecanisme est incontournable pour l'emulation, vu qu'il est maintenant utilise par le DNS sous Solaris...
Ah, ça, ça a l'air d'un projet rigolo taillé rien que pour moi. Ca marche comment? C'est une API de passage de message dans le genre de celle de Mach?
Ce n'est qu'un détail mineur par rapport au fait que la libc de Solaris est threadée, et que ni NetBSD ni OpenBSD n'émulent les appels systèmes relatifs aux lwp.
Alors la, mon cher, permet moi de te dire que tu es dans la gourrance la plus totale :o)
Il n'y a aucun besoin de supporter des appels systèmes faisant des lwp pour les emuler. En fait, NetBSD a su emuler le clone(2) de Linux bien avant d'avoir des struct lwp dans son kernel. On affectait une struct proc (et donc un pid) à chaque thread du processus, mais ils avaient un espace de mémoire partagé, au bout du compte ca suffisait pour que ca marche assez bien.
J'ai moi même ecrit le support de l'emulation des threads d'IRIX (par sproc(2)), et de celles de Darwin (par thread_create_running, c'est un appel système Mach), alors que le noyau NetBSD le contenait encore aucune struct lwp.
Avec le support SA dans NetBSD-CURRENT, ce serait chose possible, mais personne n'a encore convaincu Emmanuel Dreyfus de se pencher sur le problème.
Faut pas me convaincre, faut me donner du matos. Si quelqu'un a une sparc64 qui ne sert pas...
-- Emmanuel Dreyfus Publicité subliminale: achetez ce livre! http://www.eyrolles.com/php.informatique/Ouvrages/9782212112443.php3
Miod Vallat <miod@online.fr> wrote:
Je ne sais pas si NetBSD a le truc qui va bien, mais la difficulte d'emuler
les solaris recents, c'est leur nouveau mecanisme de communication
inter-processus, les doors (decrit entre autre dans Stevens): ce mecanisme
est incontournable pour l'emulation, vu qu'il est maintenant utilise par
le DNS sous Solaris...
Ah, ça, ça a l'air d'un projet rigolo taillé rien que pour moi. Ca
marche comment? C'est une API de passage de message dans le genre de
celle de Mach?
Ce n'est qu'un détail mineur par rapport au fait que la libc de Solaris
est threadée, et que ni NetBSD ni OpenBSD n'émulent les appels systèmes
relatifs aux lwp.
Alors la, mon cher, permet moi de te dire que tu es dans la gourrance la
plus totale :o)
Il n'y a aucun besoin de supporter des appels systèmes faisant des lwp
pour les emuler. En fait, NetBSD a su emuler le clone(2) de Linux bien
avant d'avoir des struct lwp dans son kernel. On affectait une struct
proc (et donc un pid) à chaque thread du processus, mais ils avaient un
espace de mémoire partagé, au bout du compte ca suffisait pour que ca
marche assez bien.
J'ai moi même ecrit le support de l'emulation des threads d'IRIX (par
sproc(2)), et de celles de Darwin (par thread_create_running, c'est un
appel système Mach), alors que le noyau NetBSD le contenait encore
aucune struct lwp.
Avec le support SA dans NetBSD-CURRENT, ce serait chose possible, mais
personne n'a encore convaincu Emmanuel Dreyfus de se pencher sur le
problème.
Faut pas me convaincre, faut me donner du matos. Si quelqu'un a une
sparc64 qui ne sert pas...
--
Emmanuel Dreyfus
Publicité subliminale: achetez ce livre!
http://www.eyrolles.com/php.informatique/Ouvrages/9782212112443.php3
manu@netbsd.org
Je ne sais pas si NetBSD a le truc qui va bien, mais la difficulte d'emuler les solaris recents, c'est leur nouveau mecanisme de communication inter-processus, les doors (decrit entre autre dans Stevens): ce mecanisme est incontournable pour l'emulation, vu qu'il est maintenant utilise par le DNS sous Solaris...
Ah, ça, ça a l'air d'un projet rigolo taillé rien que pour moi. Ca marche comment? C'est une API de passage de message dans le genre de celle de Mach?
Ce n'est qu'un détail mineur par rapport au fait que la libc de Solaris est threadée, et que ni NetBSD ni OpenBSD n'émulent les appels systèmes relatifs aux lwp.
Alors la, mon cher, permet moi de te dire que tu es dans la gourrance la plus totale :o)
Il n'y a aucun besoin de supporter des appels systèmes faisant des lwp pour les emuler. En fait, NetBSD a su emuler le clone(2) de Linux bien avant d'avoir des struct lwp dans son kernel. On affectait une struct proc (et donc un pid) à chaque thread du processus, mais ils avaient un espace de mémoire partagé, au bout du compte ca suffisait pour que ca marche assez bien.
J'ai moi même ecrit le support de l'emulation des threads d'IRIX (par sproc(2)), et de celles de Darwin (par thread_create_running, c'est un appel système Mach), alors que le noyau NetBSD le contenait encore aucune struct lwp.
Avec le support SA dans NetBSD-CURRENT, ce serait chose possible, mais personne n'a encore convaincu Emmanuel Dreyfus de se pencher sur le problème.
Faut pas me convaincre, faut me donner du matos. Si quelqu'un a une sparc64 qui ne sert pas...
-- Emmanuel Dreyfus Publicité subliminale: achetez ce livre! http://www.eyrolles.com/php.informatique/Ouvrages/9782212112443.php3
Miod Vallat
Ce n'est qu'un détail mineur par rapport au fait que la libc de Solaris est threadée, et que ni NetBSD ni OpenBSD n'émulent les appels systèmes relatifs aux lwp.
Alors la, mon cher, permet moi de te dire que tu es dans la gourrance la plus totale :o)
Il n'y a aucun besoin de supporter des appels systèmes faisant des lwp pour les emuler. En fait, NetBSD a su emuler le clone(2) de Linux bien avant d'avoir des struct lwp dans son kernel. On affectait une struct proc (et donc un pid) à chaque thread du processus, mais ils avaient un espace de mémoire partagé, au bout du compte ca suffisait pour que ca marche assez bien.
Moi je trouve ça gore (le t est en option, au choix du lecteur).
Fais tourner Acrobat 4/Solaris en émulation sans régression par cette méthode, et je changerai d'avis sur son bien fondé.
Ce n'est qu'un détail mineur par rapport au fait que la libc de Solaris
est threadée, et que ni NetBSD ni OpenBSD n'émulent les appels systèmes
relatifs aux lwp.
Alors la, mon cher, permet moi de te dire que tu es dans la gourrance la
plus totale :o)
Il n'y a aucun besoin de supporter des appels systèmes faisant des lwp
pour les emuler. En fait, NetBSD a su emuler le clone(2) de Linux bien
avant d'avoir des struct lwp dans son kernel. On affectait une struct
proc (et donc un pid) à chaque thread du processus, mais ils avaient un
espace de mémoire partagé, au bout du compte ca suffisait pour que ca
marche assez bien.
Moi je trouve ça gore (le t est en option, au choix du lecteur).
Fais tourner Acrobat 4/Solaris en émulation sans régression par cette
méthode, et je changerai d'avis sur son bien fondé.
Ce n'est qu'un détail mineur par rapport au fait que la libc de Solaris est threadée, et que ni NetBSD ni OpenBSD n'émulent les appels systèmes relatifs aux lwp.
Alors la, mon cher, permet moi de te dire que tu es dans la gourrance la plus totale :o)
Il n'y a aucun besoin de supporter des appels systèmes faisant des lwp pour les emuler. En fait, NetBSD a su emuler le clone(2) de Linux bien avant d'avoir des struct lwp dans son kernel. On affectait une struct proc (et donc un pid) à chaque thread du processus, mais ils avaient un espace de mémoire partagé, au bout du compte ca suffisait pour que ca marche assez bien.
Moi je trouve ça gore (le t est en option, au choix du lecteur).
Fais tourner Acrobat 4/Solaris en émulation sans régression par cette méthode, et je changerai d'avis sur son bien fondé.
Manuel Bouyer
Marc Bellon wrote:
In article (Dans l'article) <1g5o8lq.1vyi7w3d7hhoyN%, (Emmanuel Dreyfus) wrote (écrivait) :
Visiblement oui, ou alors faire tourner les packages binaires sparc en compatibilité binaire 32 bits, mais bon c'est moins bien.
Hum, hum ! Est-ce possible ?
Je veux dire, sous Solaris, il existe un système de duplication intégrale des librairies partagées, plus certains modules du noyau, pour pouvoir supporter parallèlement des applications 64 et 32 bits.
Oui bien sur. Sous NetBSD il suffit d'installer les librairies NetBSD/sparc dans /emul/netbsd32.
Autre solution: si l'on a pas besoin du 64bits, on peut installer NetBSD/sparc sur une Ultra. La difference de performances n'est pas sensibles sur les stations.
-- Manuel Bouyer NetBSD: 24 ans d'experience feront toujours la difference --
Marc Bellon <bellon@lpthe.jussieu.fr> wrote:
In article (Dans l'article) <1g5o8lq.1vyi7w3d7hhoyN%manu@netbsd.org>,
manu@netbsd.org (Emmanuel Dreyfus) wrote (écrivait) :
Visiblement oui, ou alors faire tourner les packages binaires sparc en
compatibilité binaire 32 bits, mais bon c'est moins bien.
Hum, hum !
Est-ce possible ?
Je veux dire, sous Solaris, il existe un système de duplication
intégrale des librairies partagées, plus certains modules du noyau,
pour pouvoir supporter parallèlement des applications 64 et 32 bits.
Oui bien sur. Sous NetBSD il suffit d'installer les librairies NetBSD/sparc
dans /emul/netbsd32.
Autre solution: si l'on a pas besoin du 64bits, on peut installer NetBSD/sparc
sur une Ultra. La difference de performances n'est pas sensibles sur les
stations.
--
Manuel Bouyer <bouyer@nerim.net>
NetBSD: 24 ans d'experience feront toujours la difference
--
In article (Dans l'article) <1g5o8lq.1vyi7w3d7hhoyN%, (Emmanuel Dreyfus) wrote (écrivait) :
Visiblement oui, ou alors faire tourner les packages binaires sparc en compatibilité binaire 32 bits, mais bon c'est moins bien.
Hum, hum ! Est-ce possible ?
Je veux dire, sous Solaris, il existe un système de duplication intégrale des librairies partagées, plus certains modules du noyau, pour pouvoir supporter parallèlement des applications 64 et 32 bits.
Oui bien sur. Sous NetBSD il suffit d'installer les librairies NetBSD/sparc dans /emul/netbsd32.
Autre solution: si l'on a pas besoin du 64bits, on peut installer NetBSD/sparc sur une Ultra. La difference de performances n'est pas sensibles sur les stations.
-- Manuel Bouyer NetBSD: 24 ans d'experience feront toujours la difference --
mips
On Wed, 10 Dec 2003 17:05:48 +0000 (UTC) Miod Vallat wrote:
Ce point a déjà été débattu, et jusqu'à présent se heurte à un refus catégorique, essentiellement motivé par le caractère ultra-conservateur et fort en gueule de certaines personnes chez OpenBSD (je ne vise personne en particulier ici, contrairement à ce dont vont me taxer certains).
De toutes facon il ne reste plus grand monde de chez OpenBSD ici. A moins que Matthieu traine dans le coin histoire de pas laisser Marc tout seul :)
mips
On Wed, 10 Dec 2003 17:05:48 +0000 (UTC)
Miod Vallat <miod@online.fr> wrote:
Ce point a déjà été débattu, et jusqu'à présent se heurte à un refus
catégorique, essentiellement motivé par le caractère
ultra-conservateur et fort en gueule de certaines personnes chez
OpenBSD (je ne vise personne en particulier ici, contrairement à ce
dont vont me taxer certains).
De toutes facon il ne reste plus grand monde de chez OpenBSD ici. A
moins que Matthieu traine dans le coin histoire de pas laisser Marc
tout seul :)
On Wed, 10 Dec 2003 17:05:48 +0000 (UTC) Miod Vallat wrote:
Ce point a déjà été débattu, et jusqu'à présent se heurte à un refus catégorique, essentiellement motivé par le caractère ultra-conservateur et fort en gueule de certaines personnes chez OpenBSD (je ne vise personne en particulier ici, contrairement à ce dont vont me taxer certains).
De toutes facon il ne reste plus grand monde de chez OpenBSD ici. A moins que Matthieu traine dans le coin histoire de pas laisser Marc tout seul :)
mips
Vincent Bernat
OoO En ce doux début de matinée du mercredi 10 décembre 2003, vers 08:53, (Marc Espie) disait:
Pour les aspects 32 bits, pour autant que je sache, OpenBSD est 64 bits pur sur sparc64. Aucune idee du travail necessaire pour emuler des binaires 32 bits en plus.
D'un point de vue des performances, le passage d'un Linux 32 bits (port Sparc de Debian) vers un OpenBSD 64 bits change-t-il quelque chose au niveau des perfs des applications comme mozilla ? -- BOFH excuse #226: A star wars satellite accidently blew up the WAN.
OoO En ce doux début de matinée du mercredi 10 décembre 2003, vers
08:53, espie@tetto.gentiane.org (Marc Espie) disait:
Pour les aspects 32 bits, pour autant que je sache, OpenBSD est 64 bits
pur sur sparc64. Aucune idee du travail necessaire pour emuler des
binaires 32 bits en plus.
D'un point de vue des performances, le passage d'un Linux 32 bits
(port Sparc de Debian) vers un OpenBSD 64 bits change-t-il quelque
chose au niveau des perfs des applications comme mozilla ?
--
BOFH excuse #226:
A star wars satellite accidently blew up the WAN.
OoO En ce doux début de matinée du mercredi 10 décembre 2003, vers 08:53, (Marc Espie) disait:
Pour les aspects 32 bits, pour autant que je sache, OpenBSD est 64 bits pur sur sparc64. Aucune idee du travail necessaire pour emuler des binaires 32 bits en plus.
D'un point de vue des performances, le passage d'un Linux 32 bits (port Sparc de Debian) vers un OpenBSD 64 bits change-t-il quelque chose au niveau des perfs des applications comme mozilla ? -- BOFH excuse #226: A star wars satellite accidently blew up the WAN.
pornin
According to Vincent Bernat :
D'un point de vue des performances, le passage d'un Linux 32 bits (port Sparc de Debian) vers un OpenBSD 64 bits change-t-il quelque chose au niveau des perfs des applications comme mozilla ?
Il est possible que le passage à 64 bits ralentisse un peu le Mozilla (mais probablement pas de beaucoup). L'idée est qu'en 64 bits, les pointeurs sont deux fois plus gros qu'en 32 bits (hé...) et que du coup ça augmente un peu la consommation mémoire de certains processus (donc ça stresse un peu plus les caches et ça fait travailler le swap). Le "64 bits natif" permet de faire des calculs plus efficaces sur des nombres entiers de 64 bits, mais ça m'étonnerait que ça concerne beaucoup une application telle que Mozilla.
Dans la pratique, je pense que s'il y a des différences de performances, ce sera beaucoup plus dû à des différences d'OS (gestion de la mémoire, efficacité des filesystems, support du contrôleur disque et du chipset vidéo, scheduler...) qu'au passage 32->64 bits. Et je ne suis pas en mesure, là comme ça à froid (et même à la louche), de prédire dans quel sens le passage Linux -> OpenBSD influera sur les performances sur Sparc.
--Thomas Pornin
According to Vincent Bernat <bernat@free.fr>:
D'un point de vue des performances, le passage d'un Linux 32 bits
(port Sparc de Debian) vers un OpenBSD 64 bits change-t-il quelque
chose au niveau des perfs des applications comme mozilla ?
Il est possible que le passage à 64 bits ralentisse un peu le Mozilla
(mais probablement pas de beaucoup). L'idée est qu'en 64 bits, les
pointeurs sont deux fois plus gros qu'en 32 bits (hé...) et que du coup
ça augmente un peu la consommation mémoire de certains processus (donc
ça stresse un peu plus les caches et ça fait travailler le swap). Le "64
bits natif" permet de faire des calculs plus efficaces sur des nombres
entiers de 64 bits, mais ça m'étonnerait que ça concerne beaucoup une
application telle que Mozilla.
Dans la pratique, je pense que s'il y a des différences de performances,
ce sera beaucoup plus dû à des différences d'OS (gestion de la mémoire,
efficacité des filesystems, support du contrôleur disque et du chipset
vidéo, scheduler...) qu'au passage 32->64 bits. Et je ne suis pas en
mesure, là comme ça à froid (et même à la louche), de prédire dans quel
sens le passage Linux -> OpenBSD influera sur les performances sur
Sparc.
D'un point de vue des performances, le passage d'un Linux 32 bits (port Sparc de Debian) vers un OpenBSD 64 bits change-t-il quelque chose au niveau des perfs des applications comme mozilla ?
Il est possible que le passage à 64 bits ralentisse un peu le Mozilla (mais probablement pas de beaucoup). L'idée est qu'en 64 bits, les pointeurs sont deux fois plus gros qu'en 32 bits (hé...) et que du coup ça augmente un peu la consommation mémoire de certains processus (donc ça stresse un peu plus les caches et ça fait travailler le swap). Le "64 bits natif" permet de faire des calculs plus efficaces sur des nombres entiers de 64 bits, mais ça m'étonnerait que ça concerne beaucoup une application telle que Mozilla.
Dans la pratique, je pense que s'il y a des différences de performances, ce sera beaucoup plus dû à des différences d'OS (gestion de la mémoire, efficacité des filesystems, support du contrôleur disque et du chipset vidéo, scheduler...) qu'au passage 32->64 bits. Et je ne suis pas en mesure, là comme ça à froid (et même à la louche), de prédire dans quel sens le passage Linux -> OpenBSD influera sur les performances sur Sparc.
--Thomas Pornin
Marwan FeanoR/var Burelle
On Wed, 10 Dec 2003 07:25:27 +0100 (Emmanuel Dreyfus) wrote:
Y'a aussi la volonté d'ouverture: si tu veux faire du code correct sur ia64, faut acheter le compilo du constructeur.
