je compare actuellement certaines performances CPU et IO sur plusieurs
plate forme Unix et linux.
J'ai été surpris de voir qu'une commande donnait une architecture PC
classique linux largement vainqueur face à une architecture "tres high
tech" coté Sun.
Dans le message <news:4381d477$0$19705$, *bill* tapota sur f.c.o.l.configuration :
Bonjour,
Bonjour,
je compare actuellement certaines performances CPU et IO sur plusieurs plate forme Unix et linux.
[...]
Pourriez vous me donner d autres commandes non spécifiques linux qui permettrait de faire des comparaison CPU linux/Unix (egalement IO) ?
Une qui me vient à l'esprit :
$ openssl speed
man speed
Mais faut-il aussi que le binaire de openssl ait été compilé avec les bonnes optimisations correspondant à l'architecture du CPU.
Merci bcp.
Pas de quoi.
-- TiChou
Miguel Moquillon
bill wrote:
Bonjour,
je compare actuellement certaines performances CPU et IO sur plusieurs plate forme Unix et linux.
J'ai été surpris de voir qu'une commande donnait une architecture PC classique linux largement vainqueur face à une architecture "tres high tech" coté Sun. Sans vouloir lancé de troll, les machines Sun et plus particulièrement leurs
processeurs SPARC ne sont 'high tech' que dans le discour marketing et dans le prix du matos. Les SPARC ont toujours été les pires processeurs RISC et sont même en deçà des perfs globaux que peux délivrer un processeur CISC Intel. Et ceci n'a rien à voir avec la différence de fréquences délivrées par ceux-ci.
Miguel
bill wrote:
Bonjour,
je compare actuellement certaines performances CPU et IO sur plusieurs
plate forme Unix et linux.
J'ai été surpris de voir qu'une commande donnait une architecture PC
classique linux largement vainqueur face à une architecture "tres high
tech" coté Sun.
Sans vouloir lancé de troll, les machines Sun et plus particulièrement leurs
processeurs SPARC ne sont 'high tech' que dans le discour marketing et dans
le prix du matos. Les SPARC ont toujours été les pires processeurs RISC et
sont même en deçà des perfs globaux que peux délivrer un processeur CISC
Intel. Et ceci n'a rien à voir avec la différence de fréquences délivrées
par ceux-ci.
je compare actuellement certaines performances CPU et IO sur plusieurs plate forme Unix et linux.
J'ai été surpris de voir qu'une commande donnait une architecture PC classique linux largement vainqueur face à une architecture "tres high tech" coté Sun. Sans vouloir lancé de troll, les machines Sun et plus particulièrement leurs
processeurs SPARC ne sont 'high tech' que dans le discour marketing et dans le prix du matos. Les SPARC ont toujours été les pires processeurs RISC et sont même en deçà des perfs globaux que peux délivrer un processeur CISC Intel. Et ceci n'a rien à voir avec la différence de fréquences délivrées par ceux-ci.
Miguel
Nicolas George
"TiChou" wrote in message :
$ openssl speed
Je soupçonne que l'OS va très peu influer sur la vitesse indiquée par ce test.
"TiChou" wrote in message <gniii.20051121153140@florizarre.tichou.org>:
$ openssl speed
Je soupçonne que l'OS va très peu influer sur la vitesse indiquée par ce
test.
Je soupçonne que l'OS va très peu influer sur la vitesse indiquée par ce test.
TiChou
Dans le message <news:dlsn6j$28vd$, *Nicolas George* tapota sur f.c.o.l.configuration :
$ openssl speed
Je soupçonne que l'OS va très peu influer sur la vitesse indiquée par ce test.
Mais si j'ai bien compris l'OP, c'est la différence entres architectures qui est recherchée, non ? Donc si l'OS influe peu sur ce test, c'est encore mieux ?
-- TiChou
Dans le message <news:dlsn6j$28vd$1@biggoron.nerim.net>,
*Nicolas George* tapota sur f.c.o.l.configuration :
$ openssl speed
Je soupçonne que l'OS va très peu influer sur la vitesse indiquée par ce
test.
Mais si j'ai bien compris l'OP, c'est la différence entres architectures qui
est recherchée, non ? Donc si l'OS influe peu sur ce test, c'est encore
mieux ?
Dans le message <news:dlsn6j$28vd$, *Nicolas George* tapota sur f.c.o.l.configuration :
$ openssl speed
Je soupçonne que l'OS va très peu influer sur la vitesse indiquée par ce test.
Mais si j'ai bien compris l'OP, c'est la différence entres architectures qui est recherchée, non ? Donc si l'OS influe peu sur ce test, c'est encore mieux ?
-- TiChou
bill
TiChou wrote:
$ openssl speed
Je soupçonne que l'OS va très peu influer sur la vitesse indiquée par ce test.
Mais si j'ai bien compris l'OP, c'est la différence entres architectures qui est recherchée, non ? Donc si l'OS influe peu sur ce test, c'est encore mieux ?
Disons que je recherche les 2 en fait. Cet apport est donc tres utile.
J avoue etre vraiment bluffé par les perf bien meilleures d'une architecture standard sous linux (P4 3 GHz ) face à un Unix propriétaire avec 12 processeurs (750 Mhz je crois) , 16 Go de RAM, Fibre optique et tout le blabla etc..
TiChou wrote:
$ openssl speed
Je soupçonne que l'OS va très peu influer sur la vitesse indiquée par ce
test.
Mais si j'ai bien compris l'OP, c'est la différence entres architectures
qui est recherchée, non ? Donc si l'OS influe peu sur ce test, c'est
encore mieux ?
Disons que je recherche les 2 en fait.
Cet apport est donc tres utile.
J avoue etre vraiment bluffé par les perf bien meilleures d'une
architecture standard sous linux (P4 3 GHz ) face à un Unix propriétaire
avec 12 processeurs (750 Mhz je crois) , 16 Go de RAM, Fibre optique
et tout le blabla etc..
Je soupçonne que l'OS va très peu influer sur la vitesse indiquée par ce test.
Mais si j'ai bien compris l'OP, c'est la différence entres architectures qui est recherchée, non ? Donc si l'OS influe peu sur ce test, c'est encore mieux ?
Disons que je recherche les 2 en fait. Cet apport est donc tres utile.
J avoue etre vraiment bluffé par les perf bien meilleures d'une architecture standard sous linux (P4 3 GHz ) face à un Unix propriétaire avec 12 processeurs (750 Mhz je crois) , 16 Go de RAM, Fibre optique et tout le blabla etc..
lhabert
bill :
J avoue etre vraiment bluffé par les perf bien meilleures d'une architecture standard sous linux (P4 3 GHz ) face à un Unix propriétaire avec 12 processeurs (750 Mhz je crois) , 16 Go de RAM, Fibre optique et tout le blabla etc..
Disclaimer : j'ai pas vraiment d'expérience de ces trucs là, je ne fais que faire des observations « de bon sens ».
La commande que tu indiquais n'a que faire de 12 CPUs : elle a besoin d'un CPU pour générer les 0 et exécuter la commande dd, et un deuxième pour exécuter le gzip. Donc au-delà de deux CPUs, tu ne dois pas gagner grand chose (et encore, l'un des deux CPUs doit être pratiquement inutilisé vu la trivialité de la tache qu'il exécute). Donc pour ce test précis, c'est la fréquence du CPU qui compte, pas le nombre de CPUs, et le PC va être nettement plus rapide.
Maintenant, imagine que tu as un millier d'utilisateurs sur la machine, tu vas en avoir au moins une cinquantaine connectés en permanence pour lire leur mail toutes les 5 minutes, rajoute par-dessus divers serveurs traitant des requetes en permanence. Bein c'est là que les 12 processeurs et les 16Go de RAM vont faire la différence (en fait, j'espère que la bande passante des DDs est à la hauteur, parce que ça risque d'être le facteur limitant (je connais un biproc sun récent avec 8Go de RAM et une utilisation telle que décrite ci-dessus où ça coince...)), puisqu'ils vont pouvoir tous travailler en même temps, tandis que ton PC va devoir switcher entre des centaines de process en permanence, et il risque même de passer son temps à swapper, et là c'est fini...
Bon, et puis de toutes manières, ton PC, tu lui fait subir ce pour quoi les suns sont conçues pour subir, je suis pas sur qu'il va tenir longtemps...
bill :
J avoue etre vraiment bluffé par les perf bien meilleures d'une
architecture standard sous linux (P4 3 GHz ) face à un Unix propriétaire
avec 12 processeurs (750 Mhz je crois) , 16 Go de RAM, Fibre optique
et tout le blabla etc..
Disclaimer : j'ai pas vraiment d'expérience de ces trucs là, je ne fais que
faire des observations « de bon sens ».
La commande que tu indiquais n'a que faire de 12 CPUs : elle a besoin d'un
CPU pour générer les 0 et exécuter la commande dd, et un deuxième pour
exécuter le gzip. Donc au-delà de deux CPUs, tu ne dois pas gagner grand
chose (et encore, l'un des deux CPUs doit être pratiquement inutilisé vu la
trivialité de la tache qu'il exécute). Donc pour ce test précis, c'est la
fréquence du CPU qui compte, pas le nombre de CPUs, et le PC va être
nettement plus rapide.
Maintenant, imagine que tu as un millier d'utilisateurs sur la machine, tu
vas en avoir au moins une cinquantaine connectés en permanence pour lire
leur mail toutes les 5 minutes, rajoute par-dessus divers serveurs traitant
des requetes en permanence. Bein c'est là que les 12 processeurs et les 16Go
de RAM vont faire la différence (en fait, j'espère que la bande passante des
DDs est à la hauteur, parce que ça risque d'être le facteur limitant (je
connais un biproc sun récent avec 8Go de RAM et une utilisation telle que
décrite ci-dessus où ça coince...)), puisqu'ils vont pouvoir tous
travailler en même temps, tandis que ton PC va devoir switcher entre des
centaines de process en permanence, et il risque même de passer son temps à
swapper, et là c'est fini...
Bon, et puis de toutes manières, ton PC, tu lui fait subir ce pour quoi les
suns sont conçues pour subir, je suis pas sur qu'il va tenir longtemps...
J avoue etre vraiment bluffé par les perf bien meilleures d'une architecture standard sous linux (P4 3 GHz ) face à un Unix propriétaire avec 12 processeurs (750 Mhz je crois) , 16 Go de RAM, Fibre optique et tout le blabla etc..
Disclaimer : j'ai pas vraiment d'expérience de ces trucs là, je ne fais que faire des observations « de bon sens ».
La commande que tu indiquais n'a que faire de 12 CPUs : elle a besoin d'un CPU pour générer les 0 et exécuter la commande dd, et un deuxième pour exécuter le gzip. Donc au-delà de deux CPUs, tu ne dois pas gagner grand chose (et encore, l'un des deux CPUs doit être pratiquement inutilisé vu la trivialité de la tache qu'il exécute). Donc pour ce test précis, c'est la fréquence du CPU qui compte, pas le nombre de CPUs, et le PC va être nettement plus rapide.
Maintenant, imagine que tu as un millier d'utilisateurs sur la machine, tu vas en avoir au moins une cinquantaine connectés en permanence pour lire leur mail toutes les 5 minutes, rajoute par-dessus divers serveurs traitant des requetes en permanence. Bein c'est là que les 12 processeurs et les 16Go de RAM vont faire la différence (en fait, j'espère que la bande passante des DDs est à la hauteur, parce que ça risque d'être le facteur limitant (je connais un biproc sun récent avec 8Go de RAM et une utilisation telle que décrite ci-dessus où ça coince...)), puisqu'ils vont pouvoir tous travailler en même temps, tandis que ton PC va devoir switcher entre des centaines de process en permanence, et il risque même de passer son temps à swapper, et là c'est fini...
Bon, et puis de toutes manières, ton PC, tu lui fait subir ce pour quoi les suns sont conçues pour subir, je suis pas sur qu'il va tenir longtemps...
TiChou
Dans le message <news:dlssp8$2bol$, *Luc Habert* tapota sur f.c.o.l.configuration :
bill :
J avoue etre vraiment bluffé par les perf bien meilleures d'une architecture standard sous linux (P4 3 GHz ) face à un Unix propriétaire avec 12 processeurs (750 Mhz je crois) , 16 Go de RAM, Fibre optique et tout le blabla etc..
La commande que tu indiquais n'a que faire de 12 CPUs : elle a besoin d'un CPU pour générer les 0 et exécuter la commande dd, et un deuxième pour exécuter le gzip. Donc au-delà de deux CPUs, tu ne dois pas gagner grand chose (et encore, l'un des deux CPUs doit être pratiquement inutilisé vu la trivialité de la tache qu'il exécute). Donc pour ce test précis, c'est la fréquence du CPU qui compte, pas le nombre de CPUs, et le PC va être nettement plus rapide.
Un test qui serait plus révélateur en faisant intervenir le nombre de CPU c'est une compilation avec make et son option -j.
-- TiChou
Dans le message <news:dlssp8$2bol$1@nef.ens.fr>,
*Luc Habert* tapota sur f.c.o.l.configuration :
bill :
J avoue etre vraiment bluffé par les perf bien meilleures d'une
architecture standard sous linux (P4 3 GHz ) face à un Unix propriétaire
avec 12 processeurs (750 Mhz je crois) , 16 Go de RAM, Fibre optique
et tout le blabla etc..
La commande que tu indiquais n'a que faire de 12 CPUs : elle a besoin d'un
CPU pour générer les 0 et exécuter la commande dd, et un deuxième pour
exécuter le gzip. Donc au-delà de deux CPUs, tu ne dois pas gagner grand
chose (et encore, l'un des deux CPUs doit être pratiquement inutilisé vu
la trivialité de la tache qu'il exécute). Donc pour ce test précis, c'est
la fréquence du CPU qui compte, pas le nombre de CPUs, et le PC va être
nettement plus rapide.
Un test qui serait plus révélateur en faisant intervenir le nombre de CPU
c'est une compilation avec make et son option -j.
Dans le message <news:dlssp8$2bol$, *Luc Habert* tapota sur f.c.o.l.configuration :
bill :
J avoue etre vraiment bluffé par les perf bien meilleures d'une architecture standard sous linux (P4 3 GHz ) face à un Unix propriétaire avec 12 processeurs (750 Mhz je crois) , 16 Go de RAM, Fibre optique et tout le blabla etc..
La commande que tu indiquais n'a que faire de 12 CPUs : elle a besoin d'un CPU pour générer les 0 et exécuter la commande dd, et un deuxième pour exécuter le gzip. Donc au-delà de deux CPUs, tu ne dois pas gagner grand chose (et encore, l'un des deux CPUs doit être pratiquement inutilisé vu la trivialité de la tache qu'il exécute). Donc pour ce test précis, c'est la fréquence du CPU qui compte, pas le nombre de CPUs, et le PC va être nettement plus rapide.
Un test qui serait plus révélateur en faisant intervenir le nombre de CPU c'est une compilation avec make et son option -j.
-- TiChou
Erwann ABALEA
On Mon, 21 Nov 2005, TiChou wrote:
Dans le message <news:dlssp8$2bol$, *Luc Habert* tapota sur f.c.o.l.configuration :
bill :
J avoue etre vraiment bluffé par les perf bien meilleures d'une architecture standard sous linux (P4 3 GHz ) face à un Unix propriétaire avec 12 processeurs (750 Mhz je crois) , 16 Go de RAM, Fibre optique et tout le blabla etc..
Ca ressemble furieusement à un troll quand même :)
Un test qui serait plus révélateur en faisant intervenir le nombre de CPU c'est une compilation avec make et son option -j.
Ou pour conserver le test OpenSSL, on peut faire:
openssl speed rsa1024 md5 rc4 -multi 12
Et avec ça, on a un aperçu de ce que peut absorber un serveur qui reçoit des connexion SSL en utilisant la combinaison la plus courante (RSA1024 bits, MD5, RC4). Le nombre de signatures RSA indique le nombre d'authentifications par seconde, les 2 autres mesures (RC4 et MD5) indiquent la quantité de données transmises.
Comme souvent, des gros chiffres font plaisir à son ego.
A côté de ça, ce genre de test n'est pas tellement significatif, il faut prendre en compte la fiabilité, les perfs I/O, la stabilité, ... Un serveur avec un CPU très rapide mais qui nécessite une interruption de service de 4h en cas de défaillance matérielle (le temps d'aller au chinois le plus proche et de changer la pièce, par exemple un CPU), c'est pas toujours acceptable pour un service critique. La Sun décrite ci-dessus peut très certainement voir ses cartes CPU désactivées, enlevées, changées, et redémarrées, à chaud, sans reboot, sans arrêt des services. Au pire, on aura un service dégradé en perfs, mais pas d'arrêt.
-- Erwann ABALEA - RSA PGP Key ID: 0x2D0EABD5 ----- Moi je connais pas trop les ng techniquement s'il y a quelqu'un qui s'y connait assez pour m'indiquer une personne qui s'occupe des newsgroups et qui pourrait passer un coup de balai ici... -+- AT in: Guide du Neuneu Usenet - Neuneu comme un balai -+-
On Mon, 21 Nov 2005, TiChou wrote:
Dans le message <news:dlssp8$2bol$1@nef.ens.fr>,
*Luc Habert* tapota sur f.c.o.l.configuration :
bill :
J avoue etre vraiment bluffé par les perf bien meilleures d'une
architecture standard sous linux (P4 3 GHz ) face à un Unix propriétaire
avec 12 processeurs (750 Mhz je crois) , 16 Go de RAM, Fibre optique
et tout le blabla etc..
Ca ressemble furieusement à un troll quand même :)
Un test qui serait plus révélateur en faisant intervenir le nombre de CPU
c'est une compilation avec make et son option -j.
Ou pour conserver le test OpenSSL, on peut faire:
openssl speed rsa1024 md5 rc4 -multi 12
Et avec ça, on a un aperçu de ce que peut absorber un serveur qui reçoit
des connexion SSL en utilisant la combinaison la plus courante (RSA1024
bits, MD5, RC4). Le nombre de signatures RSA indique le nombre
d'authentifications par seconde, les 2 autres mesures (RC4 et MD5)
indiquent la quantité de données transmises.
Comme souvent, des gros chiffres font plaisir à son ego.
A côté de ça, ce genre de test n'est pas tellement significatif, il faut
prendre en compte la fiabilité, les perfs I/O, la stabilité, ... Un
serveur avec un CPU très rapide mais qui nécessite une interruption de
service de 4h en cas de défaillance matérielle (le temps d'aller au
chinois le plus proche et de changer la pièce, par exemple un CPU), c'est
pas toujours acceptable pour un service critique. La Sun décrite ci-dessus
peut très certainement voir ses cartes CPU désactivées, enlevées,
changées, et redémarrées, à chaud, sans reboot, sans arrêt des services.
Au pire, on aura un service dégradé en perfs, mais pas d'arrêt.
--
Erwann ABALEA <erwann@abalea.com> - RSA PGP Key ID: 0x2D0EABD5
-----
Moi je connais pas trop les ng techniquement s'il y a quelqu'un
qui s'y connait assez pour m'indiquer une personne qui s'occupe
des newsgroups et qui pourrait passer un coup de balai ici...
-+- AT in: Guide du Neuneu Usenet - Neuneu comme un balai -+-
Dans le message <news:dlssp8$2bol$, *Luc Habert* tapota sur f.c.o.l.configuration :
bill :
J avoue etre vraiment bluffé par les perf bien meilleures d'une architecture standard sous linux (P4 3 GHz ) face à un Unix propriétaire avec 12 processeurs (750 Mhz je crois) , 16 Go de RAM, Fibre optique et tout le blabla etc..
Ca ressemble furieusement à un troll quand même :)
Un test qui serait plus révélateur en faisant intervenir le nombre de CPU c'est une compilation avec make et son option -j.
Ou pour conserver le test OpenSSL, on peut faire:
openssl speed rsa1024 md5 rc4 -multi 12
Et avec ça, on a un aperçu de ce que peut absorber un serveur qui reçoit des connexion SSL en utilisant la combinaison la plus courante (RSA1024 bits, MD5, RC4). Le nombre de signatures RSA indique le nombre d'authentifications par seconde, les 2 autres mesures (RC4 et MD5) indiquent la quantité de données transmises.
Comme souvent, des gros chiffres font plaisir à son ego.
A côté de ça, ce genre de test n'est pas tellement significatif, il faut prendre en compte la fiabilité, les perfs I/O, la stabilité, ... Un serveur avec un CPU très rapide mais qui nécessite une interruption de service de 4h en cas de défaillance matérielle (le temps d'aller au chinois le plus proche et de changer la pièce, par exemple un CPU), c'est pas toujours acceptable pour un service critique. La Sun décrite ci-dessus peut très certainement voir ses cartes CPU désactivées, enlevées, changées, et redémarrées, à chaud, sans reboot, sans arrêt des services. Au pire, on aura un service dégradé en perfs, mais pas d'arrêt.
-- Erwann ABALEA - RSA PGP Key ID: 0x2D0EABD5 ----- Moi je connais pas trop les ng techniquement s'il y a quelqu'un qui s'y connait assez pour m'indiquer une personne qui s'occupe des newsgroups et qui pourrait passer un coup de balai ici... -+- AT in: Guide du Neuneu Usenet - Neuneu comme un balai -+-
