Python is fast enough, until it isn't and then there are no simple alternatives.<p>If your problem is numerical in nature, you can call popular C modules (numpy, etc) or write your own.<p>If your functions and data are pickleable, you can use multiprocessing but run into Amdahl's Law.<p>Maybe you try Celery / Gearman introducing IO bottlenecks transferring data to workers.<p>Otherwise you might end up with PyPy (poor CPython extension module support) and still restricted by the GIL. Or you'll try Cython, a bastard of C and Python.<p>Python has been my primary language the past few years and it's great for exploratory coding, prototypes, or smaller projects. However it's starting to lose some of the charm. Julia is filling in as a great substitute for scientific coding in a single language stack, and Go / Rust / Haskell for the other stuff. I've switched back to the static language camp after working in a multi-MLOC Python codebase.
Using a Numpy-based program as an example of how Python can be fast is a bit strange.<p>It shows that Python can be fast enough <i>if you leave the heavy computational parts to libraries written in other languages</i>. Which is interesting, but doesn't say much about the speed of Python itself.
Anecdotical datapoint: For a great many years I used to consider python a very slow language. Then I switched to Ruby and realized how slow a language can <i>really</i> be and yet still be practical for many use-cases.
Obviously, this is a silly benchmark and we should stop giving it any credit.<p>However, even "real world" anecdotes in this area can be a minefield.<p>Take, for example, an existing Python application that's slow which requires a rewrite to fix fundamental architectural changes.<p>Because you feel you don't need necessarily need the flexibility of Python the second time around (as you've moved out of the experimental or exploratory phase of development), you decide to rewrite it in, say, Go, or D or $whatever.<p>The finished result turns out to be 100X faster—which is great!—but the danger is always there that you internalise or condense that as "lamby rewrote Python system X in Go and it was 100X faster!"
I spend a lot of time debating program speed (mostly C vs MATLAB), but the problem is that the programming and compile time usually makes more of a difference than people consider.<p>If my C is 1000x faster and saves me 60 seconds every time I run the program, but takes an extra 2 days to write initially, and the program is seeing lots of edits meaning that on average I have to wait 2 minutes for it to compile then I am MUCH better off with the <i>slower</i> MATLAB until I am running the same thing a few thousand times.<p>Plus there is the fact that I can look at HN while a slightly slower program is running, so I win both ways.
Numpy is written in C. That's why it's fast.<p>Better: <a href="http://benchmarksgame.alioth.debian.org/" rel="nofollow">http://benchmarksgame.alioth.debian.org/</a>
<i>Holy false comparison, Batman!</i><p>Why would you use Numpy for arrays that small? Oh, looks like someone actually just wrote it in CPython, no Numpy, and it clocked in at 0.283s. Which is fine. It's Python.<p>This thread reminds me of the scene in RoboCop where Peter Weller gets shot to pieces. Peter Weller is Python and the criminals are the other languages.
Judging by the top submission being also written in python, I think this just shows how unoptimized OP's original code was rather than how slow the language is.<p>Not that python is fast, it isn't. And using numpy seems a bit disingenuous anyways "Oh my python program is faster because I use a library that's 95% C"
The same author previously posted this code as a question on Stack Overflow: <a href="http://stackoverflow.com/questions/23295642/" rel="nofollow">http://stackoverflow.com/questions/23295642/</a> (but we didn't speed it up nearly as much as the Code Golf champions).<p>If you enjoyed this Python optimization, you may also enjoy: <a href="http://stackoverflow.com/questions/17529342/" rel="nofollow">http://stackoverflow.com/questions/17529342/</a><p>This sort of thing comes up a lot: people write mathematical code which is gratuitously inefficient, very often simply because they use a lot of loops, repeated computations, and improper data structures. So pretty much the same as any other language, plus the extra subtlety of knowing how and why to use NumPy (as it turned out, this was not a good time for it, though that was not obvious).
You can make this far faster by changing the data representation. You can represent S as a bit string so that if the i'th bit is 0 then S[i] = 1 and if the i'th bit is 1 then S[i] = -1. Lets call that bit string A. You can represent F as two bit strings B,C. If the i'th bit in B is 0 then F[i] = 0. If the i'th bit of B is 1 then if the i'th bit of C is 0 then F[i] = 1 else F[i] = -1. Now the whole thing can be expressed as parity((A & B) ^ C). The parity of a bit string can be computed efficiently with bit twiddling as well. Now the entire computation is in registers, no arrays required. The random generation is also much simpler, since we only need to generate random bit strings B,C and this is already directly what random generators give us. I wouldn't be surprised if this is 1000x faster than his Python.
It's really fast to develop in, and with NumPy/Pandas/Scipy it runs numerical models fairly fast too. You do have to spend time getting to know `cProfile` and `pstats`; saved over 80% on runtime of something the other day.
What should the OP ask instead:<p>"How fast is the code produced by your compiler."<p>I keep seeing this misconception about languages vs implementations.<p>EDIT: Clarified what my original remark meant.
Summary: Question asker wrote a program in Python using numpy (A Python library that calls C code) which could've been more performant if written in pure Python (something to do with array sizes being used) and Python in general is slower than C/C++/Fortran/Rust. Anything else new?
Yet another attempt at a comparison scuttled by using randomness.<p>Different things use different types of randomness. Some are fast. Some are slow. If your comparison is not using the same type of randomness, that comparison is comparatively useless.