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

[bartc]

On 24/02/2018 00:45, Dan Stromberg wrote:
> On Fri, Feb 23, 2018 at 1:32 PM, bartc <bc at freeuk.com> wrote:

>> But the difference in runtime speed between Python and other dynamic
>> languages, if you look at benchmarks doing actual work in the language, can
>> be much greater than two times, yet that doesn't appear to matter.
> 
> The best way to use Python is to:
> 1) Write your whole application in it.
> 2) IF things are too slow, profile the app.  Usually performance will
> be fast enough from the start, but not always.
> 3) After (if) identifying a hotspot, optimize it in any of a variety
> of ways, while still reaping the benefits of rapid development (which
> often matters much more than CPU speed today)
> 
> I have a page about speeding up python:
> http://stromberg.dnsalias.org/~strombrg/speeding-python/
> 
> But again, those techniques are only infrequently relevant, and pretty
> much never relevant to an entire application.

That your page lists 23 different approaches to making Python faster 
suggests that its speed can be an issue. Certainly there seem to be a 
lot of projects going on trying to fix that aspect.

So I'll rephrase, and say that some individuals in this group are saying 
that speed doesn't matter. For many others it apparently does.

(I've just looked at the benchmark results referred to in the OP's link 
[https://julialang.org/benchmarks/] and the comparison for the recursion 
benchmark (let's just call it that) seems fair enough to me.

Perhaps it ought to have been clear that this was CPython, if it in fact 
was. There are so many possibilities with Python, that using anything 
else would confuse matters. People who use Python will be aware there 
are acceleration techniques.

(A note regarding the C timing in that table: I've looked at what gcc 
does with this benchmark with its unreasonably fast timing, and it 
appears to cheat. That is, it does not call that function (ie. enter via 
the normal prologue code) the number of times it says. I don't know if 
that was the case when they tested C for that table. But it can happen 
that a sufficiently simple benchmark can lend itself to 
super-optimisation that is much harder with real code.

For that reason I no longer take account of gcc-O3 timings for 
micro-benchmarks.))


-- 
bartc