8 ms·

It's primarily a testament to how simply mind bogglingly slow Python is outside of its optimised numerical science ecosystem. Which also why I don't use it that

by zmmmmm 5y ago

It's primarily a testament to how simply mind bogglingly slow Python is outside of its optimised numerical science ecosystem. Which also why I don't use it that much, because while numerical analysis is a big part of what I do, so is what I would call "symbolic manipulation" and unless you go to quite some effort to transform every problem into a numerical one, Python is just awful at that. But Nim is only one of a whole suite of languages that easily cruise to a 10x performance win over Python. And that isn't counting multicore - if you count that you quickly get to a 100x improvement. Personally I use Groovy for much of what I do for similar reasons (which is somewhat unusual) but its just a placeholder for "use anything except python".

amyjess 5y ago
> It's primarily a testament to how simply mind bogglingly slow Python is outside of its optimised numerical science ecosystem. From my experience in using Python at my last job, I'll also add that Python is decent at tasks that aren't CPU-bound. I wrote a lot of scripts that polled large amounts of network devices for information and then did something with it (typically upsert the data into a database, either via direct SQL or a REST API to whatever service owns the database). All these tasks were heavily network-bound. The amount of time the CPU was doing any work was minuscule compared to the amount of time it was waiting to get data back from the network. I doubt Nim or any other language would have been a significant performance improvement in this case. For what it's worth, that made these scripts excellent candidates for multithreading. I'd run them with 20+ threads, and it was glorious. At first I did multiprocessing, because of all the GIL horror stories, but multiprocessing made it very difficult to cache data, so eventually I said "well, all this is network-bound so the GIL doesn't even apply" and switched over to multiprocessing.dummy (which implements pools using the same API as multiprocessing but with threads instead of processes), and I never looked back. Edit: For what it's worth, Nim sounds like a really cool language, and it's right up my alley in several ways, I just don't think Python is particularly slow at network-bound tasks that use very little CPU.
- otherme123 5y ago
  You have to be reaaaaaally slow to be beaten by a network. Also, touched by the OP, if it takes 3 hours to write some code that in Python takes only 1, or if the compile times are huge, Python can beat other languages in speed (that edge fades when the same program is used over and over again). But as demonstrated, Nim is fast to write and fast to compile, so Python has little edge. Just it's huge ecosystem.
  - baq 5y ago
    > Just it's huge ecosystem. self-contradiction at its best. kindly be reminded the same advantage was the only thing that kept Java alive for so long until it finally started to enter the XXI century a couple years ago. you just can't discount an ecosystem, especially if its huge.
    - curioussavage 5y ago
      Exactly. Also I’m not impressed with a lot of the ecosystem. After getting more acquainted with many very important libraries I can see the poor quality and it’s scary. Grateful for the free tools but IMO there other Languages like go where more essential libraries and tooling are written by better programmers. Like actual professionals instead of hobby tier
- m_mueller 5y ago
  I agree with your entire post but, and I‘m saying this as a fulltime python dev, there‘s often a point where it starts being bothersome, and that usually comes only later in the lifecycle of an application after it had some organic growth. Some day e.g. a sales manager comes down to your lair and asks you if you couldn‘t just also parse this little 200MB Excel spreadsheet after it came over the network such that your ETL process could save it into a new table. And boom you‘re into CPU bound lands now. Often it‘s fine, you can wait those 1-2min for a daily occuring process. But what if for example you put this whole component behind a REST API that is behind a load balancer that is set with a certain timeout? There are even strict upper limits if for example you chose AWS Lambda for your stuff. And suddenly you need to introduce quite a bit more technical complexity into this story that‘s gonna be hard to explain to management - all they see is that you now can insert a couple of millions of DB rows and their Big Data consultants[TM] told them that this is nowadays not even worth thinking about. Point being: If your performance ceiling is low, you‘re gonna hit it sooner.
IshKebab 5y ago
Yeah should really be "Why I don't use Python for Data Processing". I would consider Typescript as an alternative too which I'm sure would get a similar speedup. Also I don't know how anyone could design a language in the 21st century and make basic mistakes like this: > Nim treats identifiers as equal if they are the same after removing capitalization (except for the first letter) and underscore, which means that you can use whichever style you want. If that's any indication of the sanity of the rest of Nim then I'd say steer well clear!
- thewakalix 5y ago
  How is that a basic mistake? I think having two distinct identifiers that differ only by case sounds like a mistake!
  - otherme123 5y ago
    What I found useful is that even if some author uses snake in his library, it doesn't spread to your code, so you can still adhere to the standard.
  - IshKebab 5y ago
    Various programming languages (and file systems!) have had some form of case insensitivity and it always turns out to be an absolutely terrible idea: * It makes searching for identifiers harder. For Nim you can't even use case insensitive search because of the underscore thing! Better practice your regexes. * The case insensitivity rules are usually super complicated and don't apply to everything, so now it's an extra thing you have to mentally compute when coding. This is probably the biggest problem and I'm sure it has led to bugs, e.g. in SQL. * Do you enjoy the tabs vs spaces debate? How about single quote Vs double quotes? Ugly inconsistently styled code? Well you'll love this! * Unicode case insensitivity is actually really really complicated (this mostly applies to filesystems). You're basically opening yourself up to an array of annoyances and gotchas for essentially no benefits. I've literally never seen anyone use two identifiers that only differ by case, but if that were actually a big problem it could be solved just by making that illegal. You don't have to resort to the insanity of case insensitivity.
CraigJPerry 5y ago
The thing with Python is it's usually pretty easy to optimise quite impressively. E.g. random example: Sprinkle some cdef's in your python and suddenly you're faster than c++ https://github.com/luizsol/PrimesResult https://github.com/luizsol/PrimesResult https://github.com/PlummersSoftwareLLC/Primes/blob/drag-race/PrimeCython/solution_1/PrimeCY_32.pyx https://github.com/PlummersSoftwareLLC/Primes/blob/drag-race... 25.8 seconds down to 1.5
- stavros 5y ago
  Apparently mypyc does the same if you have types in your code, though I've never used it.
- Jensson 5y ago
  I've tried cython and it isn't competitive with C in real world cases. Cherry picking a case where it is competitive doesn't help your case. Its performance tend to be around the level of Java, another language people say is competitive or faster than C++ but in practice C++ is still twice faster than Java in most cases. Still, getting Java level performance out of python is a huge improvement and should be enough for most cases.
  - CraigJPerry 5y ago
    Ahh my point was more that you can score a 17x performance boost with minimal effort rather than any absolute performance advantage over c++. For a c++ comparison python would be much better pointing out the productivity advantage it has over the notoriously low productivity of c++ development - rather than competing on execution performance.
- PartiallyTyped 5y ago
  There is also numba, which is very impressive in its own right, and also pypy, which supports features up to Python 3.7. Some may consider Jax, and its XLA compiler, but unless you require gradients, numba will be significantly faster, an instance of this is available here [1]. XLA runs on a higher level than LLVM and therefore can't achieve the same optimizations as numba does using the latter. IIRC numba also has a Python to Cuda compiler, which is also very impressive. [1] https://github.com/scikit-hep/iminuit/blob/develop/doc/tutorial/automatic_differentiation.ipynb https://github.com/scikit-hep/iminuit/blob/develop/doc/tutor...
nerdponx 5y ago
I often recommend PyPy for "non-numerical" data processing when performance matters. Also, "awful" is too harsh. Probably 90% of Python code just doesn't need to be faster than it is.
- mattbillenstein 5y ago
  I'd guess closer to 99%...
gameswithgo 5y ago
Nim isn’t unique in its performance, but it “feels” a lot like Python making it a nice gateway drug for Python users to start wasting less electricity.
flohofwoe 5y ago
IME Python is pretty great as cross-platform scripting-, automation- and glue-language up to a few thousand lines of code. Essentially replacing bash scripts and Windows batch files or for simple command line tools that don't need the performance. It should be just one language in one's language toolbox though.
p7g 5y ago
> It's primarily a testament to how simply mind bogglingly slow Python is outside of its optimised numerical science ecosystem. CPython's slowness doesn't boggle my mind at all. It's a bytecode interpreter for an incredibly dynamic language that states simplicity of implementation as a goal. I would say performance is actually pretty impressive considering all that. What _does_ boggle my mind is the performance of cutting-edge optimizing compilers like LLVM and V8! At least there is a benefit to a simple implementation: Someone like me can dive into CPython's source and find out how things work.
sevensor 5y ago
> mind bogglingly slow Python is outside of its optimised numerical science ecosystem Granted, but inside its optimised numerical science ecosystem, Python is, in fact, fast enough. If most of your program is calls into numpy, Python will get you where you need to go. In my experience, one scalar Python math operation takes about the same amount of time as the equivalent numpy operation on a million-element array. Linked against a recent libblas, numpy will even distribute work across multiple cores. So much for the GIL.
nimmer 5y ago
> It's primarily a testament to how simply mind bogglingly slow Python is No, Nim is truly among the top fastest languages when writing idiomatic code as shown in many benchmarks. > But Nim is only one of a whole suite of languages that easily cruise to a 10x performance win over Python ...while also being very friendly to Python programmers, intuitive and expressive. Unlike many other languages.

by zmmmmm 5y ago

amyjess 5y ago

> It's primarily a testament to how simply mind bogglingly slow Python is outside of its optimised numerical science ecosystem. From my experience in using Python at my last job, I'll also add that Python is decent at tasks that aren't CPU-bound. I wrote a lot of scripts that polled large amounts of network devices for information and then did something with it (typically upsert the data into a database, either via direct SQL or a REST API to whatever service owns the database). All these tasks were heavily network-bound. The amount of time the CPU was doing any work was minuscule compared to the amount of time it was waiting to get data back from the network. I doubt Nim or any other language would have been a significant performance improvement in this case. For what it's worth, that made these scripts excellent candidates for multithreading. I'd run them with 20+ threads, and it was glorious. At first I did multiprocessing, because of all the GIL horror stories, but multiprocessing made it very difficult to cache data, so eventually I said "well, all this is network-bound so the GIL doesn't even apply" and switched over to multiprocessing.dummy (which implements pools using the same API as multiprocessing but with threads instead of processes), and I never looked back. Edit: For what it's worth, Nim sounds like a really cool language, and it's right up my alley in several ways, I just don't think Python is particularly slow at network-bound tasks that use very little CPU.

otherme123 5y ago
You have to be reaaaaaally slow to be beaten by a network. Also, touched by the OP, if it takes 3 hours to write some code that in Python takes only 1, or if the compile times are huge, Python can beat other languages in speed (that edge fades when the same program is used over and over again). But as demonstrated, Nim is fast to write and fast to compile, so Python has little edge. Just it's huge ecosystem.
- baq 5y ago
  > Just it's huge ecosystem. self-contradiction at its best. kindly be reminded the same advantage was the only thing that kept Java alive for so long until it finally started to enter the XXI century a couple years ago. you just can't discount an ecosystem, especially if its huge.
  - curioussavage 5y ago
    Exactly. Also I’m not impressed with a lot of the ecosystem. After getting more acquainted with many very important libraries I can see the poor quality and it’s scary. Grateful for the free tools but IMO there other Languages like go where more essential libraries and tooling are written by better programmers. Like actual professionals instead of hobby tier
m_mueller 5y ago
I agree with your entire post but, and I‘m saying this as a fulltime python dev, there‘s often a point where it starts being bothersome, and that usually comes only later in the lifecycle of an application after it had some organic growth. Some day e.g. a sales manager comes down to your lair and asks you if you couldn‘t just also parse this little 200MB Excel spreadsheet after it came over the network such that your ETL process could save it into a new table. And boom you‘re into CPU bound lands now. Often it‘s fine, you can wait those 1-2min for a daily occuring process. But what if for example you put this whole component behind a REST API that is behind a load balancer that is set with a certain timeout? There are even strict upper limits if for example you chose AWS Lambda for your stuff. And suddenly you need to introduce quite a bit more technical complexity into this story that‘s gonna be hard to explain to management - all they see is that you now can insert a couple of millions of DB rows and their Big Data consultants[TM] told them that this is nowadays not even worth thinking about. Point being: If your performance ceiling is low, you‘re gonna hit it sooner.

IshKebab 5y ago

Yeah should really be "Why I don't use Python for Data Processing". I would consider Typescript as an alternative too which I'm sure would get a similar speedup. Also I don't know how anyone could design a language in the 21st century and make basic mistakes like this: > Nim treats identifiers as equal if they are the same after removing capitalization (except for the first letter) and underscore, which means that you can use whichever style you want. If that's any indication of the sanity of the rest of Nim then I'd say steer well clear!

thewakalix 5y ago
How is that a basic mistake? I think having two distinct identifiers that differ only by case sounds like a mistake!
- otherme123 5y ago
  What I found useful is that even if some author uses snake in his library, it doesn't spread to your code, so you can still adhere to the standard.
- IshKebab 5y ago
  Various programming languages (and file systems!) have had some form of case insensitivity and it always turns out to be an absolutely terrible idea: * It makes searching for identifiers harder. For Nim you can't even use case insensitive search because of the underscore thing! Better practice your regexes. * The case insensitivity rules are usually super complicated and don't apply to everything, so now it's an extra thing you have to mentally compute when coding. This is probably the biggest problem and I'm sure it has led to bugs, e.g. in SQL. * Do you enjoy the tabs vs spaces debate? How about single quote Vs double quotes? Ugly inconsistently styled code? Well you'll love this! * Unicode case insensitivity is actually really really complicated (this mostly applies to filesystems). You're basically opening yourself up to an array of annoyances and gotchas for essentially no benefits. I've literally never seen anyone use two identifiers that only differ by case, but if that were actually a big problem it could be solved just by making that illegal. You don't have to resort to the insanity of case insensitivity.

CraigJPerry 5y ago

The thing with Python is it's usually pretty easy to optimise quite impressively. E.g. random example: Sprinkle some cdef's in your python and suddenly you're faster than c++ https://github.com/luizsol/PrimesResult https://github.com/luizsol/PrimesResult https://github.com/PlummersSoftwareLLC/Primes/blob/drag-race/PrimeCython/solution_1/PrimeCY_32.pyx https://github.com/PlummersSoftwareLLC/Primes/blob/drag-race... 25.8 seconds down to 1.5

stavros 5y ago
Apparently mypyc does the same if you have types in your code, though I've never used it.
Jensson 5y ago
I've tried cython and it isn't competitive with C in real world cases. Cherry picking a case where it is competitive doesn't help your case. Its performance tend to be around the level of Java, another language people say is competitive or faster than C++ but in practice C++ is still twice faster than Java in most cases. Still, getting Java level performance out of python is a huge improvement and should be enough for most cases.
- CraigJPerry 5y ago
  Ahh my point was more that you can score a 17x performance boost with minimal effort rather than any absolute performance advantage over c++. For a c++ comparison python would be much better pointing out the productivity advantage it has over the notoriously low productivity of c++ development - rather than competing on execution performance.
PartiallyTyped 5y ago
There is also numba, which is very impressive in its own right, and also pypy, which supports features up to Python 3.7. Some may consider Jax, and its XLA compiler, but unless you require gradients, numba will be significantly faster, an instance of this is available here [1]. XLA runs on a higher level than LLVM and therefore can't achieve the same optimizations as numba does using the latter. IIRC numba also has a Python to Cuda compiler, which is also very impressive. [1] https://github.com/scikit-hep/iminuit/blob/develop/doc/tutorial/automatic_differentiation.ipynb https://github.com/scikit-hep/iminuit/blob/develop/doc/tutor...

nerdponx 5y ago

I often recommend PyPy for "non-numerical" data processing when performance matters. Also, "awful" is too harsh. Probably 90% of Python code just doesn't need to be faster than it is.

mattbillenstein 5y ago
I'd guess closer to 99%...

gameswithgo 5y ago

Nim isn’t unique in its performance, but it “feels” a lot like Python making it a nice gateway drug for Python users to start wasting less electricity.

flohofwoe 5y ago

IME Python is pretty great as cross-platform scripting-, automation- and glue-language up to a few thousand lines of code. Essentially replacing bash scripts and Windows batch files or for simple command line tools that don't need the performance. It should be just one language in one's language toolbox though.

p7g 5y ago

> It's primarily a testament to how simply mind bogglingly slow Python is outside of its optimised numerical science ecosystem. CPython's slowness doesn't boggle my mind at all. It's a bytecode interpreter for an incredibly dynamic language that states simplicity of implementation as a goal. I would say performance is actually pretty impressive considering all that. What _does_ boggle my mind is the performance of cutting-edge optimizing compilers like LLVM and V8! At least there is a benefit to a simple implementation: Someone like me can dive into CPython's source and find out how things work.

sevensor 5y ago

> mind bogglingly slow Python is outside of its optimised numerical science ecosystem Granted, but inside its optimised numerical science ecosystem, Python is, in fact, fast enough. If most of your program is calls into numpy, Python will get you where you need to go. In my experience, one scalar Python math operation takes about the same amount of time as the equivalent numpy operation on a million-element array. Linked against a recent libblas, numpy will even distribute work across multiple cores. So much for the GIL.

nimmer 5y ago

> It's primarily a testament to how simply mind bogglingly slow Python is No, Nim is truly among the top fastest languages when writing idiomatic code as shown in many benchmarks. > But Nim is only one of a whole suite of languages that easily cruise to a 10x performance win over Python ...while also being very friendly to Python programmers, intuitive and expressive. Unlike many other languages.