Benchmark

15 décembre 2012

Mac OS X Benchmark: native vs virtualized, part 2

I've been really disappointed by my last benchmark of a virtualized Mac OS X running on top of ESXi with graphics card accessed in passthrough mode. So disappointed in fact that I had to make new tests.
This time, I've decided to ditch the six years old XBench, and to use proper video benchmarking tools: Geeks3D GpuTest, and Cinebench. And guess what? Thats better.
To run those tests, I've had to install OS X 10.8.2 because Geeks3D GpuTest doesn't run on Mac OS X 10.6.8. So I dedicated a SATA HDD on my Mac Pro to a fresh install of 10.8.2, created a VM with it and ran both benchmarks, once from the Mac Pro booted from OS X, once from the OS X VM.

In the chart bellow you can find FurMark and GiMark tests results for a native OS X system running on the Mac Pro, and for the exact same system running as a VM on top of ESXi hypervisor. No tuning was done, I've used the default settings for every benchmarks.

Geeks3D GpuTest	Native	VM
FurMark (AvgFPS / Score)	47 / 2845	47 / 2872
GiMark (AvgFPS / Score)	33 / 2000	7 / 446

FurMark scores the same frame rate on VM and on native OS X. But GiMark is not good at all, with a VM score 4.5x lower than reference.

Cinebench's results are quite interesting too:

Cinebench	Native	VM
CORES	4	4
LOGICALCORES	2	1
MHZ	2800	2663
CBCPUX	5.038354	3.797552
CBOPENGL	32.284100	27.319487

VM results are quite close from reference, but the CPU frequency is reported as 2.663 GHz instead of 2.8 GHz, and the VM has only 4 CPU threads, instead of 8. This explain the CPU performance drop between native and virtualized OS X. The OpenGL score is quite good, showing only a 15.4% drop.
We are very far from the 87% drop on XBench's OpenGL test.

On the left side the native OS X, on the right side the virtualized OS X:
Cinebench results for OS X 10.8.2 native vs virtualized

3 décembre 2012

Mac OS X Benchmark: native vs virtualized

An important thing about my work-in-progress virtualized workstation setup is that I've created the Mac OS X VM using my very own hard drives, hooked as raw devices (RDM: raw device mapping). So I can boot exactly the same OS directly from the hard drive, or from ESXi into a virtual machine. Quite convenient when the time comes to make comparisons. And now, I can boot the VM with ATI Radeon graphics card plugged in passthrough mode thanks to VMware DirectPath I/O and some tweaking.
While it's not enough to make a workstation (still miss a keyboard/mouse in passthrough), it allows some benchmarks. I've ran XBench on the VM and on the same OS booted natively from the hard drive.

The VM is configured with only 4 CPU. the Mac Pro sports a quad core Xeon capable of hyperthreading, so when Mac OS X boots natively it sees 8 CPU. It might explain the 50% difference on the Thread test, but that will require further testing.

The final result is not good at all. I understand very well that virtualization has a performance cost, but if I want a powerful virtualized workstation I need a setup that will waste as few resources as possible.
Quartz Graphics and User Interface tests show that "desktop" graphics are well supported, but the OpenGL test results are horrendous. With a performance loss of 87%, it predicts much trouble with games. According to this very simple benchmark, the VMware passthrough mode for graphics card seems to be very bad compared to what can be seen on XEN for example.
To be honest, having my hard disks accessed directly via RDM, I though I would have a 10-15% penalty. The 46% drop for sequential access surprises me. As for the GPU, the OpenGL results are so bad I'm wondering if the graphics card is properly passed through. May be some features are just dropped in the process. By the way, the virtualized Mac OS X won't load the screen color profile. May be it's related to the pseudo-VGA screen attached to the VSphere console. Unfortunately I can't get rid of this pseudo-VGA screen yet. Until I find a way to pass keyboard and mouse through to the VM, I need the VSphere console.

Results	259,39		127,18		-50,97 %
System Info
Xbench Version	1,3		1,3
System Version	10,6,8	(10K549)	10,6,8	(10K549)
Physical RAM	24576 MB		12288 MB
Model	MacPro5,1		VMware7,1
Drive Type	WDC	WD1001FALS	WDC	WD1001FALS (ATA)
CPU Test	205,42		200,27		-2,51 %
GCD Loop	314,75	16,59 Mops/s	305,66	16,11 Mops/s	-2,89 %
Floating Point Basic	182,81	4,34 Gflop/s	177,44	4,22 Gflop/s	-2,94 %
vecLib FFT	121,5	4,01 Gflop/s	119,14	3,93 Gflop/s	-1,94 %
Floating Point Library	385,38	67,11 Mops/s	374,17	65,15 Mops/s	-2,91 %
Thread Test	954,74		477,33		-50,00 %
Computation, 4 thr.	989,65	20,05 Mops/s	517,69	10,49 Mops/s	-47,69 %
Lock Contention, 4 thr.	922,22	39,67 Mlocks/s	442,8	19,05 Mlocks/s	-51,99 %
Memory Test	452,72		370,19		-18,23 %
System	493,4		452,74		-8,24 %
Allocate	746,78	2,74 Malloc/s	877,63	3,22 Malloc/s	17,52 %
Fill	352,03	17116,62 MB/s	287,47	13977,29 MB/s	-18,34 %
Copy	526,18	10867,96 MB/s	497,95	10285,00 MB/s	-5,37 %
Stream	418,24		313,1		-25,14 %
Copy	422,51	8726,77 MB/s	321,23	6634,92 MB/s	-23,97 %
Scale	395,84	8178,02 MB/s	303,88	6278,02 MB/s	-23,23 %
Add	438,89	9349,24 MB/s	328,71	7002,18 MB/s	-25,10 %
Triad	417,99	8941,89 MB/s	300,37	6425,59 MB/s	-28,14 %
Quartz Graphics Test	315,19		300,47		-4,67 %
Line [50% α]	239,24	15,93 Klines/s	232,29	15,47 Klines/s	-2,91 %
Rectangle [50% α]	314,61	93,93 Krects/s	296,25	88,45 Krects/s	-5,84 %
Circle [50% α]	264,41	21,55 Kcircles/s	251,89	20,53 Kcircles/s	-4,74 %
Bezier [50% α]	279,29	7,04 Kbeziers/s	263,55	6,65 Kbeziers/s	-5,64 %
Text	875,44	54,76 Kchars/s	836,28	52,31 Kchars/s	-4,47 %
OpenGL Graphics Test	306,01		39,01		-87,25 %
Spinning Squares	306,01	388,19 frames/s	39,01	49,49 frames/s	-87,25 %
User Interface Test	463,72		405,19		-12,62 %
Elements	463,72	2,13 Krefresh/s	405,19	1,86 Krefresh/s	-12,62 %
Disk Test	97,42		72,35		-25,73 %
Sequential	176,21		94,27		-46,50 %
Uncached Write [4K blk.]	180,38	110,75 MB/s	167,14	102,62 MB/s	-7,34 %
Uncached Write [256K blk.]	177,43	100,39 MB/s	80,84	45,74 MB/s	-54,44 %
Uncached Read [4K blk.]	149,41	43,73 MB/s	51,88	15,18 MB/s	-65,28 %
Uncached Read [256K blk.]	207,16	104,12 MB/s	208,09	104,59 MB/s	0,45 %
Random	67,32		58,7		-12,80 %
Uncached Write [4K blk.]	21,3	2,25 MB/s	19,86	2,10 MB/s	-6,76 %
Uncached Write [256K blk.]	507,04	162,32 MB/s	300,75	96,28 MB/s	-40,69 %
Uncached Read [4K blk.]	159,73	1,13 MB/s	96,75	0,69 MB/s	-39,43 %
Uncached Read [256K blk.]	235,97	43,79 MB/s	242,2	44,94 MB/s	2,64 %

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.

Cognitive Overhead

Archives