4 ms·

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 tha

by pekk 13y 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 13y 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 13y 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 13y 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 13y 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 13y 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 13y 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 13y 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.
  - stefantalpalaru 13y ago
    Guess where the bottleneck is when you need to generate a dynamic page for each and every request.
    - calpaterson 13y ago
      In the database? About 90% of bottlenecks boil down to something along the lines of "this query is slow" or "there are a lot of queries here". This has been true since the dotcom boom
      - stefantalpalaru 13y ago
        Guess again. All these benchmarks use the same database: http://www.techempower.com/benchmarks/#section=data-r8&hw=i7&test=query http://www.techempower.com/benchmarks/#section=data-r8&hw=i7...
        calpaterson 13y ago
        Those are fairly uselss synthetic benchmarks. How many apps do you have in production that are purely key value stores with a random access profile? And if you really have these performance characteristics (hint: it's unlikely), maybe it's time to get a edge caching CDN? Cutting 400ms of latency as you cross from Amsterdam to California is going to be the easiest performance boost you ever got
- deleted 13y ago
  [deleted]

by pekk 13y ago

izacus 13y 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 13y 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 13y 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 13y 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 13y 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 13y 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 13y 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.
- stefantalpalaru 13y ago
  Guess where the bottleneck is when you need to generate a dynamic page for each and every request.
  - calpaterson 13y ago
    In the database? About 90% of bottlenecks boil down to something along the lines of "this query is slow" or "there are a lot of queries here". This has been true since the dotcom boom
    - stefantalpalaru 13y ago
      Guess again. All these benchmarks use the same database: http://www.techempower.com/benchmarks/#section=data-r8&hw=i7&test=query http://www.techempower.com/benchmarks/#section=data-r8&hw=i7...
      - calpaterson 13y ago
        Those are fairly uselss synthetic benchmarks. How many apps do you have in production that are purely key value stores with a random access profile? And if you really have these performance characteristics (hint: it's unlikely), maybe it's time to get a edge caching CDN? Cutting 400ms of latency as you cross from Amsterdam to California is going to be the easiest performance boost you ever got
deleted 13y ago
[deleted]