un bench curieux sur la copie de blocs mémoire

Posté par  (site web personnel) . Édité par Benoît Sibaud. Modéré par dumonteil jerome.
Étiquettes : aucune
0
25
juin
2001
Linux
Dans cet article, l'auteur a eu la curieuse idée de comparer la vitesse d'exécution d'un petit programme de copie de blocs mémoire de 16Mo sous linux et sous windows 2000. Et les résultats sont a priori surprenants: la copie de mémoire est plus rapide (~170Mo/s) sous linux que sous win2k (entre 93 et 132Mo/s selon la méthode de copie). Alors que le code généré par les compilateurs est le même sous linux et sous windows. Sa conclusion est qu'il ne sait pas comment expliquer cette différence. Ma conclusion à moi, c'est que [dans cette configuration] linux gère mieux les pages mémoire que win...

Aller plus loin

  • # debat ou troll

    Posté par  . Évalué à 0.

    je vois pas le detail de ces machines...

    Linux (avec ou sans X+interface...)

    Windows (avec ou sans programme deja lancé... juste apres un reboot...)

    OK g lu rapidement... mais qd meme

  • # au sujet de la gestion de la memoire

    Posté par  . Évalué à 0.

    chez moi le swap est souvent entre 20 et 60 % même si la memoire est à 60% (380M ) !!
    kernel 2.4.5-ac17 (ac9 aussi )
    vous trouvez ca normal ?

    • [^] # Re: au sujet de la gestion de la memoire

      Posté par  . Évalué à 0.

      Non, pas du tout. Chez moi le swap commence à se remplir quand la RAM est pleine à + de 90%...
      Ceci pour les tout les kernel 2.0.x et 2.2.x

      • [^] # Re: au sujet de la gestion de la memoire

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

        >Non, pas du tout.
        Efface.

        • [^] # Re: au sujet de la gestion de la memoire

          Posté par  . Évalué à 0.

          tu peux preciser ?

          • [^] # Re: au sujet de la gestion de la memoire

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

            # swapoff

          • [^] # ah non, pas du tout. efface.

            Posté par  . Évalué à -1.

            Private joke. Si tu veux comprendre, il faut que tu sache qu'il y a quelque temps, DaCode ne gérait pas le changement automatique des fortunes, ces petits textes qui apparaissent en bas de page.

            Donc, pendant plusieur mois, on a eu droit à un extrait de tchatche (je n'arrive pas à écrire un "extrait de chat" sans penser à des misères faites à de sympathiques bestioles miaulantes) qui était, de mémoire:

            folop> y'a un fichier de 61 mo dans /proc, c'est normal ?
            mooby> ah non, pas du tout
            mooby> efface

            Voila, voila. Ensuite, on a eu droit après de très insistantes demandes à un texte ou Bartman expliquait qu'il faisait de l'IRC avec un client en Perl, que ça marchait bien :-), et immédiatement après après on voyait
            --|-- Signoff Bartman (dead socket).

            Enfin, il y eu une obscure histoire de carte vidéo branchée sur le port série, et peut-être une autre, puis les fortunes sont devenues dynamiques.

            Mais les vieux de la vielles se souviennent avec émotion des jours où Folop, Bartman et les autres héros qui ont bercé notre enfance illuminaient les jours de ce site.

            Bon, on les voit encore de temps en temps, mais ils sont noyés dans la masse.

            En tout cas, tu as ta réponse à cette angoissante question, pourquoi demande t'on d'effacer quand quelqu'un dit "ah non, pas du tout".

            L'humour nerd est une chose fascinante...

            (Hop, en -1 car c'est très hors-sujet.)

    • [^] # Oui...

      Posté par  . Évalué à 1.

      pour moi, AMHA c'est normal. Si tu lance une grosse appli ca partira beaucoup plus vite parce que tu aura de la ram de libre. Le transfert ayant été fait avec du temps CPU résiduel, pas de blème!

      Et franchement, y'a toujours un petit paquet de démons qui servent tous les 36 du mois qui sont mieux en swap... Peut être as-tu un bon paquet de ces petits démons. Quand on boote une distro toute fraiche, on a même un pandemonium...

    • [^] # Re: au sujet de la gestion de la memoire

      Posté par  . Évalué à 0.

      J'ai le même probléme. Si tu trouve une solution pour que la RAM soit plus remplit que 60% je suis interressé car j'ai le probléme avec un vieux poste avec 48Mo et l'accés à la swap ralenti considérablement le systéme....

      • [^] # Re: au sujet de la gestion de la memoire

        Posté par  . Évalué à 0.

        moi j'ai mis mon swap dans un ramdisk ... et ops ...
        plus de problème !

        • [^] # Re: au sujet de la gestion de la memoire

          Posté par  . Évalué à 0.

          Les plaisanteries de ce type devraient être assorties d'un smiley car ça risque de donner de mauvaises idées à quelques naïfs.

          Tu en doutes ? Et bien sache qu'on m'a déjà fait cette suggestion. Si, si.

          Xavier

    • [^] # Re: au sujet de la gestion de la memoire

      Posté par  . Évalué à 0.

      Moi aussi
      Mais je ne men plein pas car jai tres tres rarement des acces swap
      en effet linux met swap ce que tu n'utilises pas (notament ceratins serv/daemons) ce qui est plutot bien

    • [^] # Re: au sujet de la gestion de la memoire

      Posté par  . Évalué à 1.

      le 2.4.5 est certainement le kernel le plus buggé de la série 2.4 en ce qui concerne la memoire virtuelle

      je suis encore au 2.4.3 et je n ai pas rencontré de telles occupation de swap

      un ami avec le 2.4.5 se plaint de swap massif, voir de trash swap alors qu il a 512mo

      c un probleme pris au serieux par les developpeurs linux

      le 2.4 ne brille pas par ses performances pour nettoyer le swap. le 2.4.6 est censé améliorer ca , (enfin disons que c une premiere amélioration prévue a ce que j'ai lu)

  • # Oui, c'est un bench à la con

    Posté par  . Évalué à 0.

    Que testait-il ? Les machines ou les OS ?
    Passk'avec la MMU, les caches CPU, le resource-tracking, le multi-tâches, tester ce qui se passe vraiment est illusoire. En effet, les context-switches et le quantum ont sûrement une importance dans la vitesse des benchs ...
    Il prétend que le code pondu est identique, mais pourquoi a t'il utilisé c++ ? L'assembleur me semblait plus judicieux, il aurait eu un code complètement identique (sauf le seg-loader).
    Bref, c'est toujours la même chose : Tous les benchs pour les systèmes à mémoire protégée sont faux, qu'on se le dise.

    • [^] # Re: Non, c'est juste un bench

      Posté par  . Évalué à 0.

      Comme il s'agit du meme source, on considere donc la plateforme software : compilateur + OS. gcc+linux vs win+vc.
      Par contre, pour mesurer reellement les temps, il devrait utiliser RDTSC, cela prendra en compte tout les temps.

      La ou son truc n'a pas beaucoup de valeur, c'est concernant les debits retournes. Avec un codage different, il peut avoir des valeurs tout autre (utilisation de QMOV et de prefetch).

      nicO

  • # Et le context switching ??

    Posté par  . Évalué à 0.

    J'aimerai bien avoir accès à des benchmarks systèmes 'sérieux' pour pouvoir dire à des clients : notre environnement tournera plus vite sur un Unix plutot que sous Win32 car il est de fait plus efficace

    Mon context : EJB / Java. Bref, du très haut niveau, loin de l'OS. Peut-on mettre la JVM en cause. J'en doute. Mon problème vient d'échange de messages sur socket (loopback en ce qui concerne mon test)... WinNT perd visible son temps dans le context switching.
    Le principe : envoie d'un message, et réception d'un ACK en retour (niveau Java). Si on enlève l'envoi du ACK au protocole, on voit très très peu de différence sous Linux mais NT semble avoir des ailes qui lui poussent comparé à la version avec ACK.
    Etrange n'est-ce pas...

    Existent-ils donc des VRAIS benchmarks ?
    Sur l'utilisation de la mémoire, des sockets, ou ce genre de choses ?

    • [^] # Re: Et le context switching ??

      Posté par  . Évalué à 0.

      C'est ce que je me demandais dans le post anonyme (bench à la con).
      Dans la mesure où on ne peut pas gérer le time-slice (quantum) il se peut que Linux soit paramétré pour un quantum de 100ms, et NT pour une autre valeur. Mon Amiga a un quantum de 3ms. Il est donc prévu pour faire du context-switch intensif, mais ce n'est peut-être pas le cas de Linux ni de NT. De plus j'ai, par exemple, un algo de scheduling qui est dynamique, alors pour ce qui est de mesurer le temps ...
      Sans compter la ligne de pseudo-code ci-dessous :
      (admettons un CPU avec un CACHE)
      >charge ma_valeur dans mon_adr
      >charge ma_valeur dans mon_adr2
      >teste le dernier bit de la valeur dans mon_adr
      >teste le dernier bit de la valeur dans mon_adr2
      est plus rapide que :
      >charge ma_valeur dans mon_adr
      >teste le dernier bit de la valeur dans mon_adr
      >charge ma_valeur dans mon_adr2
      >teste le dernier bit de la valeur dans mon_adr2
      (ben oui !)

      Ais-je tord ?

      • [^] # Re: Et le context switching ??

        Posté par  . Évalué à 0.

        Oui, mais cela ne change rien au bench qui utilise le meme code C dans les 2 cas.

        nicO

      • [^] # Re: Et le context switching ??

        Posté par  . Évalué à 0.

        > Ai-je tort ?

        Oui, si tu prends le temps de lire l'article, tu verras que l'auteur s'est posé les mêmes questions et qu'il a fait un bench sur du calcul pur, sans transfert de blocs mémoires (calcul fractal).

        Résultat:
        Linux 2.2.16-22 ..... 4.065
        Linux 2.4.4 ......... 4.087
        Windows 2000 AS ..... 4.300

        La différence n'est plus la même...

        Quoiqu'il en soit, pour répondre à la question initiale, l'auteur de l'article n'ayant procédé à aucune optimisation particulière (fonction memcpy() classique) on peut en déduire qu'un programme faisant un usage intensif de transferts de blocs mémoires aura intérêt à tourner sur Linux x86 s'il n'a pas été optimisé pour une plateforme particulière.

        Xavier

  • # bravo l'auteur

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

    Y'a des news on se demande qui les a ecris.
    Genre la, ce qui m'amuse, c'est le "Ma conclusion à moi, c'est que [dans cette configuration] linux gère mieux les pages mémoire que win... ".
    Tu l'as trouvé tout seul ou qqun t'as expliqué ?
    moi perso ma conclusion c'est que le bench est favorable a linux. t'as vu, moi aussi je fait des conclusions interessantes.

    • [^] # Re: bravo l'auteur

      Posté par  . Évalué à 0.

      Surtout que la différence constatée n'a sans doute rien à voir avec la gestion des pages mémoires.

      Linux x86 a une version optimisée de la copie mémoire par memcpy (copie avec des instructions MMX ou 3Dnow ou ? je ne sais plus) alors que l'auteur de l'article constate clairement que les copies sous Win2k se font élément par élément (char par char, short par short, etc.).

      Pour moi, ce bench vaut ce qu'il vaut mais il est probant, l'auteur ayant vérifié que des paramètres comme la charge cpu (ou le time-slice ou quoi que ce soit) n'avaient pas d'influence significative sur le résultat.

      Xavier

    • [^] # Re: bravo l'auteur

      Posté par  . Évalué à 0.

      Sans compter que dans l'édito de l'article, l'auteur du test dit :
      Sur Wnt la taille de page est 4Ko, sur Linux aussi.
      Ah Ah.
      C'est dans le CPU ça, pas dans l'OS.
      Oublions ce post, ce bench, consacrons nous à autre chose.

    • [^] # Re: bravo l'auteur

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

      C'est moi qui l'ai écrite gros malin. Quand à la conclusion vaseuse, je l'ai faite puisque l'auteur de l'article refuse de se mouiller, et elle ne me semble pas forcement si triviale, surtout (je ne suis un kerner hacker ni un warlordz de la demoscene) qu'elle depend quand même de la taille des blocs copiés.

      'tain il m'a vexé :(

  • # pamela si tu es blonde ...

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

    à forte poitrine, je t'aime aussi ...
    et pas seulement pour tes bench débiles ;o)

Suivre le flux des commentaires

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