J'ai decouvert linuske et les plaisirs de l'installation de debian il y a
quelques mois. Au final, ca marche pas mal, j'ai fait quelques essais au taff et
c'est assez prometteur (pour de la simulation avec des stagiaires qui ne
savent pas eviter de swaper et pour faire des notes pdf à partir de LaTeX
pour que les vieux sous windows ne puissent pas repomper texto ce que je
fais). On envisage de généraliser l'experience à quelques autres pcs.
La question que je me pose c'est : est-ce que le choix de la distribution
peut impacter sur les perfos ? Mon interpretation est que la distribution
n'est qu'une série d'outils de config userfriendly plus une maniere de gerer
des packages plus des packages plus ou moins recents. Je me demande si une
mandrake avec un noyau 2.6 et une debian avec un noyau 2.6 auront les
memes performances par example pour traiter des fichiers binaires et faire
des transformées de Fourier (pour faire simple). Si quelqu'un peut
eclairer ma lanterne...
Dans fr.comp.os.linux.debats, Non Compos Mentis nous disait:
Bonjour,
J'ai decouvert linuske et les plaisirs de l'installation de debian il y a quelques mois.
Bien :-)
La question que je me pose c'est : est-ce que le choix de la distribution peut impacter sur les perfos ? Mon interpretation est que la distribution n'est qu'une série d'outils de config userfriendly plus une maniere de gerer des packages plus des packages plus ou moins recents. Je me demande si une mandrake avec un noyau 2.6 et une debian avec un noyau 2.6 auront les memes performances par example pour traiter des fichiers binaires et faire des transformées de Fourier (pour faire simple). Si quelqu'un peut eclairer ma lanterne...
On a la même interprétation. À moins que tu tombes sur une distrib qui te lance par défaut pleins de services bouffeurs de ressources, les perfs sont indépendantes du choix de la distrib.
-- fakeroot debian/rules troll
Salut,
Dans fr.comp.os.linux.debats, Non Compos Mentis nous disait:
Bonjour,
J'ai decouvert linuske et les plaisirs de l'installation de debian il y a
quelques mois.
Bien :-)
La question que je me pose c'est : est-ce que le choix de la distribution
peut impacter sur les perfos ? Mon interpretation est que la distribution
n'est qu'une série d'outils de config userfriendly plus une maniere de gerer
des packages plus des packages plus ou moins recents. Je me demande si une
mandrake avec un noyau 2.6 et une debian avec un noyau 2.6 auront les
memes performances par example pour traiter des fichiers binaires et faire
des transformées de Fourier (pour faire simple). Si quelqu'un peut
eclairer ma lanterne...
On a la même interprétation. À moins que tu tombes sur une distrib qui
te lance par défaut pleins de services bouffeurs de ressources, les
perfs sont indépendantes du choix de la distrib.
Dans fr.comp.os.linux.debats, Non Compos Mentis nous disait:
Bonjour,
J'ai decouvert linuske et les plaisirs de l'installation de debian il y a quelques mois.
Bien :-)
La question que je me pose c'est : est-ce que le choix de la distribution peut impacter sur les perfos ? Mon interpretation est que la distribution n'est qu'une série d'outils de config userfriendly plus une maniere de gerer des packages plus des packages plus ou moins recents. Je me demande si une mandrake avec un noyau 2.6 et une debian avec un noyau 2.6 auront les memes performances par example pour traiter des fichiers binaires et faire des transformées de Fourier (pour faire simple). Si quelqu'un peut eclairer ma lanterne...
On a la même interprétation. À moins que tu tombes sur une distrib qui te lance par défaut pleins de services bouffeurs de ressources, les perfs sont indépendantes du choix de la distrib.
-- fakeroot debian/rules troll
Patrice Karatchentzeff
Laurent Fousse writes:
[...]
On a la même interprétation. À moins que tu tombes sur une distrib qui te lance par défaut pleins de services bouffeurs de ressources, les perfs sont indépendantes du choix de la distrib.
Sûr : et le travail d'un bon admin est de faire le nettoyage des scripts d'init... à partir de là, aucune raison de ne pas avoir les mêmes performances : même noyau, même libc, même compilo, même matériel...
On a la même interprétation. À moins que tu tombes sur une distrib qui
te lance par défaut pleins de services bouffeurs de ressources, les
perfs sont indépendantes du choix de la distrib.
Sûr : et le travail d'un bon admin est de faire le nettoyage des
scripts d'init... à partir de là, aucune raison de ne pas avoir les
mêmes performances : même noyau, même libc, même compilo, même
matériel...
On a la même interprétation. À moins que tu tombes sur une distrib qui te lance par défaut pleins de services bouffeurs de ressources, les perfs sont indépendantes du choix de la distrib.
Sûr : et le travail d'un bon admin est de faire le nettoyage des scripts d'init... à partir de là, aucune raison de ne pas avoir les mêmes performances : même noyau, même libc, même compilo, même matériel...
Sûr : et le travail d'un bon admin est de faire le nettoyage des scripts d'init... à partir de là, aucune raison de ne pas avoir les mêmes performances : même noyau, même libc, même compilo, même matériel...
trop rapide ;-)
J'ajouterai de plus que pour faire du calcul « pur », le matériel compte même plus que le logiciel (même s'il faut légèrement tempéré)... Bref, dans ce cas, autant choisir la ditribution (Linux ou BSD) qui sera le mieux supporté par l'admin local ou le copain de l'admin local...
Sûr : et le travail d'un bon admin est de faire le nettoyage des
scripts d'init... à partir de là, aucune raison de ne pas avoir les
mêmes performances : même noyau, même libc, même compilo, même
matériel...
trop rapide ;-)
J'ajouterai de plus que pour faire du calcul « pur », le matériel
compte même plus que le logiciel (même s'il faut légèrement
tempéré)... Bref, dans ce cas, autant choisir la ditribution (Linux ou
BSD) qui sera le mieux supporté par l'admin local ou le copain de
l'admin local...
Sûr : et le travail d'un bon admin est de faire le nettoyage des scripts d'init... à partir de là, aucune raison de ne pas avoir les mêmes performances : même noyau, même libc, même compilo, même matériel...
trop rapide ;-)
J'ajouterai de plus que pour faire du calcul « pur », le matériel compte même plus que le logiciel (même s'il faut légèrement tempéré)... Bref, dans ce cas, autant choisir la ditribution (Linux ou BSD) qui sera le mieux supporté par l'admin local ou le copain de l'admin local...
La seule différence qu'il pourrait y avoir, c'est le processeur pour lequel est compilé la distribution. Certaines compilent leurs softs avec des optimisations Pentium, d'autres avec du code 386. C'est supposé faire une petite différence (en pratique je ne pense pas que ce soit crucial).
C'est vraiment une petite différence... C'est un pouillème dans des benchs donc je pense que c'est invisible à l'usage.
La seule différence qu'il pourrait y avoir, c'est le processeur pour lequel
est compilé la distribution. Certaines compilent leurs softs avec des
optimisations Pentium, d'autres avec du code 386. C'est supposé faire une
petite différence (en pratique je ne pense pas que ce soit crucial).
C'est vraiment une petite différence... C'est un pouillème dans des
benchs donc je pense que c'est invisible à l'usage.
La seule différence qu'il pourrait y avoir, c'est le processeur pour lequel est compilé la distribution. Certaines compilent leurs softs avec des optimisations Pentium, d'autres avec du code 386. C'est supposé faire une petite différence (en pratique je ne pense pas que ce soit crucial).
C'est vraiment une petite différence... C'est un pouillème dans des benchs donc je pense que c'est invisible à l'usage.
La seule différence qu'il pourrait y avoir, c'est le processeur pour lequel est compilé la distribution. Certaines compilent leurs softs avec des optimisations Pentium, d'autres avec du code 386. C'est supposé faire une petite différence (en pratique je ne pense pas que ce soit crucial).
C'est vraiment une petite différence... C'est un pouillème dans des benchs donc je pense que c'est invisible à l'usage.
Sur mon athlon-xp, le gain de performance est d'environ 15% entre une compilation pour athlon-xp contre une compilation pour un i386, pour la même application sur la même machine. Sur des applications de calculs intensifs, c'est un jour de calcul gagné chaque semaine. Pour avoir le même gain en choisissant un CPU plus puissant, il faut payer 50% plus cher. Ce n'est donc pas complètement négligeable.
Peut-être qu'en employant autre chose que gcc...
gcc produit un code en général assez bien optimisé, au moins sur x86. Son principal défaut est d'être lui-même assez lent.
-- Richard
Fred Albrecht <os6m34i02@sneakemail.com> writes:
[...]
La seule différence qu'il pourrait y avoir, c'est le processeur pour
lequel est compilé la distribution. Certaines compilent leurs softs avec
des optimisations Pentium, d'autres avec du code 386. C'est supposé faire
une petite différence (en pratique je ne pense pas que ce soit crucial).
C'est vraiment une petite différence... C'est un pouillème dans des
benchs donc je pense que c'est invisible à l'usage.
Sur mon athlon-xp, le gain de performance est d'environ 15% entre une
compilation pour athlon-xp contre une compilation pour un i386, pour la
même application sur la même machine. Sur des applications de calculs
intensifs, c'est un jour de calcul gagné chaque semaine. Pour avoir le même
gain en choisissant un CPU plus puissant, il faut payer 50% plus cher. Ce
n'est donc pas complètement négligeable.
Peut-être qu'en employant autre chose que gcc...
gcc produit un code en général assez bien optimisé, au moins sur x86. Son
principal défaut est d'être lui-même assez lent.
La seule différence qu'il pourrait y avoir, c'est le processeur pour lequel est compilé la distribution. Certaines compilent leurs softs avec des optimisations Pentium, d'autres avec du code 386. C'est supposé faire une petite différence (en pratique je ne pense pas que ce soit crucial).
C'est vraiment une petite différence... C'est un pouillème dans des benchs donc je pense que c'est invisible à l'usage.
Sur mon athlon-xp, le gain de performance est d'environ 15% entre une compilation pour athlon-xp contre une compilation pour un i386, pour la même application sur la même machine. Sur des applications de calculs intensifs, c'est un jour de calcul gagné chaque semaine. Pour avoir le même gain en choisissant un CPU plus puissant, il faut payer 50% plus cher. Ce n'est donc pas complètement négligeable.
Peut-être qu'en employant autre chose que gcc...
gcc produit un code en général assez bien optimisé, au moins sur x86. Son principal défaut est d'être lui-même assez lent.
-- Richard
Miod Vallat
gcc produit un code en général assez bien optimisé, au moins sur x86. Son principal défaut est d'être lui-même assez lent.
s/au moins/uniquement/
gcc produit un code en général assez bien optimisé, au moins sur x86. Son
principal défaut est d'être lui-même assez lent.
gcc produit un code en général assez bien optimisé, au moins sur x86. Son principal défaut est d'être lui-même assez lent.
s/au moins/uniquement/
Fred Albrecht
Richard Delorme a dit dans fr.comp.os.linux.debats :
Sur mon athlon-xp, le gain de performance est d'environ 15% entre une compilation pour athlon-xp contre une compilation pour un i386, pour la même application sur la même machine. Sur des applications de calculs intensifs, c'est un jour de calcul gagné chaque semaine. Pour avoir le même gain en choisissant un CPU plus puissant, il faut payer 50% plus cher. Ce n'est donc pas complètement négligeable.
Ah ben tiens, je n'aurais pas cru que ce soit si sensible que ça...
Des tests ont été faits ou bien c'est à vue de nez ?
Ce serait intéressant de faire une sorte de benchmark là dessus pour voir l'incidence qu'ont un noyau recompilé pour l'architecture qui va bien d'une part et les applis recompilées d'autre part. Pas très simple à mettre en oeuvre en revanche.
-- Fred. Linux, {Free,Open}BSD mercenary {sys,net}admin @ N48º53.115 E02º19.31 This message is made from the freshest handpicked electrons http://www.fredshome.org
Richard Delorme a dit dans fr.comp.os.linux.debats :
Sur mon athlon-xp, le gain de performance est d'environ 15% entre une
compilation pour athlon-xp contre une compilation pour un i386, pour la
même application sur la même machine. Sur des applications de calculs
intensifs, c'est un jour de calcul gagné chaque semaine. Pour avoir le
même gain en choisissant un CPU plus puissant, il faut payer 50% plus
cher. Ce n'est donc pas complètement négligeable.
Ah ben tiens, je n'aurais pas cru que ce soit si sensible que ça...
Des tests ont été faits ou bien c'est à vue de nez ?
Ce serait intéressant de faire une sorte de benchmark là dessus pour voir
l'incidence qu'ont un noyau recompilé pour l'architecture qui va bien d'une
part et les applis recompilées d'autre part. Pas très simple à mettre en
oeuvre en revanche.
--
Fred.
Linux, {Free,Open}BSD mercenary {sys,net}admin @ N48º53.115 E02º19.31
This message is made from the freshest handpicked electrons
http://www.fredshome.org
Richard Delorme a dit dans fr.comp.os.linux.debats :
Sur mon athlon-xp, le gain de performance est d'environ 15% entre une compilation pour athlon-xp contre une compilation pour un i386, pour la même application sur la même machine. Sur des applications de calculs intensifs, c'est un jour de calcul gagné chaque semaine. Pour avoir le même gain en choisissant un CPU plus puissant, il faut payer 50% plus cher. Ce n'est donc pas complètement négligeable.
Ah ben tiens, je n'aurais pas cru que ce soit si sensible que ça...
Des tests ont été faits ou bien c'est à vue de nez ?
Ce serait intéressant de faire une sorte de benchmark là dessus pour voir l'incidence qu'ont un noyau recompilé pour l'architecture qui va bien d'une part et les applis recompilées d'autre part. Pas très simple à mettre en oeuvre en revanche.
-- Fred. Linux, {Free,Open}BSD mercenary {sys,net}admin @ N48º53.115 E02º19.31 This message is made from the freshest handpicked electrons http://www.fredshome.org
Patrice Karatchentzeff
Richard Delorme writes:
[...]
C'est vraiment une petite différence... C'est un pouillème dans des benchs donc je pense que c'est invisible à l'usage.
Sur mon athlon-xp, le gain de performance est d'environ 15% entre une compilation pour athlon-xp contre une compilation pour un i386, pour la même application sur la même machine. Sur des applications de calculs intensifs, c'est un jour de calcul gagné chaque semaine. Pour avoir le même gain en choisissant un CPU plus puissant, il faut payer 50% plus cher. Ce n'est donc pas complètement négligeable.
C'est bien ce que je dis : à part pour des applis particulières - genre calculs dédiés, i.e. un truc relativement optimisé et reproductible - on n'arrive à rien de mieux ou c'est tellement « pouillèmesque » que c'est tout à fait négligeable, c'est-à-dire à l'usager normal (bureautique, surf, et quelques autres bricoles).
Peut-être qu'en employant autre chose que gcc...
gcc produit un code en général assez bien optimisé, au moins sur x86. Son principal défaut est d'être lui-même assez lent.
J'ai ouie dire que les compilos Intel obtenait un gain nettement plus important sur les PIV... Me gourre-je ?
C'est vraiment une petite différence... C'est un pouillème dans des
benchs donc je pense que c'est invisible à l'usage.
Sur mon athlon-xp, le gain de performance est d'environ 15% entre une
compilation pour athlon-xp contre une compilation pour un i386, pour la
même application sur la même machine. Sur des applications de calculs
intensifs, c'est un jour de calcul gagné chaque semaine. Pour avoir le même
gain en choisissant un CPU plus puissant, il faut payer 50% plus cher. Ce
n'est donc pas complètement négligeable.
C'est bien ce que je dis : à part pour des applis particulières -
genre calculs dédiés, i.e. un truc relativement optimisé et
reproductible - on n'arrive à rien de mieux ou c'est tellement
« pouillèmesque » que c'est tout à fait négligeable, c'est-à-dire à
l'usager normal (bureautique, surf, et quelques autres bricoles).
Peut-être qu'en employant autre chose que gcc...
gcc produit un code en général assez bien optimisé, au moins sur x86. Son
principal défaut est d'être lui-même assez lent.
J'ai ouie dire que les compilos Intel obtenait un gain nettement plus
important sur les PIV... Me gourre-je ?
C'est vraiment une petite différence... C'est un pouillème dans des benchs donc je pense que c'est invisible à l'usage.
Sur mon athlon-xp, le gain de performance est d'environ 15% entre une compilation pour athlon-xp contre une compilation pour un i386, pour la même application sur la même machine. Sur des applications de calculs intensifs, c'est un jour de calcul gagné chaque semaine. Pour avoir le même gain en choisissant un CPU plus puissant, il faut payer 50% plus cher. Ce n'est donc pas complètement négligeable.
C'est bien ce que je dis : à part pour des applis particulières - genre calculs dédiés, i.e. un truc relativement optimisé et reproductible - on n'arrive à rien de mieux ou c'est tellement « pouillèmesque » que c'est tout à fait négligeable, c'est-à-dire à l'usager normal (bureautique, surf, et quelques autres bricoles).
Peut-être qu'en employant autre chose que gcc...
gcc produit un code en général assez bien optimisé, au moins sur x86. Son principal défaut est d'être lui-même assez lent.
J'ai ouie dire que les compilos Intel obtenait un gain nettement plus important sur les PIV... Me gourre-je ?
C'est clair que l'optimisation dépend clairement des applications que l'on utilise. En ce qui me concerne, j'ai fait quelques tests entre un windows et une debian (2.4.21 compilé au mieux) avec Matlab, octave et scilab. Les pertes en temps de calcul sous windows sont violentes des que j'utilise la mémoire virtuelle. Par contre, elles sont plus minimes si on évite d'utiliser la mémoire virtuelle (pas tout le temps facile ;p)
Un autre soucis : Je travaille avec un outil dont je tairais le nom qui fonctionne sous solaris et qui est en train d être porté sous linux. L'executable ne fonctionne pas avec une debian et un noyau 2.4.21 car il a été compilé sur une red hat avec un noyau 2.4.18. A vos avis, est-ce que le pb est du à la distribution ou au noyau ?
Le Tue, 22 Jul 2003 18:27:42 +0200, Non Compos Mentis a écrit :
Bonjour,
J'ai decouvert linuske et les plaisirs de l'installation de debian il y a quelques mois. Au final, ca marche pas mal, j'ai fait quelques essais au taff et c'est assez prometteur (pour de la simulation avec des stagiaires qui ne savent pas eviter de swaper et pour faire des notes pdf à partir de LaTeX pour que les vieux sous windows ne puissent pas repomper texto ce que je fais). On envisage de généraliser l'experience à quelques autres pcs.
La question que je me pose c'est : est-ce que le choix de la distribution peut impacter sur les perfos ? Mon interpretation est que la distribution n'est qu'une série d'outils de config userfriendly plus une maniere de gerer des packages plus des packages plus ou moins recents. Je me demande si une mandrake avec un noyau 2.6 et une debian avec un noyau 2.6 auront les memes performances par example pour traiter des fichiers binaires et faire des transformées de Fourier (pour faire simple). Si quelqu'un peut eclairer ma lanterne...
Merci F
Merci pour toutes vos réponses.
C'est clair que l'optimisation dépend clairement des applications que l'on
utilise. En ce qui me concerne, j'ai fait quelques tests entre un windows
et une debian (2.4.21 compilé au mieux) avec Matlab, octave et scilab. Les pertes en temps de calcul
sous windows sont violentes des que j'utilise la mémoire virtuelle. Par
contre, elles sont plus minimes si on évite d'utiliser la mémoire
virtuelle (pas tout le temps facile ;p)
Un autre soucis : Je travaille avec un outil dont je tairais le nom qui
fonctionne sous solaris et qui est en train d être porté sous linux.
L'executable ne fonctionne pas avec une debian et un noyau 2.4.21 car il a
été compilé sur une red hat avec un noyau 2.4.18. A vos avis, est-ce que
le pb est du à la distribution ou au noyau ?
Le Tue, 22 Jul 2003 18:27:42 +0200, Non Compos Mentis a écrit :
Bonjour,
J'ai decouvert linuske et les plaisirs de l'installation de debian il y a
quelques mois. Au final, ca marche pas mal, j'ai fait quelques essais au taff et
c'est assez prometteur (pour de la simulation avec des stagiaires qui ne
savent pas eviter de swaper et pour faire des notes pdf à partir de LaTeX
pour que les vieux sous windows ne puissent pas repomper texto ce que je
fais). On envisage de généraliser l'experience à quelques autres pcs.
La question que je me pose c'est : est-ce que le choix de la distribution
peut impacter sur les perfos ? Mon interpretation est que la distribution
n'est qu'une série d'outils de config userfriendly plus une maniere de gerer
des packages plus des packages plus ou moins recents. Je me demande si une
mandrake avec un noyau 2.6 et une debian avec un noyau 2.6 auront les
memes performances par example pour traiter des fichiers binaires et faire
des transformées de Fourier (pour faire simple). Si quelqu'un peut
eclairer ma lanterne...
C'est clair que l'optimisation dépend clairement des applications que l'on utilise. En ce qui me concerne, j'ai fait quelques tests entre un windows et une debian (2.4.21 compilé au mieux) avec Matlab, octave et scilab. Les pertes en temps de calcul sous windows sont violentes des que j'utilise la mémoire virtuelle. Par contre, elles sont plus minimes si on évite d'utiliser la mémoire virtuelle (pas tout le temps facile ;p)
Un autre soucis : Je travaille avec un outil dont je tairais le nom qui fonctionne sous solaris et qui est en train d être porté sous linux. L'executable ne fonctionne pas avec une debian et un noyau 2.4.21 car il a été compilé sur une red hat avec un noyau 2.4.18. A vos avis, est-ce que le pb est du à la distribution ou au noyau ?
Le Tue, 22 Jul 2003 18:27:42 +0200, Non Compos Mentis a écrit :
Bonjour,
J'ai decouvert linuske et les plaisirs de l'installation de debian il y a quelques mois. Au final, ca marche pas mal, j'ai fait quelques essais au taff et c'est assez prometteur (pour de la simulation avec des stagiaires qui ne savent pas eviter de swaper et pour faire des notes pdf à partir de LaTeX pour que les vieux sous windows ne puissent pas repomper texto ce que je fais). On envisage de généraliser l'experience à quelques autres pcs.
La question que je me pose c'est : est-ce que le choix de la distribution peut impacter sur les perfos ? Mon interpretation est que la distribution n'est qu'une série d'outils de config userfriendly plus une maniere de gerer des packages plus des packages plus ou moins recents. Je me demande si une mandrake avec un noyau 2.6 et une debian avec un noyau 2.6 auront les memes performances par example pour traiter des fichiers binaires et faire des transformées de Fourier (pour faire simple). Si quelqu'un peut eclairer ma lanterne...
Merci F
Patrice Karatchentzeff
Non Compos Mentis writes:
Merci pour toutes vos réponses.
Merci de poster et répondre à l'endroit...
C'est clair que l'optimisation dépend clairement des applications que l'on utilise. En ce qui me concerne, j'ai fait quelques tests entre un windows et une debian (2.4.21 compilé au mieux) avec Matlab, octave et scilab. Les pertes en temps de calcul sous windows sont violentes des que j'utilise la mémoire virtuelle. Par contre, elles sont plus minimes si on évite d'utiliser la mémoire virtuelle (pas tout le temps facile ;p)
C'est normal : les accès disques ont un ordre de grandeur (au moins) de retard sur les accès mémoire... Le swap n'est à utiliser qu'exceptionnellement : si l'on y fait appel tout le temps, les perfs s'écroulent... La machine est alors clairement sous-dimensionnée.
Un autre soucis : Je travaille avec un outil dont je tairais le nom qui fonctionne sous solaris et qui est en train d être porté sous linux. L'executable ne fonctionne pas avec une debian et un noyau 2.4.21 car il a été compilé sur une red hat avec un noyau 2.4.18. A vos avis, est-ce que le pb est du à la distribution ou au noyau ?
Que fait ton outil ? S'il a besoin d'accéder à un périphérique, il est possible que le noyau puisse jouer... Sinon, c'est une question de version de libc ou de compilo.
Non Compos Mentis <fredericcornet@nospam.wanadoo.fr> writes:
Merci pour toutes vos réponses.
Merci de poster et répondre à l'endroit...
C'est clair que l'optimisation dépend clairement des applications
que l'on utilise. En ce qui me concerne, j'ai fait quelques tests
entre un windows et une debian (2.4.21 compilé au mieux) avec
Matlab, octave et scilab. Les pertes en temps de calcul sous windows
sont violentes des que j'utilise la mémoire virtuelle. Par contre,
elles sont plus minimes si on évite d'utiliser la mémoire virtuelle
(pas tout le temps facile ;p)
C'est normal : les accès disques ont un ordre de grandeur (au moins)
de retard sur les accès mémoire... Le swap n'est à utiliser
qu'exceptionnellement : si l'on y fait appel tout le temps, les perfs
s'écroulent... La machine est alors clairement sous-dimensionnée.
Un autre soucis : Je travaille avec un outil dont je tairais le nom qui
fonctionne sous solaris et qui est en train d être porté sous linux.
L'executable ne fonctionne pas avec une debian et un noyau 2.4.21 car il a
été compilé sur une red hat avec un noyau 2.4.18. A vos avis, est-ce que
le pb est du à la distribution ou au noyau ?
Que fait ton outil ? S'il a besoin d'accéder à un périphérique, il est
possible que le noyau puisse jouer... Sinon, c'est une question de
version de libc ou de compilo.
C'est clair que l'optimisation dépend clairement des applications que l'on utilise. En ce qui me concerne, j'ai fait quelques tests entre un windows et une debian (2.4.21 compilé au mieux) avec Matlab, octave et scilab. Les pertes en temps de calcul sous windows sont violentes des que j'utilise la mémoire virtuelle. Par contre, elles sont plus minimes si on évite d'utiliser la mémoire virtuelle (pas tout le temps facile ;p)
C'est normal : les accès disques ont un ordre de grandeur (au moins) de retard sur les accès mémoire... Le swap n'est à utiliser qu'exceptionnellement : si l'on y fait appel tout le temps, les perfs s'écroulent... La machine est alors clairement sous-dimensionnée.
Un autre soucis : Je travaille avec un outil dont je tairais le nom qui fonctionne sous solaris et qui est en train d être porté sous linux. L'executable ne fonctionne pas avec une debian et un noyau 2.4.21 car il a été compilé sur une red hat avec un noyau 2.4.18. A vos avis, est-ce que le pb est du à la distribution ou au noyau ?
Que fait ton outil ? S'il a besoin d'accéder à un périphérique, il est possible que le noyau puisse jouer... Sinon, c'est une question de version de libc ou de compilo.
