Et si on faisait des outils de bench ?

[djaconil]

y a sûrement mieux qu'une suite de fibo pour les benchs, quelque chose de plus complet....

Moi je pense à un calcul de fft sur 4096 points par exemple. Mais il faut pondre le code.

[buserror]

y a sûrement mieux qu'une suite de fibo pour les benchs, quelque chose de plus complet....

Moi je pense à un calcul de fft sur 4096 points par exemple. Mais il faut pondre le code.

Bah, 4096 ? c'est du gateau. Je fais facile du 16k points dans FFTea, et la machine est loin d'etre a genoux.

[GregWar]

Bonsoir,

Pour un petit bentch qui tourne sur PC et Mac, j'ai peut être une idée. La c'est vraiment pour tester les perfs générales de la machine autour du Proc. C'est en Java, donc on teste tout, le proc, le système (bus système / ram ...) mais aussi le logiciel : ordonanceur de l'OS. Et Mac OS X est plutôt bien placé dans ce domaine. Bien entendu, c'est du Java, donc les tests ne sont pas super precis, mais ca donne un rapide apercu de la puissance de la machine.

Je suis partis d'un constat tout bête quand je fesais un programme. J'ai au boulot un AMD Athlon XP 1500+ (sous Linux je précise) et j'ai ramené au boulot le PB G3 400.

A la base, je travaillais sur un programme java assez gourmant en capacitées proc et par curiosité je l'ai mis sur le mac, qui ma fois ce débrouillais comme un charme
En fait, en gros, tant que l'on ne fais pas d'interface graphique en Java, j'ai noté que la JVM d'apple est plutot performante !

On peux donc tester les performances de nos macs, et voir les gains et les pertes entre chaque évolutions, mais également les comparer avec d'aute architectures (Qui à une sation Solaris ou SGI ou ... ? (ou un Palm ))

Je ne suis pas sur qu'un bench en Java soit le plus adapté pour tester la vitesse d'un mac…
Tu vas surtout tester l'efficacité de la JVM, ce qui veut tout et rien dire (meme si pour ma part, je serais partant pour un bench des différentes JVM, mais C un autre sujet).

D'autant plus que d'une JVM a l'autre les résultats different bcp :
http://www.osnews.com/story.php?news_id=5602&page=1
(attention je ne critique pas JAVA, j'en fais toute la journée, et j'en suis tres content)


Je pense que évaluer la vitesse d'un mac, il faudrait plutot utiliser les API natives, la couche graphique native, etc… il existe déjà des tests touts simples, orientés utilisateurs, qui sont assez parlant, du genre : mesurer le temps de fermeture de 1000 fenetre du finder…

Pour des tests plus scientifiques/techniques, il faut faire attention à ne pas faire qqc qui dépende du compilo (typiquement sur des parcours d'arbres, des calculs complexes, ou certaines options sont profitables a certaines architecture et pas à d'autre)… et ceci est particulierement en ces temps ou l'on trouve encore des G3, mais surtout des G4 et G5 qui ont un nombre différents d'unités de calcul vecto, en plus de l'archi 64bits… pas simple du tout d'etre objectif !!!

[dulrich]

Je crois au contraire qu'il faut fournir une grande variété de test, c'est à dire du java, du c et du fortran. De cette manière on peut évaluer les machines selon tous les critères. On peut y ajouter des tests spécifiques sur altivec, flottant, entier etc.... du moment qu'on donne un résultat pour chaque test et qu'on ne combine pas tout.
On pourra voir ainsi quelles sont les améliorations apportées aux machines, ce qu'elles représentent dans les faits.... sinon autant listr simplement les GHz.... c'est pas le but.

[apprenti bidouil...]

Entièrement d'accord, il nous faut un truc très varié, sinon ça ne sert à rien !

[dulrich]

Alors hier soir j'ai abouti à ça pour les mesures de vitesses...c'est moche, je me suis pas embeté pour l'instant
Voici la vitesse de lecture de mon combo drive lorsque je copie 700 Mb (1 fichier sur le disque). L'application marche pas mal...1 point par seconde (utilisation très faible du CPU). C'est un début...je vais faire mieux ce soir

tu peux filer les sources?

Sinon pour le temps, il y a en effet d'autres applications.... Je suis en train de lire quelques pages de man, mais je ne trouve pas de vrai équivalent à GetTick() sur PC.....

[Lionel]

Si tu pouvais m'envoyer une béta de ton soft.
C'est pour mettre en évidence la différence de vitesse de gravure du Nec et du Pioneer.
Merci

[GregWar]

Je crois au contraire qu'il faut fournir une grande variété de test, c'est à dire du java, du c et du fortran.

Le truc avec Java, C que ton programme peut ne pas changer d'une ligne et ses perfos évoluer énormément !

Si on reprend mon lien de tout à l'heure on voit que (sur PC) la JVM 1.4 est 2x plus lente sur les calculs trigo que la 1.3… ca veut donc dire, en grossissant un peu les choses, qu'une machine 2x plus perfo, plus récente mais disposant d'une nouvelle JVM moins adaptée au problème précis que tu traites serait seulement l'égale de son ainée…

J'en ai déjà parlé dans les fora, mais sur une appli JAVA de test AWT & SWING hyper basique, mon PC Athlon 1GHz fait >60fps, alors que mon iBook 700 Ati7500 fait du 6 à 7 fps… le rapport n'est pas du tout réaliste ! Ce n'est pas le hard le probleme, mais bien la couche graphique JAVA d'Apple.

bref, qqpart ce serait comme comparer des movies Flash… on risque d'oublier les versions du player lorsque l'on juge 2 machines.

[Lionel]

Et un gros calcul de N décimales de Pi ?
C'est universel ça

[apprenti bidouil...]

héhé, un petite valeur approchée à 10000 décimales !!

[Guest_macmagna_*]

Pour ceux que le calcul de PI interesse, j'ai récupéré un source basique et facilement adaptable qui fait le boulôt:

Source et executable

J'ai juste ajouté les lignes post-commentées par MM dans main pour avoir une idée des perfs.
Ce qui est étonnant c'est que la moyenne n'est pas constante et diminue avec l'augmentation du nombre de décimales. Si qqun peut m'expliquer ça?
J'ai chez moi par ex:
Digits: 1000 - Time: 0.043968s - Rate: 22744/s
Digits: 10000 - Time: 2.838359s - Rate: 3523/s
Digits: 20000 - Time: 13.870423s - Rate: 1442/s

Edit: Le lien original http://mathforum.org/library/drmath/view/54343.html

Ce message a été modifié par macmagna - 11 Feb 2004, 21:47.

[Tilao]

Oui, c'est tout à fait normal,

Le calcul du nombre Pi ne tiens pas dans un registre mémoire, dans un réel par exemple (qui d'ailleur fausserait l'approximation, il me semble)

Le calcul de Pi ce fait sur un ensemble de variables contenues dans un tableau. Plus tu calcule de décimales de Pi, plus le nombre est grand, plus le nombre de variable utilisés est important.

Pour faire très simple, au début, on fait un calcul sur une variable

Par exemple x = x + 1; C'est le BA B.A, c'est très rapide.

Si tu depasse la capacité de x, tu crée deux variables, x1 et x2 et en gros tu as

x1 = x1 + 1;
Si (x1 à eut un dépassement de capacité) {
x2 = x2 + dépassement de capacité;
}

ensuite tu passe à trois variable, puis 4, puis des 10 aines, de 100 aines, etc

Donc au début faire un calcul etait très rapide, en gros une opération du processeur. Ensuite tu dois faire des 100 aines d'opérations au niveau "algo et matériel" pour une opération "mathématique".

Donc ton programme ralenti.

[No6]

Hello,
J'ai appercu des Benchs de compilateurs ADA,
mis à partl'aspect performance, il y avait aussi un controle des résultats, de la précision.
mon petit grain de sel...

[blueG3]

pour les tets il faut differentier
1) le calcul en virgule flottante ( la reine incontesté dans ce domaine le fortran )
2) le calcul avec des entiers

dans les 2 cas , faire attention au nombre de bits utilisés , car la quantité de memoire va fluctuer et donc fausser les resultats.

le probleme du compilateur est crucial , car il ne faut pas des optimisdations de codes qui avantagent une machine , plus qu'une autre ( du coup altivec est a mettre de coté)

eviter dans la mesure du possible , de faire des calculs sur une utlisation de memoire faible , la memoire cache va fatalement provoquer de grand ecarts.

effectuer un calcul sur plusieurs minutes , cela permets de mieux mesurer la performance.

je penses dans le cas avec des entiers differents algorithmes de tris , ( les optimisations des compilos vont forcement passer par là) , mais sur une volumetrie suffisemment importante ( evidemment le type de gestion de fichiers differents va fausser la aussi le resultat , genre optimisation fichier sur index....)

eviter les declarations de type union sur pc qui favorisent un gain, de place memoire , ce n'est pas forcement le cas sur une machine big endian ( pour des raisons d'alignements en memoire )
--> ce point est systematiquement utilisé coté PC , mais partir d'un meme source avec des options de compilation identique devrait mettre une egalité sur ce point.

[apprenti bidouil...]

( du coup altivec est a mettre de coté)

C'est là on je pense qu'il faut qu'on se décide, soit on essaie de faire un truc très objectif, mais qui ne tient pas forcément compte de ce que font réellement les utilisateurs, soit on fait un truc sans doute moins *officiel*, mais qui se préoccupe des besoins réels... si quelque chose de souvent utilisé par l'utilisateur est fortement aidé par l'altivec, on le met quand même dans le test, puisque c'est quelque chose qui touche vraiment l'utilisateur final... Ce serait plutôt ma philosophie... ce serait vrai dans l'autre sens, si quelque chose que fait souvent l'utilisateur est favorisé par une architecture intel, on le mettrait quand même.

J'ai pas l'impression d'être très clair...

[dulrich]

Je crois au contraire qu'il faut fournir une grande variété de test, c'est à dire du java, du c et du fortran.

Le truc avec Java, C que ton programme peut ne pas changer d'une ligne et ses perfos évoluer énormément !

Si on reprend mon lien de tout à l'heure on voit que (sur PC) la JVM 1.4 est 2x plus lente sur les calculs trigo que la 1.3… ca veut donc dire, en grossissant un peu les choses, qu'une machine 2x plus perfo, plus récente mais disposant d'une nouvelle JVM moins adaptée au problème précis que tu traites serait seulement l'égale de son ainée…

J'en ai déjà parlé dans les fora, mais sur une appli JAVA de test AWT & SWING hyper basique, mon PC Athlon 1GHz fait >60fps, alors que mon iBook 700 Ati7500 fait du 6 à 7 fps… le rapport n'est pas du tout réaliste ! Ce n'est pas le hard le probleme, mais bien la couche graphique JAVA d'Apple.

bref, qqpart ce serait comme comparer des movies Flash… on risque d'oublier les versions du player lorsque l'on juge 2 machines.

Cela importe peu... je parle pas de graphique, mais de calcul mathématique.
On ne veut pas évaluer juste les perfs du proc, sinon, comme j'ai dis, on lit les MHz et ça suffit... mais on veut aussi voir, avec un code semblable dans lusieurs langages, ce que vaut le compilateur ET le proc....
On peut faire des calculs de plusieurs sortes... qui prennent l'aspect globale du CPU.

C'est clair qu'on va pas tester quartz avec du Java.

je suis POUR un test d'altivec, et pourquoi ne simplement pas le séparer du reste? Faire un test qu'altivec (ça permettrait de voir les progrès du G5 en la matière).

sinon pour une idée des problèmes du au cache:
http://madchat.org/coding/c/hack_processeur_en_C.html

[Guest_macmagna_*]

Ne pourrait-on pas faire un bench CPU avec quelque chose de trés simple comme:

CODE

#include <stdio.h>
#include <sys/time.h>

int main (int argc, const char * argv[])
{
   struct timeval begin, end;
   float elapsed;
 
   int count = 100000000, i = count, j = 1;
   
   gettimeofday (&begin, NULL);

   while (i--)
       j += j;
   
   gettimeofday (&end, NULL);
   elapsed = (float)(end.tv_sec - begin.tv_sec) + ((end.tv_usec - begin.tv_usec) / 1000000.0);
   printf("Count: %d - Time: %fs - Rate: %.0f/s\n", count, elapsed, ((float) count) / elapsed);

   return 0;
}

On pourrait mettre ce qu'on veut dans la boucle while, calculer sur un float, etc...
Et en assembleur avec le même nombre d'instructions pour les programmes PC et Mac?

[kakace]

Vouloir comparer, via des benchmarks, des architectures fondamentalement différentes avec le même code ne mène nul part. Pour une tâche donnée, on peut écrire du code qui fonctionne mieux sur une architecture que sur une autre, ou avoir un impact bénéfique sur l'une et pas sur l'autre, y compris lorsque l'algo est le même.
J'ai eu le cas avec du code écrit pour résoudre un challenge ECC (Eliptic Curves). Après avoir apporté des modifs triviales (réorganisation du code, principalement), les performances sur G4 étaient multipliées par trois, alors qu'elles évoluaient à peine sur AMD/Intel.

La seule façon de faire est d'utiliser des algos optimisés au maximum pour chaque plateforme, même s'ils sont différents, de façon à obtenir les performances maximales et savoir qui fait quoi mieux que l'autre. Faute de quoi les benchs sont biaisés d'entrée de jeu et ne signifient plus grand chose d'un point de vue pratique.

Tout dépend de ce que vous voulez faire.

[buserror]

Le calcul de Pi, le code tiens dans le cache, et c'est inutile. En plus ca n'a vraiment rien a voir avec la "vraie vie" et franchement, un bench qui est bon a quelque chose que je ne fais JAMAIS je m'en tapes pas mal!

Moi je suggere un filtre image de type gaussian, sur une petite matrice par exemple 3x3 pour tester le rapport scalaire/altivec, et ensuite pousser sur des matrices plus grosses si ont veut tester le scalaire a fond.

Un filtre image de ce type s'appuye a fond sur le nombre de registres, la qualite du scheduler, et aussi beaucoup sur la bande passante du bus et l'efficacité du cache.

Je suis pret a donner un gaussian 3x3 tout altivec qui travaille en natif sur de la video YUV 422.

Aussi, je suis pas manchot a ecrire de l'altivec direct, si jamais vous avez des trucs a vectoriser.

[l0wc0der]

Alors, voilà:

J'arrive à avoir les vitesses de transfert de données pour un Disque dur en read/write...mais j'arrive pas à avoir la vitesse de gravure d'un CD/DVD par ma méthode (que la vitesse de lecture ) . J'explique ce que je fait, je récupère avec IOKit les propriétés de tous les éléments qui correspondent à IOBlockDeviceDriver...ce qui me permet de récupérer les bytes lu/écrit...il faut encore que je travaille un peu pour arriver à obtenir la vitesse de gravure.

Sinon, j'ai remarqué un truc rigolo...si j'extraie un fichier d'un DVD en le copiant sur le disque à partir du finder et bien à ma grande surprise l(bon pas si grande que ça) le disque dur ne fait pas qu'écrire mais en même temps il lit beacoup de donnée -> correction d'erreur?
Avec "cp" dans le terminal que dalle, que de l'écriture...on voit aussi bien comment le multitache préemptif influence la vitesse de lecture/écriture...

Bon, pour ce qui est du code, c'est un peu compliqué...j'ai une version Cocoa et une version Carbon Mach-o...je préfère la version carbon car c'est plus simple à mon goût d'utiliser la bibliothèque standard C++. Je suis disposé à vous donner le code mais je pense que le truc bien à faire est de créer un projet sur sourceforge...c'est quand même plus agréable de pouvoir utiliser CVS

Pour ce qui est des benchs CPU, je suis d'accord avec buserror...en ce moment je donne des cours de simulation numérique à la fac et j'ai pas mal d'algorithmes en stock, mais il faut être franc la plupart ne sont pas significatifs de l'utilisation courante d'un ordinateur...
Ensuite, et là je rejoint kakace...pas la peine d'espèrer obtenir des benchs multiplateforme avec un seul code...de toute façon si on veut vraiment éviter des remarques du type "ils utilisent pas le compilo d'intel", etc... il y pas 36 façon de faire...assembleur très bien écrit hehe

[dulrich]

je comprend tout à fait vos point de vue, si je n'ai pas tout à fait le même c'est que je ne pense pas tester la même chose que vous.

Question compilateur, si on utilise gcc sur les deux plateformes il devrait avoir à peu prêt équité.

Pour l'assembleur et le ocde altivec j'ai encore quelques années d'études devant moi , donc pour ça je peux pas aider .

[Einstein]

donc ce serait aussi sensible à ce qui tourne sur la machine...

bon, alors on fait un truc qui demande au démarrage de quitter toutes les applis en cours d'utilisation... déjà ça limitera une bonne partie de l'activité de la machine nan ?

On pourrait même lister les process en cours et désactiver tous ceux qui ne sont pas indispensables.
Ensuite soit reboot soit on les relance.

plus simple: on peut les freezer. Comme ca à la fin on libère tout et c'est transparent pour l'utilisateur.

Mais bien faire attention de ne pas freezer le defreezeer, sinon c'est le gros bouton blanc sur la machine qu'il faudra activer

J'veux pas faire le ch*eur, mais le fait de freezer une appli de libère pas la mémoire qui lui est allouée, or si on fait des test mémoires, je ne pense pas que ça puisse être bénéfique, non?

[dulrich]

[mode second degré]
et si on faisait des scripts firmware pour les benchs?

ou alors on refait un OS minimal?
[/mode second degré]

[apprenti bidouil...]

clair j'en ai marre de os X
je propose que nous nous lancions dans MB OS ! ®©™

[bortek]

Moi pour l'outil MBBench, je peux juste vous aider pour l'icone et le design si vous avez besoin.

[Maconnect]

pour le calcul du temps, Microseconds() n'est-il pas mieux adapté que les ticks? Ces dernière ne sont pas précises

[l0wc0der]

Bonsoir

Si il y a toujours des interesses, on pourrait en discuter sur le chat irc de macbidouille...j'y suis ce soir. C'est plus simple de discuter en live...

A bientôt

[Kisco]

On a benché le tout avec la fonction gettimeofday.... qui est sensible à ce qui est en background, le code est pas forcément très beau (et pascal arrête de rire )

[l0wc0der]

Bon, y'a vraiment plus que moi d'intéréssé?

[apprenti bidouil...]

non non, je soutiens le projet ! mais je ne peux pas apporter grande aide au développement, à part tester les versions