Forum Programmation.c le test qui tue ;)

Posté par  .
Étiquettes : aucune
0
12
nov.
2004
J'ai besoin d'aide pour un petit programme que j'ai écrit.
Pas trop pour la mise au point, mais pour en sortir des résultats.
C'est à dire que je veux le tester sur un max de machines.


C'est juste un bout de code qui teste un peu les perfos de la machine et de l'operating system, disponible ici :
http://meynaf.free.fr/testeu(...)
(désolé, c'est index of /testeu, pas eu le temps de faire une page :)

Ce test-là dépend très peu de la vitesse de calcul brute et aveugle du processeur, c'est surtout l'efficacité (en timing) qui est visée.
C'est à dire, les temps incompressibles qu'on n'a pas dans les benchmarks classiques, mais qu'on observe dans la vraie vie quand ça rame...

Un .h avec deux .c, à compiler, et lancer le programme après, c'est pas dur.
Le lancer plusieurs fois de suite, avec une charge système la plus réduite possible.

J'aimerais bien qu'il y ait un maximum de gens qui fassent ce test, sur un maximum de configurations.
Pour porter le code sur une plate-forme, rien de plus facile (à condition de trouver les API adéquates) : il y a simplement 3 fonctions à réécrire, elles sont dans pf_unix.c.
Il y a un thread à créer, une fonction de lecture de timer et une fonction d'attente. Rien de bien difficile.
S'il y a du startup/cleanup code à mettre, le main est dans le source spécifique plate-forme, et appelle la fonction zmain.

J'avais prévu que mon thread soit d'une priorité inférieure au thread principal, c'est à dire qu'il ne puisse jamais l'interrompre, mais j'ai pas trouvé comment faire.
A vrai dire, le seul moyen aisé que j'ai trouvé pour créer un thread a été d'utiliser la SDL...
Si qqn pouvait m'aider, ce serait sympa.

J'ai aussi besoin, assez urgeamment, d'une version zindoz, mais j'ai tout simplement pas trouvé quelles API employer :(
(pour le thread et la mesure du temps, ok, mais pas pour le sleep en microsecondes : on dirait qu'y a tout simplement pas)
Une version Mac serait cool aussi, mais là j'y connais que dalle.

Vous pouvez m'écrire directement ici (réponse assurée, plus rapide que sur ce forum) :
meynaf@free.fr

Et ce, pour m'envoyer :
. résultats (cpu, fréquence cpu, operating system, version os, compilo utilisé, chiffres donnés par le programme)
. modifs éventuelles, portages (sur toutes plates-formes, y compris exotiques, sasfépu - j'ai déjà une version Amiga - , etc)
. questions
. remarques et suggestions (pas d'insultes svp :)


Une fois que j'aurai plein de résultats, je ferai une page dédiée sur mon site. Si vous pensez avoir un OS réactif, low latency, c'est le moment de le prouver 8-)))


Voilà. Pour ceux que ça intéresse...

  • # Pas tout compris la ?

    Posté par  . Évalué à 4.

    Je crois que je n'ai pas tout saisis. Tu m'arretes si je me trompe, mais :

    - Tu as fait un petit prog en C pour bencher une machine.

    - Ton prog doit compiler actuellement sous linux (je suppose car ce n'est pas précisé dans ton post).

    - Tu voudrais qu'on SE récrive les parties qui manque pour windows/mac et autre et qu'on t'envois à TOI les résultats.

    En gros, si c'est bien ca, on te mache un peu le travail. Ca risque de ne pas passer :)

    Une idée serai

    1) si tu n'a vraiement aucun moyen de compiler une version windows/mac (vérifie quand même car entre cygwin et le fait que gcc existe pour macosX ... c'est pas insurmontable) tu peux demander qu'on te les fournissent.

    2) tu te debrouilles pour que ton client, une fois executé t'envois automatiquement le resultat (requette http, mail, ce que tu veux).

    3) ensuite, tu fait un jolie site web avec les binaires et les sources en libre download.

    l'autre c'est de faire une jolie iso d'un joli live cd linux minimal avec ton programme de bench dessus. Ainsi on à qu'a rebooter sur l'iso pour faire le test (pas besoin de spécifique pour les OS x86, tu auras toutes les machines x86 d'un coup). En revanche ca sera un poil plus complexe pour générer des isos live linux pour autre archi si tu ne les a pas sous la main.

    voila, mon humble contribution.

    • [^] # Re: Pas tout compris la ?

      Posté par  . Évalué à 1.

      Mon code doit compiler sous Linux, oui.

      Mais je n'ai PAS de Linux (ni de Windows, d'ailleurs).
      Ce que je demande ici, c'est pas qu'on me mâche le travail, c'est de l'aide pour ce que je ne peux pas faire tout seul.

      1) Ok, mais c'est si vite fait pour qqn qui a la machine et qui la connaît... Je risque de faire des grosses bourdes sans le savoir.

      2) Non parce que ces choses-là ne sont pas trop portables, et j'ai déjà assez de spécifique comme ça dans mon code.

      3) Joli site web, je sais pas faire, mais il est clair que quand j'aurai quelques résultats, je ferai le site web avec les binaires et les sources en libre download.


      Un CD, pour un petit programme de quelques ko ?
      C'est pas un peu le char d'assaut pour aller faire les courses ?


      Enfin, merci pour ton humble contribution.

  • # un Makefile

    Posté par  (site web personnel) . Évalué à 3.

    Si tu veux qu'un max de gens testent ton programme, je te suggère de le rendre facile à compiler/utiliser: genre un tar.gz avec tout ce qu'il faut + un Makefile qui t'envoit éventuellement un mail quand on fait "make testeu" ou un truc comme ça.

    pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

    • [^] # Re: un Makefile

      Posté par  . Évalué à 0.

      C'est vrai que : gcc bench.c pf_linux.c suivi de : ./a.out c'est vachement plus compliqué qu'un makefile dans un tar.gz. En fait j'ai plus l'habitude des environnements de développement que des makefile. (ouh la honte je sais :) J'aurai bientôt les binaires en téléchargement sur mon site, ça sera plus simple que d'avoir à compiler.

      • [^] # Re: un Makefile

        Posté par  . Évalué à 1.

        En fait la ligne de compilation exact à faire est :
        gcc bench.c pf_unix.c `sdl-config --cflags --libs`

        Vu que tu utilises la libSDL il est indispensable de rajouter les headers et .so au linker. Installez donc le paquet de développement libSDL-dev, sous debian :
        apt-get install libsdl1.2-dev

        Alors toujours pas de PEGASOS ( http://www.pegasosppc.fr(...) ) pour faire tes tests Phil ? :)

  • # usleep(3)

    Posté par  (site web personnel) . Évalué à 2.

    usleep(3) :

    This function is obsolete. Use nanosleep(2) or setitimer(2) instead.

  • # 507

    Posté par  (site web personnel) . Évalué à 2.

    [gc@meuh /tmp/t/t] uname -a
    Linux meuh 2.6.5 #6 SMP Tue Sep 7 12:27:49 CEST 2004 i686 Intel(R) Pentium(R) 4 CPU 3.00GHz GenuineIntel GNU/Linux
    [gc@meuh /tmp/t/t] ./a.out
    performance système : 506
    [gc@meuh /tmp/t/t] ./a.out
    performance système : 503
    [gc@meuh /tmp/t/t] ./a.out
    performance système : 507
    [gc@meuh /tmp/t/t] ./a.out
    performance système : 509

    • [^] # Re: 507

      Posté par  . Évalué à 1.

      C'est exactement ça qu'il me faut comme infos, merci !!!

      Quand j'aurai plein de résultats comme celui-là, je les mettrai sur la page :
      http://meynaf.free.fr/testeu/(...)

      (quand j'en aurai 5 ou 6, je fais la page et je la mets en ligne, un peu de patience...)

      • [^] # Re: 507

        Posté par  . Évalué à 1.

        Il est intéressant de signaler, même si tu le sais déjà, que les résultats sont différents si on lance le bench sous X ou en mode console uniquement.
        Sous X j'ai des résultats plus élevés !

        A préciser donc l'environnement de test que tu souhaites. Pour la version Windows la libSDL devrait compiler dessus.

  • # AMD Athlon(TM) XP 1600+ @ 1059.454 MHz Linux 2.4.22, Debian (~sarge)

    Posté par  . Évalué à 1.

    à la compilation j'ai un petit warning:

    # gcc-3.3 bench.c pf_unix.c `sdl-config --cflags --libs`
    pf_unix.c: In function `runthread':
    pf_unix.c:23: warning: passing arg 1 of `SDL_CreateThread' from incompatible pointer type

    # ./a.out
    performance système : 50

    conclusion mon système est 4 fois moins performant que celui de gc

  • # Merci à vous tous !

    Posté par  . Évalué à 1.

    Je vais mettre tout ça sur mon site (l'url est dans mon message plus haut). Ça devrait être en ligne ce lundi.

    Apparamment, le dernier kernel low latency fait toute la différence... en tous cas je suppose que le facteur de *10 vient de là.

    Ce que je mesure en fait, c'est le temps mis par le système à redonner le processeur à une application qui vient de le perdre (par un appel sleep() volontaire).

    Je fais donc des appels usleep() avec des durées de plus en plus grandes, vérifiant que mon thread a pris le cpu. Si tel n'est pas le cas, le test n'est pas bon, sinon je prends la durée réellement écoulée.
    Même en cas de réussite, je continue le test, prenant à l'arrivée le meilleur résultat.

    Je ne sais pas si mon source est bien clair à ce sujet...

    On dirait que la réactivité dépend assez peu de la vitesse du processeur, et beaucoup de la politique d'ordonnancement du système.

    A titre d'exemple, un bon vieux Amiga (de 1992 !), muni d'un 68030 à 50 Mhz, sous OS 3.0, arrive sur ce test à une valeur de... 2500 (entre 2470 et 2510).
    Quand je vous dis que ça dépend pas de la vitesse du cpu ;-)


    J'aimerais bien savoir ce que donnerait un QNX !!!

    • [^] # Re: Merci à vous tous !

      Posté par  . Évalué à 2.

      Donc ton test est hautement dépendant du nombre de process qui tournent, il va probablement être considéré comme non interactif par le noyau, donc pas forcément favorisé au niveau du scheduling, et le résultat va plafonner à 1000 sur un linux vu qu'il me semble que c'est le nb maximum de changemnet de process par seconde...

      • [^] # Tout à fait...

        Posté par  . Évalué à 0.

        ...et c'est bien pour ça qu'il faut lancer le test avec le moins de process possibles qui tournent (bien qu'en théorie un process en attente ne prend rien du tout).

        S'il plafonne à 1000... eh bien c'est dommage, parce que quand on a une bécane à 3 Ghz, ça fait 3 millions de cycles d'horloge entre deux changements de process, ce qui est tout bonnement énorme.

        Peut-être aussi que la limite vient de l'architecture x86, pas fichue de dépasser le kilohertz.

        • [^] # Re: Tout à fait...

          Posté par  . Évalué à 2.

          Oula, on se calme :)
          Le 1000 c'est une constante hardcodée dans Linux.
          Pourquoi ? Parce que quand t'as une interruption qui se déclenche, il faut la traiter, alors que tu aurais pu faire autre chose à la place de ce traitement. Ensuite, si tu dois changer de processus actif, c'est pareil, ça a un coût, c'est pas immédiat. Il faut donc trouver un équilibre entre la fréquence à laquelle tu t'autorises à changer de processus, et le coût de ce changement de processus. Si tu as la possibilité de changer de processus actif toutes les microsecondes, mais que le cout de ce changement est aussi de l'ordre de la microseconde, c'est pas très rentable.

          • [^] # Re: Tout à fait...

            Posté par  . Évalué à 0.

            Hardcodée dans Linux, le 1000 ? Peut-être. N'empêche que 10000 marcherait aussi bien sur une machine actuelle, non ?
            On devrait multiplier cette valeur par 10 à chaque fois que la vitesse des machines est multipliée par 10. Or c'est loin d'être le cas, il me semble ?

            Et une microseconde sur une machine à 3Ghz, c'est tout de même 3000 cycles d'horloge. S'il faut tout ça pour changer de process, c'est qu'il y a un truc qui ne va pas quelque part.

            De plus, entre une microseconde et une milliseconde, il y a un facteur de 1 à 1000, on a de la marge...

            • [^] # Re: Tout à fait...

              Posté par  . Évalué à 2.

              changement de process, ça implique probablement que la plupart de tes caches se retrouvent invalidés, rien que ça c'est super coûteux. 3000 cycles d'horloge, c'est pas grand chose non plus si tu prends en compte tout le "book keeping" qu'il y a à faire (récupérer l'interrupt timer, mettre à jour les diverses structures en rapport avec le temps, choisir un process à activer, changer le processus actif, mettre à jour les diverses tables utilisées par le scheduler, ...). Tu arrives super rapidement à tes 3000 cycles pour faire tout ça

              • [^] # Re: Tout à fait...

                Posté par  . Évalué à 2.

                http://kerneltrap.org/node/view/464(...) et http://kerneltrap.org/node/view/1766(...) si tu veux des explications plus précises (et moins fausses) que les miennes)

                • [^] # Re: Tout à fait...

                  Posté par  . Évalué à 0.

                  M'ouais, ça veut dire que la réactivité est dépendante du timer système.

                  C'est à dire que quand un process (ou un thread) devient idle, le reste de sa "time slice" est tout bonnement perdu.

                  Pourquoi ne pas passer à un autre process directement et relancer une nouvelle tranche de temps à partir de là ? C'est à dire, reset du timer ? Au lieu de perdre son temps à ne rien faire en attendant la prochaine interruption...


                  Au fait, petite info rigolote.
                  Un vieux 68000 à 8 Mhz comme il y en a dans un Atari St de 1985 est capable de monter à 16000 ints/sec et plus. Soit une interruption tous les 500 cycles d'horloge.
                  Les PC actuels sont sensés être combien de fois plus rapides ?

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.