How to make Python run as fast (or faster) than Julia

[bartc]

On 27/02/2018 00:35, Chris Angelico wrote:
> On Tue, Feb 27, 2018 at 11:17 AM, Steven D'Aprano
> <steve+comp.lang.python at pearwood.info> wrote:
>> On Tue, 27 Feb 2018 02:09:53 +1100, Chris Angelico wrote:
>>
>>> You're still reimplementing the C code in Python, which is inefficient.
>>> Have you considered going back to the *actual algorithm* and
>>> implementing that idiomatically in Python? I think you'll find that (a)
>>> the code is more readable, and (b) the run time is much lower.
>>
>> Chris, I think this is incredibly optimistic, if not naive. We're talking
>> about a PRNG by Marsaglia, so my guess is that the "original algorithm"
>> *is* the C code. Or possibly Fortran.
>>
>> Even if not, even if there is actually a language-neutral algorithm, its
>> a PRNG which means its going to be filled with bit-twiddling and number-
>> crunching operations. Pure Python without a JIT is never going to be
>> competitive with C or Fortran for code like that.
>>
> 
> I may have been a little unclear. It's highly unlikely that the run
> time of the properly-implemented Python code will be lower than the
> original C or Fortran. But it most certainly CAN be more efficient
> than the Python reimplementation of the C implementation, which would
> narrow the gap considerably. Implementing Python idiotically instead
> of idiomatically gives you suboptimal performance.

Nonsense. You shouldn't need to care about such things. An algorithm is 
an algorithm. And the better ones should be easily written in any language.

This particular one, which was of interest because the calculations 
tended to overflow into undesirable bignums, is just a bunch of 
calculations. 'Bit-twiddling'.

Anyway, even this pure Python version can deliver pseudo random numbers 
at some 200,000 per second, while the built-in generator does 450,000 
per second, so it's not bad going.

Of course, the C version will generate them at over 100 million per second.

-- 
bartc