4 ms·

I wonder if the time.time is the slow part there? Maybe worth doing a busy look for say 5 million iterations, timing that then doing the calculation for loops

I wonder if the time.time is the slow part there? Maybe worth doing a busy look for say 5 million iterations, timing that then doing the calculation for loops per second.

lucb1e 8y ago
I'm sure it is a thousand times slower than i++, but it should be the same code on each platform. But you made me think: indeed, the underlying call could be slower from JS whereas from pypy/python{2,3} it's fast (or vice versa). So I just tested a version where it checks how long ten million iterations take (n=3). Code here: https://hastebin.com/uyuhecabek.py https://hastebin.com/uyuhecabek.py browser/pypy 5.25 seconds python 3.6.6 2.16 seconds python 3.7.0 2.08 seconds python 2.7.15 1.42 seconds pypy 6.0.0 0.01 seconds Since there is no syscall to be made, pypy can do this in compiled code and is blazingly fast (I bet C/assembly isn't much faster there), and the rest seems comparable to the previous estimate: the browser version is 2.25× slower compared to python3 (now 2.43×) and 3.33× slower compared to python2 (now 3.70×).
- alexchamberlain 8y ago
  I'm surprised it's that different; in the optimum case, it feels like a several layers of JITing interpreter should get to the same performance in the end. Might not be enough to trigger it I guess.
  - chmod775 8y ago
    I can't see the code because I'm on mobile, but if the JIT is function based and you're only calling the benchmarked function once it may not have it optimized for your first call. It certainly can't replace the instructions mid-loop. Edit: SO answer explaining the PyPy JIT: https://stackoverflow.com/questions/37377787/what-kind-of-jit-compiler-is-used-by-pypy https://stackoverflow.com/questions/37377787/what-kind-of-ji...
- aroberge 8y ago
  Tested on Brython (with Firefox) - http://www.brython.info/tests/editor.html?lang=en http://www.brython.info/tests/editor.html?lang=en Iteration 0 took -0.9660000801086426s Iteration 1 took -0.9519999027252197s Iteration 2 took -0.9499998092651367s It is about 10 times slower with Chrome on my computer.
  - lucb1e 8y ago
    Wow. That makes a huge difference. Iteration 0 took 0.6579999923706055s Iteration 1 took 0.6540000438690186s Iteration 2 took 0.6460001468658447s (I noticed the code from hastebin was an old version, I forgot to swap the starttime-time.time() in the version I posted. Not that it matters much, just change the sign.) Running it on OP's website again just to be sure, it now takes 4.9 seconds instead of 5.25, so there is some variance there, but this is still a big difference. This is Firefox as well (see another comment in this subthread), I don't have Chromium installed.
- gengkev 8y ago
  Are you sure pypy didn't just optimize out the loop entirely (as an aggressive C compiler would have done)?

I wonder if the time.time is the slow part there? Maybe worth doing a busy look for say 5 million iterations, timing that then doing the calculation for loops per second.

lucb1e 8y ago

I'm sure it is a thousand times slower than i++, but it should be the same code on each platform. But you made me think: indeed, the underlying call could be slower from JS whereas from pypy/python{2,3} it's fast (or vice versa). So I just tested a version where it checks how long ten million iterations take (n=3). Code here: https://hastebin.com/uyuhecabek.py https://hastebin.com/uyuhecabek.py browser/pypy 5.25 seconds python 3.6.6 2.16 seconds python 3.7.0 2.08 seconds python 2.7.15 1.42 seconds pypy 6.0.0 0.01 seconds Since there is no syscall to be made, pypy can do this in compiled code and is blazingly fast (I bet C/assembly isn't much faster there), and the rest seems comparable to the previous estimate: the browser version is 2.25× slower compared to python3 (now 2.43×) and 3.33× slower compared to python2 (now 3.70×).

alexchamberlain 8y ago
I'm surprised it's that different; in the optimum case, it feels like a several layers of JITing interpreter should get to the same performance in the end. Might not be enough to trigger it I guess.
- chmod775 8y ago
  I can't see the code because I'm on mobile, but if the JIT is function based and you're only calling the benchmarked function once it may not have it optimized for your first call. It certainly can't replace the instructions mid-loop. Edit: SO answer explaining the PyPy JIT: https://stackoverflow.com/questions/37377787/what-kind-of-jit-compiler-is-used-by-pypy https://stackoverflow.com/questions/37377787/what-kind-of-ji...
aroberge 8y ago
Tested on Brython (with Firefox) - http://www.brython.info/tests/editor.html?lang=en http://www.brython.info/tests/editor.html?lang=en Iteration 0 took -0.9660000801086426s Iteration 1 took -0.9519999027252197s Iteration 2 took -0.9499998092651367s It is about 10 times slower with Chrome on my computer.
- lucb1e 8y ago
  Wow. That makes a huge difference. Iteration 0 took 0.6579999923706055s Iteration 1 took 0.6540000438690186s Iteration 2 took 0.6460001468658447s (I noticed the code from hastebin was an old version, I forgot to swap the starttime-time.time() in the version I posted. Not that it matters much, just change the sign.) Running it on OP's website again just to be sure, it now takes 4.9 seconds instead of 5.25, so there is some variance there, but this is still a big difference. This is Firefox as well (see another comment in this subthread), I don't have Chromium installed.
gengkev 8y ago
Are you sure pypy didn't just optimize out the loop entirely (as an aggressive C compiler would have done)?