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.

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.

Compact Flash Extreme IV : performances comparées

CF extreme IVIl 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

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

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.

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.

Le Mac Pro en chiffre

Anandtech propose ce qui semble être un bon test comparatif du Mac Pro. Ce comparatif confirme bien, je trouve, que le Mac Pro n'est vraiment pas une machine grand public. Par ailleurs, il apparaît que les performances des tâches étroitement liées à la mémoire sont très mauvaises. Cela n'augure rien de bon pour le XServe, même si ce dernier va gagner 2 cores.
Pour finir sur les performances brutes, les tests avec un processeur désactivé (donc 2 cores au lieu de 4) montrent que les applications pouvant tirer partie de 4 cores sont vraiment marginales pour le grand public (toutes celles qui sont testées sont "grand public").
Moralité, un iMac Core Duo (ou Core 2 Duo quand ils sortiront) devrait faire jeu égal avec un Mac Pro à 2x plus cher dans toutes les utilisations courantes (hors considération de carte vidéo). De quoi donner à réfléchir sérieusement au placement de son argent.

La question de la consommation électrique est aussi abordée : le quad-core xeon 2.66 GHz consomme sensiblement moins que le quad G5 2.5 GHz en plein travail, mais je trouve la comparaison douteuse. La pompe de refroidissement liquide du quad G5 doit probablement consommer plus qu'un ventilateur.