4 ms·

The Python code is terrible. That's not how you code in Python. Also, this implementation seems to take more than 32 GB on my machine. Here is a refactor: https

by lqdc13 13y ago

The Python code is terrible. That's not how you code in Python. Also, this implementation seems to take more than 32 GB on my machine. Here is a refactor: https://gist.github.com/lqdc/9149772 https://gist.github.com/lqdc/9149772 Anyway, this problem should not be solved this way in python either way. I would have stored everything in a Pandas table and computed stuff from there.

logicchains 13y ago
Thanks! I'm rerunning it and updating the tables progressively every few hours as optimisations are suggested. Feel free to make a pull request. Ideally within a day or so the implementations will have all been optimised enough to make for fairer comparison. I understand that a Pandas table would be a better idea, but the purpose of this benchmark is comparing the speed of the raw languages.
- lqdc13 13y ago
  Also there is integer overflow in the C code and maybe others because the sum doesn't fit in 64 bit integer.
  - logicchains 13y ago
    It mentions that later in the post. The implementations in the final two tables use bignums for fairness and to avoid overflow.
- lqdc13 13y ago
  I updated with a pandas script as well. I think the strength of the languages have in part to do with their libraries. You have to pick the right tools for the right task. The pandas version runs 3x faster than regular python, but 17x slower than C.
  - logicchains 13y ago
    Great, I'll include that in the next run of the benchmark. Is it Python 3 or 2? (Does it work with Pypy) Also, if you're comparing it to C you should compare it to C3.c, from the final tables, which uses bignums like Python does automatically. *Edit: I tried your faster_py.py, but it didn't seem any faster than Pypy2.py in the repo (running both with Pypy). I haven't yet got the Pandas version to work due to library compatibility issues (I've got about five versions of Python installed; still working on it).
    - lqdc13 13y ago
      It's about 2x faster in regular CPython 2.7 on my machine. In pypy it is actually way slower than your original one. In many cases, pypy cannot be used, because it's not compatible with all the libraries.
      - logicchains 13y ago
        Ah, right. I've included your version (converted to Python 3) as Python3_fst; it's around twice as fast as regular CPython 3.3.

by lqdc13 13y ago

logicchains 13y ago

Thanks! I'm rerunning it and updating the tables progressively every few hours as optimisations are suggested. Feel free to make a pull request. Ideally within a day or so the implementations will have all been optimised enough to make for fairer comparison. I understand that a Pandas table would be a better idea, but the purpose of this benchmark is comparing the speed of the raw languages.

lqdc13 13y ago
Also there is integer overflow in the C code and maybe others because the sum doesn't fit in 64 bit integer.
- logicchains 13y ago
  It mentions that later in the post. The implementations in the final two tables use bignums for fairness and to avoid overflow.
lqdc13 13y ago
I updated with a pandas script as well. I think the strength of the languages have in part to do with their libraries. You have to pick the right tools for the right task. The pandas version runs 3x faster than regular python, but 17x slower than C.
- logicchains 13y ago
  Great, I'll include that in the next run of the benchmark. Is it Python 3 or 2? (Does it work with Pypy) Also, if you're comparing it to C you should compare it to C3.c, from the final tables, which uses bignums like Python does automatically. *Edit: I tried your faster_py.py, but it didn't seem any faster than Pypy2.py in the repo (running both with Pypy). I haven't yet got the Pandas version to work due to library compatibility issues (I've got about five versions of Python installed; still working on it).
  - lqdc13 13y ago
    It's about 2x faster in regular CPython 2.7 on my machine. In pypy it is actually way slower than your original one. In many cases, pypy cannot be used, because it's not compatible with all the libraries.
    - logicchains 13y ago
      Ah, right. I've included your version (converted to Python 3) as Python3_fst; it's around twice as fast as regular CPython 3.3.