9 ms·

The title is bad; the article doesn't deliver on the promise of making Python programs "blazingly" fast. The first example given (the exponential function) is

by nayuki 7y ago

The title is bad; the article doesn't deliver on the promise of making Python programs "blazingly" fast. The first example given (the exponential function) is basically the worst scenario, because it's a purely numerical computation expressed in pure Python code. Whereas Python's performance is okay-ish for I/O or calling C modules. From doing Project Euler solutions, I have ample evidence that for pure numerics (e.g. int, float, array), Java is anywhere from 10× to 30× faster than pure Python code executed in CPython. https://www.nayuki.io/page/project-euler-solutions#benchmark-timings https://www.nayuki.io/page/project-euler-solutions#benchmark... I believe it is basically impossible for Python to win back all that performance loss without adopting radical and jarring features like static typing, machine-sized integers, and no more "every number is a full-fledged object".

cf 7y ago
I think for pure numerics using numpy basically recovers all performance loss. It's when you get tricky control-flow that you run into real trouble.
- kragen 7y ago
  Typically straightforward Numpy gets me from 40× slower than straightforward C to 5× slower. Tricky Numpy (output arguments, conversions to lower precision, weird SciPy functions) gets me another factor of 2. C SIMD (intrinsics or GCC’s portable vector types) gets me a factor of 4 faster than straightforward C. Presumably CUDA would buy me another factor of 100 but I haven't tried it and I haven't tried Numba either.
  - m_mueller 7y ago
    You're probably expecting a bit much from CUDA. If you have heavily optimized CPU code running on a high-core count Xeon, it's probably more like 2-3x. The reason why CUDA is so popular is because it makes that comparatively easy to achieve. Optimizing x86 to the last 10% is a dark art only very few programmers are capable of, while writing decent GPU code is IMO an order of magnitude easier, i.e. just a craft. Main difference being: High memory bandwidth vs. heavy usage of cache, unified programming model for vectorization and multicore parallelism
    - kragen 7y ago
      Thanks! But what if I don't have any kind of Xeon, but do have an NVIDIA card?
      - yalok 7y ago
        You don’t need any kind of Xeon - most of recent i5/i7/i9 cores have AVX and even AVX2 support.
      - m_mueller 7y ago
        without lots of CPU cores and with a high-end NVIDIA card your speedup expectations just can become a bit higher. Typically 100x when comparing GPU-friendly algos to unoptimized (but native) CPU code or 10x when comparing it to decently optimized code running on slower CPUs. Generally I think a performance/cost comparison is more useful: Take the price of the GPU and compare it to something with equivalent cost in CPU+RAM.
    - FpUser 7y ago
      Btw GPU has its own cache and all problems related to it. You still have to watch what/how you do things on GPU to be cache friendly
      - m_mueller 7y ago
        Yes, but it's much less emphasized on GPU I think. If you have a data parallel algorithm, as long as you design the array ordering to allow coalesced access, the memory architecture will usually already allow better performance than what you can hope to get from CPU even with heavily cache optimized code that's basically unmaintainable (as it will likely perform much differently on the next architecture).
  - steev 7y ago
    > Typically straightforward Numpy gets me from 40x slower than straightforward C to 5x slower. I find this hard to believe. What kind of numerical work are you doing? Even something as simple as matrix-matrix multiplication should be hard to beat with C, unless your C code is using a cache efficient algorithm.
    - hoiuyoi9087 7y ago
      Branch heavy code, for example trading order book updating. People always say "use numpy", but that is only possible if your algorithm can be described in terms of vectorized operations. For many kinds of processing, the only alternative is C/C++ (through Cython)
      - steev 7y ago
        That was my hunch. > People always say "use numpy", but that is only possible if your algorithm can be described in terms of vectorized operations. For many kinds of processing, the only alternative is C/C++ (through Cython Agreed
      - Sean1708 7y ago
        > (through Cython) My personal experience is that you can actually get another factor of 2 or 3 speed-up by ditching Cython and using actual C instead (I think it's because optimizers have a hard time cleaning up the C that Cython produces), even if you've turned off thing's like bounds checking.
        hoiuyoi9087 7y ago
        I meant "through Cython" as in "passing through Cython", ie, Cython is just a thin wrapper layer over the real C/C++ code.
      - cf 7y ago
        I think using numpy is always good first step after just trying to improve the algorithm. Numpy will be less effort than going to cython. After that cython is a good next step. I seriously don't know any situation where I would do the kind of micro-optimizations mentioned in the article.
  - imtringued 7y ago
    Using GPUs involves significant tradeoffs that go way beyond writing SIMD code. (mostly batching and off device transfers) CPU SIMD code can be trivially mixed with non SIMD code but mixing GPU and CPU code may negate the benefits.
- qwerty456127 7y ago
  Indeed, numpy is awesome. I used to do my computational experimenting (some of them including neural networks) the plain way (using classic data structures, the languages' built-in arithmetic operators and functional facilities) in many different languages. Once I've tried Python with numpy my mind was blown, it's so much faster than anything. Now I feel like I enjoyed writing functional code more but given the performance difference I can hardly imagine coming back. So the very reason I use Python is performance.
bjoli 7y ago
Chez scheme is just as dynamic as python and is about as fast as C# running on mono IIRC. My scheme was probably worse than my C# was when I did project Euler though. Chez does unboxed integer arithmetic (but not floats) and does not have to do any OO-like dispatch, and is also probably one of the best language implementations there are.
- tluyben2 7y ago
  A nice show of Chez Scheme speed is Idris 2. Edwin is very impressed with the performance; it is very fast. And imho it is a lovely language with, as you rightfully say, one of the best implementations out there. Extremely portable (cpu/OS). And quite readable too.
- username90 7y ago
  C# running on mono is in my experience 10 times slower than equivalent C++ even for simple things like adding numbers in an array.
  - bjoli 7y ago
    That story of mine is old, but I have some newer anecdata: porting all my old project Euler solutions to SBCL and getting help by some better lispers than me to optimize it made SBCL come out close, but almost universally slower than Chez if someone really wants I can see if I find the code on any of my external HDDs. A number quoted is that SBCL preforms roughly on par with, but slightly slower than, java. For what it is worth, the computer benchmarks game confirms that: https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/lisp.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/... That was with optimize level 3, which burns on (car 1), and then you might as well use C, but the language at least allows for those speeds.
    - omaranto 7y ago
      Ooh! I don't think I've ever seen someone claim Chez Scheme produced faster code than SBCL before. That's interesting.
socialdemocrat 7y ago
You could just use Julia which basically gives you a Python like language but with C like performance. Julia will kick Java to the curb on numerics because it was actually built with that in mind. And you get all of this WITHOUT static typing and yes in Julia everything is still a full-fledged object. There is no difference between numbers and other objects in Julia. But numerics is still fast.
- steev 7y ago
  I tried really hard to like Julia and just couldn't get behind it. We used it for a research paper in the area of optimization and by the end of the project I really regretted it. Performance and built in numerics libraries were great, but I feel the language ergonomics are pretty bad. I hate Python just as much as the next developer, but I do find it much easier to use than Julia for research type work. My biggest qualm with Julia (and maybe this speaks to my inexperience with the language) is that it isn't always obvious when Julia is going to make a copy. We spent about an hour working through some code that was very slow (props to Julia's profiling tools) but couldn't figure out _why_ it was slow. It turned out that despite our best efforts, Julia was still copying a vector despite us using pre-allocated scratch space for the work. From my point of view, if I am comparing algorithms then Python's performance doesn't really matter and it's ergonomics win. If performance matters I'd just use C++ or Rust.
  - Sukera 7y ago
    > My biggest qualm with Julia (and maybe this speaks to my inexperience with the language) is that it isn't always obvious when Julia is going to make a copy. If you're talking about slices of an array, those always create a copy unless created with the @views macro (or the equivalent function call).
  - socialdemocrat 7y ago
    Interesting how we can have such vastly different experiences. When Julia makes a copy is pretty straightforward and natural IMHO. I would have been curious to see an example of the code you used where a copy was made without you knowing. I started with Python, but I find Julia better is almost every single way I can think of. Like even if Julia was slower than Python I would have picked it because I find it so much nicer to use. I wrote an article here about some of the observations I had about using Python after coming back to it from Julia: https://medium.com/@Jernfrost/python-vs-julia-observations-e61ee667fa95 https://medium.com/@Jernfrost/python-vs-julia-observations-e... There are some exchanges further down. Would have been interesting to hear your feedback on some of those things.
pjmlp 7y ago
Lisp, Smalltalk, Dylan, JavaScript prove otherwise regarding performance of dynamic languages. The problem is that projects like PyPy remain on the sidelines, instead of being fully embraced by the community.
- mangecoeur 7y ago
  That's because PyPy has poor support for C-API exentions, which is what all the performance-oriented python packages rely on. Most people doing serious numeric work don't care about the speed of the Python interpreter because all the heavy lifting is done by optimized libraries like Numpy and TensorFlow.
  - pjmlp 7y ago
    Which will never change, because instead of improving Python, one writes C instead. I could even use them from TCL if bothered to do so, thus Python's benefits as programming language are meaningless. Tensorflow has multiple language support for example.
    - psv1 7y ago
      > Python's benefits as programming language are meaningless. Being the most flexible and user-friendly interface to the most powerful libraries written in other languages isn't meaningless.
      - pjmlp 7y ago
        That isn't unique to Python.
  - ken 7y ago
    Then maybe the statement should have been "I believe it is basically impossible for Python to win back all that performance loss without adopting radical and jarring features like dropping the legacy C interface to Python objects." The fastest dynamic languages I see are those which have no C interface at all. How many of the performance optimizations in a modern JavaScript engine would be possible if it had to support accessing every property of every object as a C string at any point in a program? JS has exactly none of the features that comment claims would be necessary for performance.
calpaterson 7y ago
> I believe it is basically impossible for Python to win back all that performance loss without adopting radical and jarring features like static typing, machine-sized integers, and no more "every number is a full-fledged object". Pypy is often quite a bit faster than CPython for real-world programs so clearly some improvement is possible.
gameswithgo 7y ago
It is a shame that Python became so popular. There are a number of choices that are just as “easy” (or better) and an order of magnitude more efficient. Two options you can try guiding a budding python user to are Nim and F#
- AstralStorm 7y ago
  Both rather dead because you get to chase Microsoft, and even Mono cannot achieve that. Short: they're not portable beyond Windows.
  - gameswithgo 7y ago
    Nim is not related to Microsoft at all, and runs anywhere GCC can run. F# runs on Windows/Linux/Mac standard since .NET Core, and Mono runs it anywhere, Nintendo Switch, IOS, Android, playstation.
  - igouy 7y ago
    ? Ubuntu https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/fsharp.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

by nayuki 7y ago

cf 7y ago

I think for pure numerics using numpy basically recovers all performance loss. It's when you get tricky control-flow that you run into real trouble.

kragen 7y ago
Typically straightforward Numpy gets me from 40× slower than straightforward C to 5× slower. Tricky Numpy (output arguments, conversions to lower precision, weird SciPy functions) gets me another factor of 2. C SIMD (intrinsics or GCC’s portable vector types) gets me a factor of 4 faster than straightforward C. Presumably CUDA would buy me another factor of 100 but I haven't tried it and I haven't tried Numba either.
- m_mueller 7y ago
  You're probably expecting a bit much from CUDA. If you have heavily optimized CPU code running on a high-core count Xeon, it's probably more like 2-3x. The reason why CUDA is so popular is because it makes that comparatively easy to achieve. Optimizing x86 to the last 10% is a dark art only very few programmers are capable of, while writing decent GPU code is IMO an order of magnitude easier, i.e. just a craft. Main difference being: High memory bandwidth vs. heavy usage of cache, unified programming model for vectorization and multicore parallelism
  - kragen 7y ago
    Thanks! But what if I don't have any kind of Xeon, but do have an NVIDIA card?
    - yalok 7y ago
      You don’t need any kind of Xeon - most of recent i5/i7/i9 cores have AVX and even AVX2 support.
    - m_mueller 7y ago
      without lots of CPU cores and with a high-end NVIDIA card your speedup expectations just can become a bit higher. Typically 100x when comparing GPU-friendly algos to unoptimized (but native) CPU code or 10x when comparing it to decently optimized code running on slower CPUs. Generally I think a performance/cost comparison is more useful: Take the price of the GPU and compare it to something with equivalent cost in CPU+RAM.
  - FpUser 7y ago
    Btw GPU has its own cache and all problems related to it. You still have to watch what/how you do things on GPU to be cache friendly
    - m_mueller 7y ago
      Yes, but it's much less emphasized on GPU I think. If you have a data parallel algorithm, as long as you design the array ordering to allow coalesced access, the memory architecture will usually already allow better performance than what you can hope to get from CPU even with heavily cache optimized code that's basically unmaintainable (as it will likely perform much differently on the next architecture).
- steev 7y ago
  > Typically straightforward Numpy gets me from 40x slower than straightforward C to 5x slower. I find this hard to believe. What kind of numerical work are you doing? Even something as simple as matrix-matrix multiplication should be hard to beat with C, unless your C code is using a cache efficient algorithm.
  - hoiuyoi9087 7y ago
    Branch heavy code, for example trading order book updating. People always say "use numpy", but that is only possible if your algorithm can be described in terms of vectorized operations. For many kinds of processing, the only alternative is C/C++ (through Cython)
    - steev 7y ago
      That was my hunch. > People always say "use numpy", but that is only possible if your algorithm can be described in terms of vectorized operations. For many kinds of processing, the only alternative is C/C++ (through Cython Agreed
    - Sean1708 7y ago
      > (through Cython) My personal experience is that you can actually get another factor of 2 or 3 speed-up by ditching Cython and using actual C instead (I think it's because optimizers have a hard time cleaning up the C that Cython produces), even if you've turned off thing's like bounds checking.
      - hoiuyoi9087 7y ago
        I meant "through Cython" as in "passing through Cython", ie, Cython is just a thin wrapper layer over the real C/C++ code.
    - cf 7y ago
      I think using numpy is always good first step after just trying to improve the algorithm. Numpy will be less effort than going to cython. After that cython is a good next step. I seriously don't know any situation where I would do the kind of micro-optimizations mentioned in the article.
- imtringued 7y ago
  Using GPUs involves significant tradeoffs that go way beyond writing SIMD code. (mostly batching and off device transfers) CPU SIMD code can be trivially mixed with non SIMD code but mixing GPU and CPU code may negate the benefits.
qwerty456127 7y ago
Indeed, numpy is awesome. I used to do my computational experimenting (some of them including neural networks) the plain way (using classic data structures, the languages' built-in arithmetic operators and functional facilities) in many different languages. Once I've tried Python with numpy my mind was blown, it's so much faster than anything. Now I feel like I enjoyed writing functional code more but given the performance difference I can hardly imagine coming back. So the very reason I use Python is performance.

bjoli 7y ago

Chez scheme is just as dynamic as python and is about as fast as C# running on mono IIRC. My scheme was probably worse than my C# was when I did project Euler though. Chez does unboxed integer arithmetic (but not floats) and does not have to do any OO-like dispatch, and is also probably one of the best language implementations there are.

tluyben2 7y ago
A nice show of Chez Scheme speed is Idris 2. Edwin is very impressed with the performance; it is very fast. And imho it is a lovely language with, as you rightfully say, one of the best implementations out there. Extremely portable (cpu/OS). And quite readable too.
username90 7y ago
C# running on mono is in my experience 10 times slower than equivalent C++ even for simple things like adding numbers in an array.
- bjoli 7y ago
  That story of mine is old, but I have some newer anecdata: porting all my old project Euler solutions to SBCL and getting help by some better lispers than me to optimize it made SBCL come out close, but almost universally slower than Chez if someone really wants I can see if I find the code on any of my external HDDs. A number quoted is that SBCL preforms roughly on par with, but slightly slower than, java. For what it is worth, the computer benchmarks game confirms that: https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/lisp.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/... That was with optimize level 3, which burns on (car 1), and then you might as well use C, but the language at least allows for those speeds.
  - omaranto 7y ago
    Ooh! I don't think I've ever seen someone claim Chez Scheme produced faster code than SBCL before. That's interesting.

socialdemocrat 7y ago

You could just use Julia which basically gives you a Python like language but with C like performance. Julia will kick Java to the curb on numerics because it was actually built with that in mind. And you get all of this WITHOUT static typing and yes in Julia everything is still a full-fledged object. There is no difference between numbers and other objects in Julia. But numerics is still fast.

steev 7y ago
I tried really hard to like Julia and just couldn't get behind it. We used it for a research paper in the area of optimization and by the end of the project I really regretted it. Performance and built in numerics libraries were great, but I feel the language ergonomics are pretty bad. I hate Python just as much as the next developer, but I do find it much easier to use than Julia for research type work. My biggest qualm with Julia (and maybe this speaks to my inexperience with the language) is that it isn't always obvious when Julia is going to make a copy. We spent about an hour working through some code that was very slow (props to Julia's profiling tools) but couldn't figure out _why_ it was slow. It turned out that despite our best efforts, Julia was still copying a vector despite us using pre-allocated scratch space for the work. From my point of view, if I am comparing algorithms then Python's performance doesn't really matter and it's ergonomics win. If performance matters I'd just use C++ or Rust.
- Sukera 7y ago
  > My biggest qualm with Julia (and maybe this speaks to my inexperience with the language) is that it isn't always obvious when Julia is going to make a copy. If you're talking about slices of an array, those always create a copy unless created with the @views macro (or the equivalent function call).
- socialdemocrat 7y ago
  Interesting how we can have such vastly different experiences. When Julia makes a copy is pretty straightforward and natural IMHO. I would have been curious to see an example of the code you used where a copy was made without you knowing. I started with Python, but I find Julia better is almost every single way I can think of. Like even if Julia was slower than Python I would have picked it because I find it so much nicer to use. I wrote an article here about some of the observations I had about using Python after coming back to it from Julia: https://medium.com/@Jernfrost/python-vs-julia-observations-e61ee667fa95 https://medium.com/@Jernfrost/python-vs-julia-observations-e... There are some exchanges further down. Would have been interesting to hear your feedback on some of those things.

pjmlp 7y ago

Lisp, Smalltalk, Dylan, JavaScript prove otherwise regarding performance of dynamic languages. The problem is that projects like PyPy remain on the sidelines, instead of being fully embraced by the community.

mangecoeur 7y ago
That's because PyPy has poor support for C-API exentions, which is what all the performance-oriented python packages rely on. Most people doing serious numeric work don't care about the speed of the Python interpreter because all the heavy lifting is done by optimized libraries like Numpy and TensorFlow.
- pjmlp 7y ago
  Which will never change, because instead of improving Python, one writes C instead. I could even use them from TCL if bothered to do so, thus Python's benefits as programming language are meaningless. Tensorflow has multiple language support for example.
  - psv1 7y ago
    > Python's benefits as programming language are meaningless. Being the most flexible and user-friendly interface to the most powerful libraries written in other languages isn't meaningless.
    - pjmlp 7y ago
      That isn't unique to Python.
- ken 7y ago
  Then maybe the statement should have been "I believe it is basically impossible for Python to win back all that performance loss without adopting radical and jarring features like dropping the legacy C interface to Python objects." The fastest dynamic languages I see are those which have no C interface at all. How many of the performance optimizations in a modern JavaScript engine would be possible if it had to support accessing every property of every object as a C string at any point in a program? JS has exactly none of the features that comment claims would be necessary for performance.

calpaterson 7y ago

> I believe it is basically impossible for Python to win back all that performance loss without adopting radical and jarring features like static typing, machine-sized integers, and no more "every number is a full-fledged object". Pypy is often quite a bit faster than CPython for real-world programs so clearly some improvement is possible.

gameswithgo 7y ago

It is a shame that Python became so popular. There are a number of choices that are just as “easy” (or better) and an order of magnitude more efficient. Two options you can try guiding a budding python user to are Nim and F#

AstralStorm 7y ago
Both rather dead because you get to chase Microsoft, and even Mono cannot achieve that. Short: they're not portable beyond Windows.
- gameswithgo 7y ago
  Nim is not related to Microsoft at all, and runs anywhere GCC can run. F# runs on Windows/Linux/Mac standard since .NET Core, and Mono runs it anywhere, Nintendo Switch, IOS, Android, playstation.
- igouy 7y ago
  ? Ubuntu https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/fsharp.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/...