Benchmark

13 mai 2011

Mon ami grep

grep, c'est mon ami. C'est d'ailleurs probablement l'ami de pas mal d'administrateurs système (enfin, les vrais quoi*). De temps en temps, il faut quand même bien vérifier que son ami est au mieux de sa forme, s'enquérir de ses performances, évaluer d'un œil critique si son environnement lui convient bien.

Quand vous avez un millier de chaînes de caractères, dont vous souhaitez retrouver toutes les occurrences dans un gros fichier de 685000 lignes, vous pouvez utiliser grep de deux manières :

vous dites à votre ami grep de chercher toutes les chaînes en même temps dans le gros fichier,
vous utilisez une boucle pour dire à grep de chercher une chaîne dans le fichier, puis de passer à la chaîne suivante, …

La solution 1 semble la plus intéressante. Une seule commande, pas de boucle, on se dit naturellement que c'est plus économique, et donc plus rapide. La solution 2, on se dit qu'elle est moche, complexe, et que les performances vont être mauvaises.

Petit test grandeur nature sur un serveur FreeBSD 7.x virtualisé, 2 CPU, 2Go de RAM :

Méthode 1 :
grep -i -f liste_emails maillog
opération terminée en 370 min environ.
Méthode 2 :
while read email; do grep -i $email maillog ; done<liste_emails
opération terminée en 1 min 32 s.

Bien sûr, le résultat est le même en terme de contenu, la seule différence est l'ordre des lignes. La méthode moche et supposée lente est juste 240 fois plus rapide que la méthode académique. Shame on you grep. Shame on you.

L'environnement est aussi important. On pourrait se dire qu'avec plus de CPU (en puissance, pas en nombre), plus de RAM, tout irait tellement plus vite. Essayons la même chose sur un Mac Pro Xeon quad-core, avec 12 Go de RAM, sous Mac OS X 10.6.

Méthode 1 : 223 min.
Méthode 2 : 35 min 45 s.

Ce qui prouve une fois de plus que Mac OS X est un gros tromblon quand il s'agit de fork. Comprendre que le coût du lancement d'un programme, en terme de ressources système, est beaucoup plus fort que sur d'autres OS, comme FreeBSD par exemple. Ce qui fait de Mac OS X un très mauvais candidat pour les scripts shell utilisant des boucles de manière très intensive.
On voit aussi que la vitesse d'exécution de la méthode 1 est essentiellement liée à la puissance de calcul du CPU, alors que la vitesse de la méthode 2 est essentiellement liée à la capacité du système d'exploitation de créer des process rapidement.

Pour conclure, j'ai fait un petit test avec awk, sur les mêmes fichiers. Moyennant quelques aménagements triviaux pour transformer le fichier liste_emails en programme awk, j'ai pu lancer la commande awk -f liste_emails maillog qui est l'équivalent de la méthode 1 pour grep. Le temps d'exécution est tombé à moins de 15 minutes sur Mac OS X, et moins de 30 minutes sur le FreeBSD.

* ceux qui ont fait 5 ans d'études dans une autre branche, avant de passer à l'informatique, par exemple.

30 janvier 2011

Benchmark Left 4 Dead 2, sur Mac Pro

La plupart des "gamers" vous le diront, la bonne machine pour les jeux, c'est celle qui fait tourner Windows. Si on met de coté les consoles de jeux dédiées, ils n'ont pas tort. Comparés à ceux de Mac OS X, les pilotes vidéo Windows sont plus performants, voire dans certains cas vraiment beaucoup plus performants. Les cartes vidéo disponibles sont aussi plus récentes, et les jeux programmés en DirectX sont bien sûr nativement privilégiés, puisque DirectX n'est pas disponible sur Mac OS X.
Ceci posé, j'ai décidé de faire des tests pour déterminer quels réglages vidéo sont les meilleurs pour jouer confortablement à Left 4 Dead 2 sur (mon) Mac. À titre indicatif, il s'agit d'un Mac Pro mono Xeon quad-core 2,8GHz, 3Go de RAM (DDR3), ATI Radeon HD 5770, sous Mac OS X 10.6.6.

Pour faire un benchmark L4D2 sur PC ou Mac, il faut procéder à plusieurs manipulations que je ne vais pas détailler. Sachez juste qu'il faut activer la console développeur dans les préférences du jeu. Grace à cette console, vous allez pouvoir enregistrer une "demo", c'est à dire le script d'une partie. Ensuite il faut rejouer ce script avec différents réglages vidéo, et enregistrer le nombre d'images par seconde que votre machine génère pendant le rendu vidéo de cette "demo". C'est long et fastidieux, et il est impossible (et stupide) de tester tous les réglages vidéo. Si j'avais voulu faire une mesure pour chaque combinaison de réglages, sans changer la résolution, il aurait fallu que je fasse 2700 rendus de ma partie enregistrée.

J'ai donc pris le parti de lancer 5 fois la partie enregistrée, toujours dans la même résolution (1920x1200), et toujours avec les paramètres "effects" et "model" au maximum.

Voici le résultat sous la forme d'un graphique :
bench_l4d2_macpro PNG 24bit

En rouge, est représenté le pourcentage d'images qui sont calculées à la vitesse de 60 images par seconde ou plus. Donc plus la proportion de rouge est grande, plus la carte video calcule vite le rendu de la partie. Et plus la proportion de vert et de bleu est faible, moins vous avez de ralentissements perceptibles dans le rafraîchissement de l'image. Ici le bleu (moins de 20 fps) est totalement absent.
Le jeu est capable d'afficher des chiffres de FPS ("frame per second") supérieurs à 60, mais le système intégré qui enregistre la répartition des FPS considère qu'à partir de 60 images par seconde il n'est plus utile de donner la répartition des FPS.
Ce n'est pas gênant, car in fine, les écrans actuels sont assez limités en terme de rafraîchissement, et que 60 images par seconde, c'est suffisant pour un affichage stéréoscopique à 30 images par seconde pour chaque œil. Donc à partir de 60 FPS, même un joueur exigeant pourrait jouer avec des lunettes 3D confortablement.

On voit sur ce graphique qu'un réglage a énormément d'impact sur le nombre de FPS : la synchronisation verticale. Si la synchronisation verticale est activée, le jeu ne peut pas dépasser 60 images par secondes, et le nombre global de FPS est sensiblement réduit. Mais ce réglage garanti une certaine cohérence de l'affichage et prévient l'apparition d'artefacts graphiques qui peuvent dénaturer l'expérience du joueur. Si votre machine le permet, laissez la synchronisation verticale activée. Les réglages 3 et 4 montrent l'impact de la désactivation de cette synchronisation sur la répartition des FPS.

Je ne vais pas plus loin dans l'analyse, il est aisé de comparer chaque jeu de réglages en utilisant le graphique. Si vous souhaitez faire le même benchmark que moi exactement, il vous faut le script de la partie que j'ai enregistré (ZIP 3,6Mo). La partie dure environ 10 minutes. L'archive contient un fichier parish000.dem qui est le script de la partie, et un fichier parish000.vdm qui est un fichier texte contenant les commandes qui lancent l'enregistrement des FPS au début du rendu, et qui arrêtent l'enregistrement à la fin du rendu. Il faut placer ces deux fichiers dans /left 4 dead 2/left4dead2 (je ne donne pas le chemin complet il est différent sur Mac OS X et Windows).
Après avoir joué la partie sur votre machine, vous obtiendrez un fichier prof_c5m4_quarter.csv situé dans /left 4 dead 2/update/. Attention, ce fichier est écrasé à chaque lancement de la "demo".
Je vous renvoie vers les forums et les aides en ligne pour tous les détails techniques (comment lancer une "demo", etc.).

Addendum

À titre de comparaison, voici le même benchmark effectué sur un MacBook Pro (un portable donc), doté d'un Core Duo 2,8 GHz, de 8 Go de RAM DDR3, et d'une carte vidéo GeForce 9600M GT. La résolution est native : 1440x900. J'ai tenté de faire le test avec les réglages vidéo "recommandés" par le jeu, l'écriture du fichier de log des FPS a échoué, mais les résultats étaient de toute manière catastrophiques.
bench_l4d2_macbookpro PNG 24bit
À gauche, un jeu de réglages "tout medium" avec antialiasing et filtering au minimum. Au centre, les mêmes réglages mais avec la synchronisation verticale désactivée. Enfin à droite le jeu de réglages "recommandés" par L4D2, mais avec la synchronisation verticale désactivée. Le résultat reste injouable, avec presque 75% des frames générées à moins de 20 fps.

17 février 2008

CF Extreme IV : lecteur externe et performances

Il y a déjà quelques temps, j'avais testé une carte CF Ultra II 1 Go et une CF Extreme IV 2 Go de SanDisk. Je reviens avec un autre test (rapide) : les mêmes cartes en lecture et écriture dans un lecteur externe FireWire Sandisk.

La méthodologie de ces tests est sommaire et barbare. J'ai choisi d'utiliser la commande dd pour lire et écrire des fichiers de 500 et 800 Mo sur les deux cartes. Le lecteur est connecté en FireWire 2 (800 Mbits/s théoriques, soient 100 Mo/s). Voici un exemple de commande utilisée pour l'écriture :

time dd if=/dev/zero bs=8k count=100000 of=/Volumes/EOS_DIGITAL/fichier

et un exemple de commande utilisée pour la lecture :

time dd bs=64k if=/Volumes/EOS_DIGITAL/fichier | dd of=/dev/null

Résultats d'écriture

12,43 Mo/s pour la carte Ultra II
30,42 Mo/s pour la carte Extreme IV

Résultats de lecture

13,17 Mo/s pour la carte Ultra II
64,93 Mo/s pour la carte Extreme IV

Je n'ai pas torturé les cartes pour en tirer les meilleurs performances, mais l'Extreme IV se dégage sans difficulté devant l'Ultra II avec des performances de lecture dépassant nettement les 40 Mo/s annoncés par le constructeur. Ce résultat est hautement suspect. J'ai donc refait le test de lecture de la carte Extreme IV avec des vrais fichiers RAW.

for image in /Volumes/EOS_DIGITAL/*.CR2; do
   time dd bs=64k if=${image} | dd of=/dev/null
done

La première exécution de cette commande donne environ 33 Mo/s pour les 39 fichiers RAW. La seconde lecture donne par contre une moyenne de 74 Mo/s. Sans doute une farce de l'OS (Mac OS X 10.5.2) et de ses multiples caches d'optimisation/accélération.
Dans le cadre de l'utilisation photographique d'une carte CF, l'ordinateur avec son lecteur externe va servir à télécharger les photos une fois, et effacer la carte. On peut donc oublier les résultats farfelus et ne retenir que le déjà très honorable 33 Mo/s.
Pour utiliser régulièrement cette carte avec de lecteur pour décharger mes photos, je peux témoigner du confort énorme qu'apporte ces performances.

6 juin 2007

Compact Flash Extreme IV : performances comparées

CF extreme IV Il y a quelques temps sur cfsl.net une petite discussion s'est engagée sur les mérites comparées de quelques cartes Compact Flash. Si nous sommes bien tous conscients que ça ne change pas la face du monde, surtout dans un réflex numérique grand public, les vitesses des CF SanDisk Ultra II et Extreme IV sont présentées comme assez différentes par le site lesnumeriques.com. Il me tardait donc de pouvoir vérifier ces chiffres.
J'avais déjà fait un test selon la méthodologie de lesnumeriques.com pour ma carte Ultra II dans mon EOS 350D : prendre 30 photos en X secondes. J'ai refait ce test avec une carte Extreme IV dans des conditions similaires. Voici les résultats comparés à ceux avancés par l'article mentionné plus haut :

30 jpeg

17 sec. sur l'Ultra II
12 sec. sur l'Extreme IV (29,4% plus rapide | lesnumeriques.com : 35,2% avec 11")

30 RAW+jpeg

56 sec. sur l'Ultra II
52 sec. sur l'Extreme IV (7,1% plus rapide | lesnumeriques.com : 21,4% avec 44")

Si le test "jpeg" donne un résultat assez proche de celui de référence, le test "RAW+jpeg" est sensiblement moins bon. Il sera peut être nécessaire de refaire le test complètement sans reprendre les vieux résultats de l'Ultra II. Néanmoins, les écarts de performance que je constate entre l'Ultra et l'Extreme étant plus faibles que ceux qu'avance lesnumeriques.com, cela confirmerait que l'EOS 350D est bien le facteur limitant comme le disent plusieurs sites dédiés à la photographie.

Pour compléter ce test, je me suis livré à un second comparatif. En inversant la méthodologie j'ai décidé de mesurer le nombre de photos prises en un temps donné. Voici donc pour chaque carte le nombre de jpeg, raw, et raw+jpeg enregistrés en 10 et 30 secondes :

jpeg haute qualité

63 en 30" et 27 en 10" sur l'Ultra II
64 en 30" et 29 en 10" sur l'Extreme IV

RAW

32 en 30" et 13 en 10" sur l'Ultra II
32 en 30" et 14 en 10" sur l'Extreme IV

RAW+jpeg

21 en 30" et 09 en 10" sur l'Ultra II
21 en 30" et 10 en 10" sur l'Extreme IV

Les résultats sont pour ainsi dire totalement identiques d'une carte à l'autre. La carte Extreme IV garde un très maigre avantage sur 10 secondes, mais sur 30 secondes elle fait jeu égal avec l'Ultra II dans un EOS 350D. C'est intéressant de voir comme les deux méthodologies de test donnent des résultats si différents pour les mêmes cartes testées dans le même boîtier. Ce dernier test montre encore mieux que le premier la limitation imposée par l'appareil numérique

15 novembre 2006

Sun T2000 contre Apple Mac Pro, contre Linux, fin des tests

J'ai fini par boucler mes modestes tests de charge MySQL 4.x sur la Sun T2000, le Mac Pro d'Apple, et un serveur Supermicro 6015P-TR sous linux. Comme je n'ai utilisé que super-smack à cause de fortes contraintes temporelles (entre autre), les résultats ne sont pas forcément généralisables, ni applicables à toutes les architectures. Néanmoins j'ai obtenu quelques résultats intéressants.
Continue reading →

20 octobre 2006

Il y a des benchmarks MySQL qui tournent à la violence pure

Joli aileron de requin, cela dit.

9 octobre 2006

SUN T2000 contre Apple Mac Pro ?

La T2000 revient pour une nouvelle série de tests préliminaires, cette fois contre un Mac Pro, gracieusement prêté par Apple. Je rappelle sommairement les caractéristiques de la machine Sun : 1 processeur physique à 1 GHz, avec 8 cores capables d'exécuter chacun 4 threads, 8 Go de RAM, des disques SAS. Le Mac Pro est bien doté aussi : 2 Xeon Woodcrest 2,66 GHz à deux cores, 7 Go de RAM et 4 disques SATA II.

Comme précédemment, le but est de mettre en face du serveur MySQL de la T2000, un client capable de mettre à genoux la machine Sun.
On a vu qu'un client XServe bi G5 à 2 GHz n'est pas assez puissant pour faire chauffer le serveur. Au plus fort de mes tests j'ai dépassé 90 de charge sur le XServe, et la T2000 n'a jamais atteint les 20% cpu. Le nombre de selects par seconde, obtenu via super-smack sql_select-key.smack $i 10000 (avec $i un nombre de threads entre 1 et 80), plafonne à 13400 ±300.
Dans les mêmes conditions, le client Mac Pro arrive à tirer 26700 ±200 selects par seconde du serveur Sun. Pendant cette charge de threads et de requêtes, le MySQL consomme 16% du cpu sur le serveur. À moins de faire une attaque distribuée à partir de plusieurs clients, je ne vois aucun moyen de mettre la T2000 en échec, ce qui est bon signe si je veux remplacer nos trois XServes/MySQL par une seule T2000/MySQL.

28 septembre 2006

SUN T2000 contre Apple XServe ?

J'ai reçu il y a deux jours un nouveau jouet : un serveur SUN T2000 en prét pour 60 jours. Sans rentrer dans les détails, puisque j'y reviendrai, je peux affirmer une chose : je vais avoir bien du mal à faire mes benchmarks MySQL sur cette machine. La raison est simple, je crois que je n'ai pas de machine assez puissante à mettre en face !
Pour mes tests préliminaires, j'ai confronté la SUN à notre machine de test habituelle, un XServe bi-G5 2GHz avec 4 Go de RAM. La T2000 à un seul processeur physique, à 1GHz, mais il dispose de 8 cores, chacun pouvant exécuter 4 threads. On se retrouve alors avec une machine possédant 32 processeurs virtuels, elle dispose par ailleurs de 8 Go de RAM :

root@sunt2000 # psrinfo -pv
The physical processor has 32 virtual processors (0, 1, 2, 3, 4, 5, 6, 7, 8, 
9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28,
 29, 30, 31)
  UltraSPARC-T1 (cpuid 0 clock 1000 MHz)

Et bien, le XServe mouline comme un taré (actuellement Load Avg: 15.14, 13.33, 9.61, et ça monte), alors que la SUN ne fait presque rien :

   PID USERNAME  SIZE   RSS STATE  PRI NICE      TIME  CPU PROCESS/NLWP       
   935 mysql    2565M  856M cpu9    45    0   2:37:15 6.1% mysqld/25
../..
Total: 45 processes, 188 lwps, load averages: 2.78, 2.77, 2.50

Je reviendrai là dessus quand je serai un peu plus familier avec Solaris d'une part et les méthodes de bench MySQL d'autre part, mais j'ai dans l'idée que les 60 jours vont très vite passer.

Cognitive Overhead

Archives