6 ms·

Using a Numpy-based program as an example of how Python can be fast is a bit strange. It shows that Python can be fast enough if you leave the heavy computatio

by Wilya 12y ago

Using a Numpy-based program as an example of how Python can be fast is a bit strange. It shows that Python can be fast enough if you leave the heavy computational parts to libraries written in other languages. Which is interesting, but doesn't say much about the speed of Python itself.

pekk 12y ago
It isn't strange, it's standard practice. What would be strange is to force Python to hold one hand behind its back and be used in a totally unrealistic way that doesn't reflect normal practice. And by strange I mean basically dishonest about the performance available when using Python.
- izacus 12y ago
  Well, yes and no. Python apps CAN be fast. Python itself isn't. It's dishonest to do a NumPy benchmark to show how "Python" is fast if the article implies that all code written in pure Python will be as fast. Then newbies will come, try to write fast algorithms and find out, they have to rewrite them in a faster language to get that advertised performance.
  - pekk 12y ago
    If someone wants to do the kinds of computations done by NumPy, what's relevant is how fast that actual practice is. Not some stupid alternative implementation intended to show that Python is slow, but which nobody would ever actually use. In other words, it's nonsense to discard Python with NumPy as an option for fast computations just because we can imagine an imaginary world where NumPy was written differently, purely to penalize this environment for having used more than one language. To be honest, we should benchmark what we actually have, not imaginary made-up handicapped versions of the things we are judging.
- stefantalpalaru 12y ago
  > the performance available when using Python The honest thing would be to say "yes, Python is slow, but you can use some fast modules written in C". You can even go farther and say that if you're going to use Python for non-trivial projects you better learn C (or some C generator like Cython).
  - pekk 12y ago
    The ubiquitous implementation of Python is written in C. So, for example, the list-sorting algorithm is written in C. If you want to eliminate C from the equation completely, I guess we now have to rewrite the C sort algorithm to be slower to show off "how slow Python really is" in isolation from C. But this is a benchmark of a fantasy world. That Python isn't the real Python we use. In the real world Python is not in isolation from C, by design, and this works well.
    - stefantalpalaru 12y ago
      No. The language in which the interpreter is written is not the point here. The point is the interpretation overhead of the best (or "only" if we're being pedantic since Python is de facto whatever CPython does) interpreter. That overhead is the price you pay for using Python so it's what matters when you compare languages for CPU bound projects.
      - maxerickson 12y ago
        It's a little strange to insist that CPython is the only Python interpreter and then reject all the C libraries that you can access for performance (because those C libraries are the big loss when shifting from CPython 2.7 to Pypy). I think interpreter overhead and language ecosystem performance are probably best looked at as separate questions.
  - calpaterson 12y ago
    You only need to know C to get fast Python code for a tiny minority of situations. For one, most interesting C wrappers have already been written and second, the majority of C code you will use in normal business software contexts isn't used by FFI. For a normal web application the request flow goes something like: nginx (WSGI) -> uwsgi -> web application code -> psycopg2 driver -> postgres. Only the web application part is written in Python, so for practical purposes you actually have a C stack that uses Python for business logic. Loads of libraries, from json parsers to templating libraries include optional C code for speedups.
wffurr 12y ago
You didn't read the thread. The OPs code used very small arrays and using numpy was slowing the code down by an order of magnitude. The pure python solution is 17x faster.
omaranto 12y ago
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 12y 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 12y 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 12y 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 12y 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.
illumen 12y ago
Yet, numpy exists for python, so why can't you use it in a comparison? Why can't you use libraries for languages? The python approach is all about gluing bits together, not staying within a pure walled garden. Also, python is not an implementation of python. These benchmarks are always funny, because real systems use different components, yet the benchmarks stick to some fake, non-real-world way of measuring. Oh, the garbage collection in java pauses for multiple seconds soemtimes... but it's not slow because we ignore that in our benchmarks. Oh, it's not fast the first time, because the jit hasn't warmed up? Let's ignore that in our benchmarks too. Um... yeah. Good one. This benchmark is also flawed to since people would probably use numexpr in the real world. Which is much faster than plain numpy. So python would be even faster than they say. Mercurial(hg) is now faster than git. Git is written by great C hackers (including Linus no less), and yet hg is faster than git. See the facebook benchmarks for evidence. Using the right tool for the job can mean using multiple languages together for where they are best. Want clarity and performance? Then C/asm + python is an ok combination.
- scrollaway 12y ago
  It's worth noting that someone replied with a pure python implementation that was a lot faster: 0.283s.
njharman 12y ago
Python itself includes all the options; PyPy, Cython, Psyco, Numpy and other C extestions, Jython and more. It's all Python. That is one one of the strengths of Python. Would you exclude use of stdlib parts that are written in C? Would you say Javascript can't run serverside cause Node.js is not part of your imagined "core language"? Or it doesn't say much about the speed of C when you use a better/more optimized compiler or compiler flags?

by Wilya 12y ago

pekk 12y ago

It isn't strange, it's standard practice. What would be strange is to force Python to hold one hand behind its back and be used in a totally unrealistic way that doesn't reflect normal practice. And by strange I mean basically dishonest about the performance available when using Python.

izacus 12y ago
Well, yes and no. Python apps CAN be fast. Python itself isn't. It's dishonest to do a NumPy benchmark to show how "Python" is fast if the article implies that all code written in pure Python will be as fast. Then newbies will come, try to write fast algorithms and find out, they have to rewrite them in a faster language to get that advertised performance.
- pekk 12y ago
  If someone wants to do the kinds of computations done by NumPy, what's relevant is how fast that actual practice is. Not some stupid alternative implementation intended to show that Python is slow, but which nobody would ever actually use. In other words, it's nonsense to discard Python with NumPy as an option for fast computations just because we can imagine an imaginary world where NumPy was written differently, purely to penalize this environment for having used more than one language. To be honest, we should benchmark what we actually have, not imaginary made-up handicapped versions of the things we are judging.
stefantalpalaru 12y ago
> the performance available when using Python The honest thing would be to say "yes, Python is slow, but you can use some fast modules written in C". You can even go farther and say that if you're going to use Python for non-trivial projects you better learn C (or some C generator like Cython).
- pekk 12y ago
  The ubiquitous implementation of Python is written in C. So, for example, the list-sorting algorithm is written in C. If you want to eliminate C from the equation completely, I guess we now have to rewrite the C sort algorithm to be slower to show off "how slow Python really is" in isolation from C. But this is a benchmark of a fantasy world. That Python isn't the real Python we use. In the real world Python is not in isolation from C, by design, and this works well.
  - stefantalpalaru 12y ago
    No. The language in which the interpreter is written is not the point here. The point is the interpretation overhead of the best (or "only" if we're being pedantic since Python is de facto whatever CPython does) interpreter. That overhead is the price you pay for using Python so it's what matters when you compare languages for CPU bound projects.
    - maxerickson 12y ago
      It's a little strange to insist that CPython is the only Python interpreter and then reject all the C libraries that you can access for performance (because those C libraries are the big loss when shifting from CPython 2.7 to Pypy). I think interpreter overhead and language ecosystem performance are probably best looked at as separate questions.
- calpaterson 12y ago
  You only need to know C to get fast Python code for a tiny minority of situations. For one, most interesting C wrappers have already been written and second, the majority of C code you will use in normal business software contexts isn't used by FFI. For a normal web application the request flow goes something like: nginx (WSGI) -> uwsgi -> web application code -> psycopg2 driver -> postgres. Only the web application part is written in Python, so for practical purposes you actually have a C stack that uses Python for business logic. Loads of libraries, from json parsers to templating libraries include optional C code for speedups.

wffurr 12y ago

You didn't read the thread. The OPs code used very small arrays and using numpy was slowing the code down by an order of magnitude. The pure python solution is 17x faster.

omaranto 12y ago

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 12y 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 12y 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 12y 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 12y 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.

illumen 12y ago

Yet, numpy exists for python, so why can't you use it in a comparison? Why can't you use libraries for languages? The python approach is all about gluing bits together, not staying within a pure walled garden. Also, python is not an implementation of python. These benchmarks are always funny, because real systems use different components, yet the benchmarks stick to some fake, non-real-world way of measuring. Oh, the garbage collection in java pauses for multiple seconds soemtimes... but it's not slow because we ignore that in our benchmarks. Oh, it's not fast the first time, because the jit hasn't warmed up? Let's ignore that in our benchmarks too. Um... yeah. Good one. This benchmark is also flawed to since people would probably use numexpr in the real world. Which is much faster than plain numpy. So python would be even faster than they say. Mercurial(hg) is now faster than git. Git is written by great C hackers (including Linus no less), and yet hg is faster than git. See the facebook benchmarks for evidence. Using the right tool for the job can mean using multiple languages together for where they are best. Want clarity and performance? Then C/asm + python is an ok combination.

scrollaway 12y ago
It's worth noting that someone replied with a pure python implementation that was a lot faster: 0.283s.

njharman 12y ago

Python itself includes all the options; PyPy, Cython, Psyco, Numpy and other C extestions, Jython and more. It's all Python. That is one one of the strengths of Python. Would you exclude use of stdlib parts that are written in C? Would you say Javascript can't run serverside cause Node.js is not part of your imagined "core language"? Or it doesn't say much about the speed of C when you use a better/more optimized compiler or compiler flags?