Ah the 'smart alec' has appeared. I'm not stupid, I know code like that won't be faster in Python but PyPy shows that it can be a hell of a lot faster than CPython and right up there with Node.js and the travesty is that CPython is so far off the pace and getting slower
Would you please not post uncivilly to HN, regardless of how annoying you find someone's comment? This kind of thing degrades discussion and provokes worse from others. We're hoping to do better than that here.
i suspect "smart alec" was chosen with exactly the intention you're expecting--ie, i'm not a native English speaker but i believe the term when used by adults to refer to other adults is benign--perhaps like the "G"-rated version of "wise-ass" or "pedant." Maybe wrong here, but benefit of the doubt perhaps....
Python 3.6.1 is a lot faster than 3.3.2 which was used back when the heap benchmark was done. In my system, 2.7.10 vs 3.6.1:
C:\Test\PyBench>py -2 test.py
Done in 1188.308127
C:\Test\PyBench>py -3 test.py
Done in 1454.897614
Please bring up to date benchmarks to the discussion, and stop complaining about old problems.
Note: adjusted I the workload to be 1000 less iterations, to get the results fast for this comment, so this numbers aren't comparable to the list in the github repo. But even if I hadn't done that, they wouldn't be because I ran these in my system.
Python, R and other languages are just slower. If that is an issue I again will agree you need to move to another language.
Can I ask what you need the speed for? How long are your reports running? Because a lot of times the reports run in under a few minutes and people just don't sub-set their data to code on. People feel it is "BIG DATA" when it is just annoying data that takes less then a minute to spit out.
The coalescence around Python and R for numerics to the extent it did was kind of premature. They're both great languages but I've given up on implementations of either of them achieving the kinds of speeds that they should be at for the things people are using them for.
I think there'll be more traction expanding the libraries for Julia, Nim, or Kotlin, all of which are much faster than Python, and similar in expressiveness. It's probably easier to create an optimization/ML/linear algebra/RNG/whatever library in Julia, Nim, or Kotlin than trying to get good performance out of R or Python.
I completely understand PyPy and numpy and why Python and R became popular, because there was a need for expressivity in the numerics space and other languages weren't offering it. But if you've been following them for long enough, it's clear that both of them had problems under the hood. I think people just crossed the boundary of appropriate use at some point, because the language syntax is so appealing for these sorts of things.
Maybe I'm wrong about all this and Pypy will deliver but I'm not holding my breath any longer. No offense to the Pypy developers--I'm immensely impressed with their work, and they've produced much more than I ever thought--but I do see some sort of asymptote. I think it would take some serious corporate influx of effort like what happened with javascript, and even then I worry that compatibility issues would rear their head. My guess is the Python 2-3 split would become a Python 2-3-Pypy split--maybe that's fine though.
I'm not a "smart alec" for pointing out that Python is, was and will be bad at heavily numerical, number crunching code. It's not what Python is built for.
I mean... it takes 28 bytes to store a single integer in Python.
this is silly, python is used by some of the biggest number crunchers on earth ... as glue code. If you dont like the dual language paradigm and want fast code go learn fortran.
It's not really a travesty. CPython just isn't designed for that kind of workload, and that's fine, because not many people use it to do that kind of thing.
