3 ms·

Well, this particular example shows instead that the overhead of calling libraries written in other languages can be so large that a pure python solution can be

Well, this particular example shows instead that the overhead of calling libraries written in other languages can be so large that a pure python solution can be faster. The current top answer to the question shows a pure python version that is about 20 times faster, commenters explain that the arrays are so small that the overhead in calling numpy outweighs any avantage numpy's speed gives. http://codegolf.stackexchange.com/a/26337/3074 http://codegolf.stackexchange.com/a/26337/3074

algorias 13y ago
That 20x is hardly just because of numpy overhead, read the answer more carefully: > optimization by precomputing F values > I also optimize by skipping the rest of the convolution if the first result isn't zero. If you don't measure implementations of the same algorithm, you hardly have a fair language/library benchmark.
- kbenson 13y ago
  Measuring implementations of the same algorithm is how you benchmark algorithms, not a a language as a whole. If a language or library allows for enhancements based on it's strengths (in this case, the ability to code in early exits), those are perfectly valid in benchmarking languages and libraries. Put another way, one of the benefits of Python (and drawbacks of using an external library) is that you have more control over the algorithm and exactly what it does. That said, a sample size of one will hardly give you an accurate picture.
  - igouy 13y ago
    "Measuring implementations of the same algorithm is how you benchmark" that one algorithm. "Measuring implementations of [different] algorithms is how you benchmark algorithms"
    - kbenson 13y ago
      Yes, and in this case, we can think of pure Python and it's capabilities as one "algorithm", and calling out to a library as another.
      - igouy 13y ago
        That is probably not what readers of your comment understand by the word algorithm.
- omaranto 13y ago
  You're right, I wasn't careful. Without precomputing F, the speedup is only around 7x.

algorias 13y ago

That 20x is hardly just because of numpy overhead, read the answer more carefully: > optimization by precomputing F values > I also optimize by skipping the rest of the convolution if the first result isn't zero. If you don't measure implementations of the same algorithm, you hardly have a fair language/library benchmark.

kbenson 13y ago
Measuring implementations of the same algorithm is how you benchmark algorithms, not a a language as a whole. If a language or library allows for enhancements based on it's strengths (in this case, the ability to code in early exits), those are perfectly valid in benchmarking languages and libraries. Put another way, one of the benefits of Python (and drawbacks of using an external library) is that you have more control over the algorithm and exactly what it does. That said, a sample size of one will hardly give you an accurate picture.
- igouy 13y ago
  "Measuring implementations of the same algorithm is how you benchmark" that one algorithm. "Measuring implementations of [different] algorithms is how you benchmark algorithms"
  - kbenson 13y ago
    Yes, and in this case, we can think of pure Python and it's capabilities as one "algorithm", and calling out to a library as another.
    - igouy 13y ago
      That is probably not what readers of your comment understand by the word algorithm.
omaranto 13y ago
You're right, I wasn't careful. Without precomputing F, the speedup is only around 7x.