Je suis un utilisateur très satisfait de Linux mais le seul truc qui me
dérange un peu est l'apparente lenteur de Linux par-rapport à Windows.
Je m'explique avant que l'on ne me tape dessus : dans une utilisation
desktop, je trouve que Linux est plus lent que Windows.
Bien que n'étant pas fan de KDE, j'ai installé la version 3.2 par apt-
get depuis kde.org et ce gestionnaire de fenêtres met facilement une
vingtaine de secondes à se lancer sur mon PC qui n'est pas forcément une
vieille croûte (XP1800, 512 DDR, GF4, Barracuda IV 7200 tours etc).
Bon, admettons que le problème du Window manager soit réglé en
installant une interface poids plume du genre Fluxbox, il reste le
problème des grosses applications : Mozilla est plus lent à charger
qu'Internet Explorer et ne parlons pas d'OpenOffice. Une calamité niveau
temps de lancement comparé à Word ou Excel.
On peut bien sûr argumenter en mettant en avant la propension de Windows
à charger au démarrage en mémoire les applications du genre IE ou Office
mais j'ai un autre exemple de lenteur :
quand je fais un $cp /cdrom/image.iso ~/
(fichier de 700 Mo), ce dernier met 2 minutes à arriver dans mon home
alors que pour copier le même gros fichier sous Windows, ça met 40
secondes. Et pourtant, hdparm marche bien :
xp:~# hdparm -Tt /dev/hda
/dev/hda:
Timing buffer-cache reads: 128 MB in 0.50 seconds =256.00 MB/sec
Timing buffered disk reads: 64 MB in 1.81 seconds = 35.36 MB/sec
xp:~# hdparm -d /dev/hda
/dev/hda:
using_dma = 1 (on)
et je n'ai pas 300.000 services lancés au démarrage, juste le strict
nécessaire et mon noyau n'est pas énorme :
Je sais pas, j'ai plus d'origin 200. En attendant il ne fait aucun doute qu'un Origin 350 avec 2 CPU 600Mhz mange 4 Xeon à 2.4Ghz pour son déjeuner, en tant que serveur.
Tres franchement, j'aurais tendance a etre d'accord avec toi, mais j'ai l'impression que c'est plus affaire d'impressions et de legendes que de faits techniques.
En serveur de quoi ?
Bref, j'aimerais bien avoir les deux machines sous la main pour pouvoir me convaincre que ce que tu dis est vrai, mais tres franchement, j'ai quand meme des doutes.
-- Stephane TOUGARD
Unix et programmation - http://www.unices.org Stations Unix en occasions. - http://yellow.epernon.net
Emmanuel Florac wrote:
Je sais pas, j'ai plus d'origin 200. En attendant il ne fait aucun doute
qu'un Origin 350 avec 2 CPU 600Mhz mange 4 Xeon à 2.4Ghz pour son
déjeuner, en tant que serveur.
Tres franchement, j'aurais tendance a etre d'accord avec toi, mais j'ai
l'impression que c'est plus affaire d'impressions et de legendes que de
faits techniques.
En serveur de quoi ?
Bref, j'aimerais bien avoir les deux machines sous la main pour pouvoir
me convaincre que ce que tu dis est vrai, mais tres franchement, j'ai
quand meme des doutes.
--
Stephane TOUGARD
Unix et programmation - http://www.unices.org
Stations Unix en occasions. - http://yellow.epernon.net
Je sais pas, j'ai plus d'origin 200. En attendant il ne fait aucun doute qu'un Origin 350 avec 2 CPU 600Mhz mange 4 Xeon à 2.4Ghz pour son déjeuner, en tant que serveur.
Tres franchement, j'aurais tendance a etre d'accord avec toi, mais j'ai l'impression que c'est plus affaire d'impressions et de legendes que de faits techniques.
En serveur de quoi ?
Bref, j'aimerais bien avoir les deux machines sous la main pour pouvoir me convaincre que ce que tu dis est vrai, mais tres franchement, j'ai quand meme des doutes.
-- Stephane TOUGARD
Unix et programmation - http://www.unices.org Stations Unix en occasions. - http://yellow.epernon.net
Emmanuel Florac
Dans article , disait...
Tres franchement, j'aurais tendance a etre d'accord avec toi, mais j'ai l'impression que c'est plus affaire d'impressions et de legendes que de faits techniques.
Ben non, c'est par rapport à mes expériences antérieurs avec les machines de génération précédente.
En serveur de quoi ?
Tout ce qui demande de l'I/O plus que du CPU : serveur de fichiers en particulier. Aussi on voit la résistance à la charge : avec une charge de 2.5, mes PC sont inutilisables (genre impossible d'ouvrir une connexion ssh), alors qu'une SGI -même une Indy à 100Mhz- reste raisonnablement réactive avec une charge au-delà de 10.
-- Quis, quid, ubi, quibus auxiliis, cur, quomodo, quando?
Dans article <slrnbkbbl1.chq.stephane@goliath.kirch>, stephane@unices.org
disait...
Tres franchement, j'aurais tendance a etre d'accord avec toi, mais j'ai
l'impression que c'est plus affaire d'impressions et de legendes que de
faits techniques.
Ben non, c'est par rapport à mes expériences antérieurs avec les machines
de génération précédente.
En serveur de quoi ?
Tout ce qui demande de l'I/O plus que du CPU : serveur de fichiers en
particulier. Aussi on voit la résistance à la charge : avec une charge de
2.5, mes PC sont inutilisables (genre impossible d'ouvrir une connexion
ssh), alors qu'une SGI -même une Indy à 100Mhz- reste raisonnablement
réactive avec une charge au-delà de 10.
--
Quis, quid, ubi, quibus auxiliis, cur, quomodo, quando?
Tres franchement, j'aurais tendance a etre d'accord avec toi, mais j'ai l'impression que c'est plus affaire d'impressions et de legendes que de faits techniques.
Ben non, c'est par rapport à mes expériences antérieurs avec les machines de génération précédente.
En serveur de quoi ?
Tout ce qui demande de l'I/O plus que du CPU : serveur de fichiers en particulier. Aussi on voit la résistance à la charge : avec une charge de 2.5, mes PC sont inutilisables (genre impossible d'ouvrir une connexion ssh), alors qu'une SGI -même une Indy à 100Mhz- reste raisonnablement réactive avec une charge au-delà de 10.
-- Quis, quid, ubi, quibus auxiliis, cur, quomodo, quando?
Gilles Berger Sabbatel
On Thu, 21 Aug 2003 13:05:36 +0200, Emmanuel Florac wrote:
Parce qu'à l'usage, un Origin 200 à 195 Mhz sert plus de fichiers qu'un PIII Xeon à 700Mhz. Après je n'ai pas creusé considérablement la question. Cependant il est vrai que la même chose se vérifie également en comparant un Mac G4 450Mhz contre le même Xeon 700. C'est peut-être simplement que le PC c'est vraiment trop de la daube, en fait.
C'est surtout que la fréquence d'horloge n'est pas forcément un bon indice de permformance : une machine avec une fréquence d'horloge 2 fois plus élevée qu'une autre sera quand même moins rapide si elle fait 3 fois moins de travail par cycle.
C'est une chose que tous ceux qui connaissent un peu l'architecture des processeurs savent depuis longtemps, et qu'on peut effectivement vérifier en comparant les perfs d'un Mac et d'un PC de même génération.
Dans le monde PC, la fréquence d'horloge est un mythe qui a la vie dure. AMD a commencé à le remettre en cause en produisant des processeurs de fréquence inférieure aux Pentiums pour des perfs équivallentes. Et Intel y vient aussi avec le Pentium M, qui offre les mêmes perfs qu'un Pentium IV de fréquence d'horloge très supérieure!
On Thu, 21 Aug 2003 13:05:36 +0200, Emmanuel Florac wrote:
Parce qu'à l'usage, un Origin 200 à 195 Mhz sert plus de fichiers qu'un
PIII Xeon à 700Mhz. Après je n'ai pas creusé considérablement la
question. Cependant il est vrai que la même chose se vérifie également
en comparant un Mac G4 450Mhz contre le même Xeon 700. C'est peut-être
simplement que le PC c'est vraiment trop de la daube, en fait.
C'est surtout que la fréquence d'horloge n'est pas forcément un bon indice
de permformance : une machine avec une fréquence d'horloge 2 fois plus
élevée qu'une autre sera quand même moins rapide si elle fait 3 fois moins
de travail par cycle.
C'est une chose que tous ceux qui connaissent un peu l'architecture des
processeurs savent depuis longtemps, et qu'on peut effectivement vérifier
en comparant les perfs d'un Mac et d'un PC de même génération.
Dans le monde PC, la fréquence d'horloge est un mythe qui a la vie dure.
AMD a commencé à le remettre en cause en produisant des processeurs de
fréquence inférieure aux Pentiums pour des perfs équivallentes. Et Intel
y vient aussi avec le Pentium M, qui offre les mêmes perfs qu'un Pentium
IV de fréquence d'horloge très supérieure!
On Thu, 21 Aug 2003 13:05:36 +0200, Emmanuel Florac wrote:
Parce qu'à l'usage, un Origin 200 à 195 Mhz sert plus de fichiers qu'un PIII Xeon à 700Mhz. Après je n'ai pas creusé considérablement la question. Cependant il est vrai que la même chose se vérifie également en comparant un Mac G4 450Mhz contre le même Xeon 700. C'est peut-être simplement que le PC c'est vraiment trop de la daube, en fait.
C'est surtout que la fréquence d'horloge n'est pas forcément un bon indice de permformance : une machine avec une fréquence d'horloge 2 fois plus élevée qu'une autre sera quand même moins rapide si elle fait 3 fois moins de travail par cycle.
C'est une chose que tous ceux qui connaissent un peu l'architecture des processeurs savent depuis longtemps, et qu'on peut effectivement vérifier en comparant les perfs d'un Mac et d'un PC de même génération.
Dans le monde PC, la fréquence d'horloge est un mythe qui a la vie dure. AMD a commencé à le remettre en cause en produisant des processeurs de fréquence inférieure aux Pentiums pour des perfs équivallentes. Et Intel y vient aussi avec le Pentium M, qui offre les mêmes perfs qu'un Pentium IV de fréquence d'horloge très supérieure!
Patrice Karatchentzeff
Stephane TOUGARD writes:
Patrice Karatchentzeff wrote:
J'ai un soft assez consequent (300 Ko) en Perl/Tk, celui la est plus
Que du code ? Il fait quoi ce soft ?
Interface d'un logiciel de billing pour un petit operateur telephonique. Juste l'interface, le logiciel de billing est ecrit en PL/PgSQL sous PostgreSQL.
Tu codes directement ou tu passes par un trucs WYSIWIG ? Juste par curiosité, je jetterai bien un coup d'oeil au code... Tu as des captures d'écran par hasard ?
J'ai un soft assez consequent (300 Ko) en Perl/Tk, celui la est plus
Que du code ? Il fait quoi ce soft ?
Interface d'un logiciel de billing pour un petit operateur telephonique.
Juste l'interface, le logiciel de billing est ecrit en PL/PgSQL sous
PostgreSQL.
Tu codes directement ou tu passes par un trucs WYSIWIG ? Juste par
curiosité, je jetterai bien un coup d'oeil au code... Tu as des
captures d'écran par hasard ?
J'ai un soft assez consequent (300 Ko) en Perl/Tk, celui la est plus
Que du code ? Il fait quoi ce soft ?
Interface d'un logiciel de billing pour un petit operateur telephonique. Juste l'interface, le logiciel de billing est ecrit en PL/PgSQL sous PostgreSQL.
Tu codes directement ou tu passes par un trucs WYSIWIG ? Juste par curiosité, je jetterai bien un coup d'oeil au code... Tu as des captures d'écran par hasard ?
C'est surtout que la fréquence d'horloge n'est pas forcément un bon indice de permformance : une machine avec une fréquence d'horloge 2 fois plus élevée qu'une autre sera quand même moins rapide si elle fait 3 fois moins de travail par cycle.
Oui, oui, je sais. D'ailleurs un P4 à 1.5Ghz se fait systématiquement rétamer par un PIII 1Ghz ou presque.
-- Quis, quid, ubi, quibus auxiliis, cur, quomodo, quando?
Dans article <pan.2003.08.22.09.23.27.533867@imag.fr>, Gilles.Berger-
Sabbatel@imag.fr disait...
C'est surtout que la fréquence d'horloge n'est pas forcément un bon indice
de permformance : une machine avec une fréquence d'horloge 2 fois plus
élevée qu'une autre sera quand même moins rapide si elle fait 3 fois moins
de travail par cycle.
Oui, oui, je sais. D'ailleurs un P4 à 1.5Ghz se fait systématiquement
rétamer par un PIII 1Ghz ou presque.
--
Quis, quid, ubi, quibus auxiliis, cur, quomodo, quando?
C'est surtout que la fréquence d'horloge n'est pas forcément un bon indice de permformance : une machine avec une fréquence d'horloge 2 fois plus élevée qu'une autre sera quand même moins rapide si elle fait 3 fois moins de travail par cycle.
Oui, oui, je sais. D'ailleurs un P4 à 1.5Ghz se fait systématiquement rétamer par un PIII 1Ghz ou presque.
-- Quis, quid, ubi, quibus auxiliis, cur, quomodo, quando?
talon
azathoth wrote:
In article (Dans l'article) <loict+, Loic Tortay <loict+ wrote (écrivait) :
La je demande à voir sur quels tests.
Là <http://www.beowulf.org/pipermail/beowulf/2003-July/007384.html>, par
exemple, quelqu'un compare la capacité de « scalabilité » de machines bi-pro à base de P4 (à 3 GHz) et d'Opteron (à 1.4 GHz).
Ici <http://mpc.uci.edu/opteron.html>, il y a un test différent et plus détaillé avec plusieurs processeurs (dont l'Opteron 240 à 1.4 GHz).
Ce qui est dommage c'est qu'on ne voit pas bien la quantité de ram sur chaque machine. A priori je dirais qu'un processeur 64 bits commence à vraiment éclater tout le monde lorsqu'il y a plus de 4 Go à adresser.
A priori les Opteron sont livrés avec un gig de ram par processeur. C'est une des particularités de l'Opteron que la ram est attachée au processeur avec un contrôleur mémoire directement dans le proc. Les processeurs sont liés entre eux par un bus trés rapide (Hyper...) et quand on veut accéder à la mémoire d'un autre proc seulement doit on passer par ce bus. C'est paraît il cette architecture originale qui fait qu'un biproc opteron a presque deux fois les perfs d'un monoproc alors que c'est loin d'être le cas avec l'architecture classique.
L'autre intérêt est que tout de suite maintenant, les Opteron sont moins chers à l'achat que les P4 ou Xeon de performances similaires (ou inférieures).
Oui mais faut voir le prix des 4Go de ram qui vont très bien avec :-)
-- Michel Talon
azathoth <azathoth@alussinan.org> wrote:
In article (Dans l'article)
<loict+usenet.1061543712.f@beuark.bougon.net>, Loic Tortay
<loict+usenet@bougon.net> wrote (écrivait) :
La je demande à voir sur quels tests.
Là <http://www.beowulf.org/pipermail/beowulf/2003-July/007384.html>, par
exemple, quelqu'un compare la capacité de « scalabilité » de machines bi-pro
à base de P4 (à 3 GHz) et d'Opteron (à 1.4 GHz).
Ici <http://mpc.uci.edu/opteron.html>, il y a un test différent et plus
détaillé avec plusieurs processeurs (dont l'Opteron 240 à 1.4 GHz).
Ce qui est dommage c'est qu'on ne voit pas bien la quantité de ram sur
chaque machine. A priori je dirais qu'un processeur 64 bits commence à
vraiment éclater tout le monde lorsqu'il y a plus de 4 Go à adresser.
A priori les Opteron sont livrés avec un gig de ram par processeur. C'est
une des particularités de l'Opteron que la ram est attachée au processeur
avec un contrôleur mémoire directement dans le proc. Les processeurs sont
liés entre eux par un bus trés rapide (Hyper...) et quand on veut accéder
à la mémoire d'un autre proc seulement doit on passer par ce bus. C'est paraît
il cette architecture originale qui fait qu'un biproc opteron a presque deux
fois les perfs d'un monoproc alors que c'est loin d'être le cas avec
l'architecture classique.
L'autre intérêt est que tout de suite maintenant, les Opteron sont moins
chers à l'achat que les P4 ou Xeon de performances similaires (ou
inférieures).
Oui mais faut voir le prix des 4Go de ram qui vont très bien avec :-)
In article (Dans l'article) <loict+, Loic Tortay <loict+ wrote (écrivait) :
La je demande à voir sur quels tests.
Là <http://www.beowulf.org/pipermail/beowulf/2003-July/007384.html>, par
exemple, quelqu'un compare la capacité de « scalabilité » de machines bi-pro à base de P4 (à 3 GHz) et d'Opteron (à 1.4 GHz).
Ici <http://mpc.uci.edu/opteron.html>, il y a un test différent et plus détaillé avec plusieurs processeurs (dont l'Opteron 240 à 1.4 GHz).
Ce qui est dommage c'est qu'on ne voit pas bien la quantité de ram sur chaque machine. A priori je dirais qu'un processeur 64 bits commence à vraiment éclater tout le monde lorsqu'il y a plus de 4 Go à adresser.
A priori les Opteron sont livrés avec un gig de ram par processeur. C'est une des particularités de l'Opteron que la ram est attachée au processeur avec un contrôleur mémoire directement dans le proc. Les processeurs sont liés entre eux par un bus trés rapide (Hyper...) et quand on veut accéder à la mémoire d'un autre proc seulement doit on passer par ce bus. C'est paraît il cette architecture originale qui fait qu'un biproc opteron a presque deux fois les perfs d'un monoproc alors que c'est loin d'être le cas avec l'architecture classique.
L'autre intérêt est que tout de suite maintenant, les Opteron sont moins chers à l'achat que les P4 ou Xeon de performances similaires (ou inférieures).
Oui mais faut voir le prix des 4Go de ram qui vont très bien avec :-)
-- Michel Talon
Stephane TOUGARD
Emmanuel Florac wrote:
Tout ce qui demande de l'I/O plus que du CPU : serveur de fichiers en particulier. Aussi on voit la résistance à la charge : avec une charge de 2.5, mes PC sont inutilisables (genre impossible d'ouvrir une connexion ssh), alors qu'une SGI -même une Indy à 100Mhz- reste raisonnablement réactive avec une charge au-delà de 10.
J'ai quelques PC IBM NetFinity, avec des cartes RaidServer et des disques assez costaud. Tu penses pas que ces machines ont une archi capable de rivaliser avec des station SGI/SUN/...
-- Stephane TOUGARD
Unix et programmation - http://www.unices.org Stations Unix en occasions. - http://yellow.epernon.net
Emmanuel Florac wrote:
Tout ce qui demande de l'I/O plus que du CPU : serveur de fichiers en
particulier. Aussi on voit la résistance à la charge : avec une charge de
2.5, mes PC sont inutilisables (genre impossible d'ouvrir une connexion
ssh), alors qu'une SGI -même une Indy à 100Mhz- reste raisonnablement
réactive avec une charge au-delà de 10.
J'ai quelques PC IBM NetFinity, avec des cartes RaidServer et des
disques assez costaud. Tu penses pas que ces machines ont une archi
capable de rivaliser avec des station SGI/SUN/...
--
Stephane TOUGARD
Unix et programmation - http://www.unices.org
Stations Unix en occasions. - http://yellow.epernon.net
Tout ce qui demande de l'I/O plus que du CPU : serveur de fichiers en particulier. Aussi on voit la résistance à la charge : avec une charge de 2.5, mes PC sont inutilisables (genre impossible d'ouvrir une connexion ssh), alors qu'une SGI -même une Indy à 100Mhz- reste raisonnablement réactive avec une charge au-delà de 10.
J'ai quelques PC IBM NetFinity, avec des cartes RaidServer et des disques assez costaud. Tu penses pas que ces machines ont une archi capable de rivaliser avec des station SGI/SUN/...
-- Stephane TOUGARD
Unix et programmation - http://www.unices.org Stations Unix en occasions. - http://yellow.epernon.net
Emmanuel Florac
Dans article <220820032020435075%, disait...
Tu utilises linux sur les deux bécane ?
Ah ben non, je vais pas utiliser Linux sur une SGI, c'est de la folie.
-- Quis, quid, ubi, quibus auxiliis, cur, quomodo, quando?
Dans article <220820032020435075%azathoth@alussinan.org>,
azathoth@alussinan.org disait...
Tu utilises linux sur les deux bécane ?
Ah ben non, je vais pas utiliser Linux sur une SGI, c'est de la folie.
--
Quis, quid, ubi, quibus auxiliis, cur, quomodo, quando?
Ah ben non, je vais pas utiliser Linux sur une SGI, c'est de la folie.
-- Quis, quid, ubi, quibus auxiliis, cur, quomodo, quando?
Stephane TOUGARD
Patrice Karatchentzeff wrote:
Tu codes directement ou tu passes par un trucs WYSIWIG ? Juste par curiosité, je jetterai bien un coup d'oeil au code... Tu as des captures d'écran par hasard ?
Je code via une interface qui se nomme ViM et qui me permet d'utiliser les 104 touches de mon clavier pour faire apparaitre des lettres qui forment du code.
Si tu veux un exemple de code dont je suis l'auteur, je ne peux pas t'en passer de cette application qui est un developement a destination d'un client et meme si je suis l'unique proprietaire du code tant intellectuellement qu'en exploitation, je suis lie a ce client et il en est pour le moment le seul beneficiaire. Par contre, tu trouveras sur mon site dbspool, un middleware transactionnel asynchrone local. Je suis a l'origine de 100% du code et j'ai utilise la meme interface de programmation (ViM).
-- Stephane TOUGARD
Unix et programmation - http://www.unices.org Stations Unix en occasions. - http://yellow.epernon.net
Patrice Karatchentzeff wrote:
Tu codes directement ou tu passes par un trucs WYSIWIG ? Juste par
curiosité, je jetterai bien un coup d'oeil au code... Tu as des
captures d'écran par hasard ?
Je code via une interface qui se nomme ViM et qui me permet d'utiliser
les 104 touches de mon clavier pour faire apparaitre des lettres qui
forment du code.
Si tu veux un exemple de code dont je suis l'auteur, je ne peux pas t'en
passer de cette application qui est un developement a destination d'un
client et meme si je suis l'unique proprietaire du code tant
intellectuellement qu'en exploitation, je suis lie a ce client et il en
est pour le moment le seul beneficiaire. Par contre, tu trouveras sur
mon site dbspool, un middleware transactionnel asynchrone local. Je suis
a l'origine de 100% du code et j'ai utilise la meme interface de
programmation (ViM).
--
Stephane TOUGARD
Unix et programmation - http://www.unices.org
Stations Unix en occasions. - http://yellow.epernon.net
Tu codes directement ou tu passes par un trucs WYSIWIG ? Juste par curiosité, je jetterai bien un coup d'oeil au code... Tu as des captures d'écran par hasard ?
Je code via une interface qui se nomme ViM et qui me permet d'utiliser les 104 touches de mon clavier pour faire apparaitre des lettres qui forment du code.
Si tu veux un exemple de code dont je suis l'auteur, je ne peux pas t'en passer de cette application qui est un developement a destination d'un client et meme si je suis l'unique proprietaire du code tant intellectuellement qu'en exploitation, je suis lie a ce client et il en est pour le moment le seul beneficiaire. Par contre, tu trouveras sur mon site dbspool, un middleware transactionnel asynchrone local. Je suis a l'origine de 100% du code et j'ai utilise la meme interface de programmation (ViM).
-- Stephane TOUGARD
Unix et programmation - http://www.unices.org Stations Unix en occasions. - http://yellow.epernon.net
Manuel Leclerc
[...] je suis lie a ce client et il en est pour le moment le seul beneficiaire.
Blablabla, Blablabla.
manuel leclerc
[...] je suis lie a ce client et il en est pour le
moment le seul beneficiaire.
