Forum Programmation.python Javascript plus rapide que python !

Posté par  .
Étiquettes :
3
1
juil.
2010

Bonjour,

Tout à fait au hasard j'ai put remarquer que Javascript (plus particuliérement sur firefox que sur chrome) est bien plus rapide que python (CPython)

Version python

for a in xrange(2,10000):
sa=1
for d in xrange(2,a-2):
if a%d==0: sa+=d
b,sb=sa,1
for d in xrange(2,b-2):
if b%d==0: sb+=d
if sb==a and a<b:
print a,b


Version javascript

for(a=2;a<=20000;a++)
{
sa=1;
for(d=2;d<=a-2;d++) {if (a%d==0) sa=sa+d}
b=sa ; sb=1;
for(d=2;d<=b-2;d++) {if (b%d==0) sb=sb+d}
if (sb==a && a<=b)
{if(!confirm(a+" et "+b+" sont amicaux")) return};
}


Vous pouvez tester la version js ici : http://serge.mehl.free.fr/anx/nb_amic.html
Mais pourtant :[http://shootout.alioth.debian.org/gp4/benchmark.php?test=all(...)]

Ici je ne démontre strictement rien,et je pense que la domination sur le web de javascript à poussé à develloper de meilleurs moteurs,car les deux language se ressemblent mais leur diffusion est differente.
  • # Petite erreur

    Posté par  . Évalué à 1.

    les derniéres ligne du code python sont

    if sb==a and a<=b:
    print a,b
    • [^] # Re: Petite erreur

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

      Non.

      les derniéres ligne du code JavaScript sont

      if (sb==a && a<b)
      {if(!confirm(a+" et "+b+" sont amicaux")) return};



      Car a et b ne peuvent pas être amicaux si a = b…
      • [^] # Re: Petite erreur

        Posté par  . Évalué à 2.

        yep mais je voulais que le code javascript soit rapidement testable et donc calquer le code python dessus
  • # yach.....

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

    effectivement.......
    23s en python....
  • # psyco

    Posté par  . Évalué à 8.

    pour comparer du comparable, il faudrait peut-être commencer par utiliser psyco... ici, je passe de 25,3s à 2,3s.
    • [^] # Re: psyco

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

      psyco ? Ce truc révolutionnaire qui améliore python mais que je n'ai jamais pu utiliser car uniquement X86 ? Ah oui effectivement, dans ce cas autant comparer flash à javascript… ( j'ai pas pu attendre demain, dzl)
      • [^] # Re: psyco

        Posté par  . Évalué à 7.

        Primo, la plupart des interpréteurs Javascripts modernes utilisent un JIT très souvent limités au x86:
        * SpiderMonkey (interpréteur javascript inclus dans Gecko): tu as TraceMonkey qui ajoutes la compilation native (FF 3.5+) uniquement pour x86 32 bits (c'est encore expérimental pour le 64 bits)
        * v8 (Chromium): JIT x86 only
        * SquirrelFish Extreme aka Nitro (WebKit): JIT x86 32 bits only

        Donc c'est pas si stupide que ça de vouloir comparer avec psyco.

        J'ai fais rapidement l'expérience avec gjs (basé sur SpiderMonkey) et CPython 2.6, je trouve pour le premier 28s (sans affichage console, l'introspection GLib est pété), et pour le second 14.26s. Avec V8 c'est 4.7s mais c'est du JIT derrière.
        • [^] # Re: psyco

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

          Pour V8, si tu regardes le code, ils génèrent de l'ARM aussi.
          Mais je sais pas si c'est activé..

          « Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker

          • [^] # Re: psyco

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

            Pour android sans doute?
            • [^] # Re: psyco

              Posté par  . Évalué à 3.

              Peut-être à long terme, mais le navigateur disponible sous Android n'utilise pas la base Chromium. En revanche, ChromeOS est sensé supporter la plateforme ARM.
  • # Et avec numpy

    Posté par  . Évalué à 2.

    Il faudrait utiliser un des modules python pour le calcul scientifique, afin de pouvoir pertinemment critiquer la lenteur de python. Un volontaire ?

    Systemd, the bright side of linux, toward a better user experience and on the road to massive adoption of linux for the desktop.

    • [^] # Re: Et avec numpy

      Posté par  . Évalué à 4.

      Je n'ai pas l'impression que la finalité du calcul soit importante. Le but est juste de comparer des grosses boucles.

      Envoyé depuis mon lapin.

      • [^] # Re: Et avec numpy

        Posté par  . Évalué à 4.

        C'est vrai que si on conmmence à sortir l'artillerie python ,javascript ne fait pas long feu
  • # Ça dépend

    Posté par  . Évalué à 5.

    Chez moi :
    * Python : 23,47s
    * Javascript : 42s (en gros)

    Je suis en amd64, donc sans JIT, c'est ça qui doit faire la différence ...
    • [^] # Re: Ça dépend

      Posté par  . Évalué à 5.

      Javascript : 42s
      Ca fait visiblement une différence car sur mon Sempron d'il y a 4 ans ça ne met que 12 secondes :-)
    • [^] # Re: Ça dépend

      Posté par  . Évalué à 2.

      C'est quoi ton navigateur?

      Parce que même firefox 3 s'en tire tranquille ( et ya rien à voir avec ton architecture amd64 je pense)
      • [^] # Re: Ça dépend

        Posté par  . Évalué à 2.

        Iceweasel 3.5.10. Et le JIT n'est pas activé puisque ça n'est pas encore implémenté en dehors des bêta pour amd64.
  • # [HS] algo

    Posté par  . Évalué à 6.

    c'est toujours délicat de comparer deux langages en traduisant directement l'implémentation d'une syntaxe dans une autre.
    
    accessoirement, ça va pas faire avancer beaucoup le débat, mais là, l'algo est tellement inefficace qu'il *fallait* que j'en écrive un autre :)
    
    
    NB_ENTRIES = 20000
    d = [1] * NB_ENTRIES
    
    for i in xrange(2, NB_ENTRIES / 2):
            for j in xrange(2 * i, NB_ENTRIES, i):
                    d[j] += i
    
    print [sorted((i, d[i])) for i in xrange(0, len(d)) if d[i] < NB_ENTRIES and d[d[i]] == i and i <= d[i]]
    
  • # À mon tour !

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

    C'est vendredi ! À mon tour de troller !

    % time python loop.py
    6 6
    28 28
    220 284
    496 496
    1184 1210
    2620 2924
    5020 5564
    6232 6368
    8128 8128
    python loop.py 36.03s user 0.00s system 98% cpu 36.459 total

    % cat loop.cl
    (loop for a from 2 to 10000
    do
    (let ((sa 1))
    (loop for d from 2 to (- a 2)
    do
    (when (= 0 (mod a d))
    (incf sa d)))
    (let ((b sa)
    (sb 1))
    (loop for d from 2 to (- b 2)
    do
    (when (= 0 (mod b d))
    (incf sb d)))
    (when (and (= sb a) (<= a b))
    (format t "wesh ~a and ~a" a b)))))

    time sbcl --noinform < loop.cl
    * wesh 6 and 6wesh 28 and 28wesh 220 and 284wesh 496 and 496wesh 1184 and 1210wesh 2620 and 2924wesh 5020 and 5564wesh 6232 and 6368wesh 8128 and 8128
    NIL
    * sbcl --noinform < loop.cl 2.23s user 0.02s system 98% cpu 2.279 total


    Bon, ben je suis toujours content d'utiliser CL le vendredi.
  • # j'en rajoute

    Posté par  . Évalué à 1.


    gcc
    1.444s
    gcc -O3
    0.914s
    java
    1.379s
    java -Xint
    7.779s

    sur un P8600 2.14GHz sous ouinouin.
    • [^] # Re: j'en rajoute

      Posté par  . Évalué à 2.

      Et en compilant une fois par gcc -fprofile-generate -O3 toto2.c puis en recompilant après avoir lancé le programme une fois par gcc -fprofile-use -O3 toto2.c on gagne encore 10% environ grâce à la profile-guided optimization.
  • # DÉMODÉ

    Posté par  . Évalué à 1.

Suivre le flux des commentaires

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