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

[Steven D'Aprano]

On Fri, 02 Mar 2018 14:45:55 -0600, Python wrote:

> On Mon, Feb 26, 2018 at 09:57:06AM +0000, Steven D'Aprano wrote:
>> Besides, if you want Python with no GIL so you can run threaded code,
>> why aren't you using IronPython or Jython?
> 
> But this is just another oversimplified argument.  In the real world
> there rather often exist constraints which have nothing to do with what
> is technically possible, but which make impractical or infeasible what
> may be technically possible.

Of course it is simplified. As is the argument that the GIL is the source 
of all evil, er, why Python threading is slow.

In reality, we may have good reasons for not using IronPython or Jython, 
such as the desire for the latest 3.x version, or because we rely on C 
external libraries that don't work under the CLR or JVM.


[...]
> But back to the point of the thread, I think it's ironic that you're
> basically making the benchmarks' argument:  Choose the tool which suits
> the solution you need.  You argue we should use IronPython or Jython
> when threads are needed, and the Julia benchmarks *imply* (but never
> actually argue, AFAICT) that if you need a solution which relies on
> heavy use of function calls, since Python will be slower than Julia, you
> should therefore choose Julia instead.

Indeed. While I haven't said so explicitly in this thread, I agree 
entirely with everything you say here. One of the things I'm very 
interested in is the possibility of writing number-crunching code in 
Julia and calling it from Python.

I haven't tried it yet, but it is on my bucket-list :-)


> But that's only a sensible
> conclusion if all other things be equal, which of course they are not,
> neither for Julia vs. Python, nor for Python vs. Jython or IronPython
> (though likely the latter case is slightly closer to being true).

There are always constraints on what language you might use. Foo-lang 
might be the best language for the job, but since I don't know the 
language (or even heard of it), I can't use it. You may be constrained by 
familiarity, shop politics, customer requirements, the availability of 
staff, personal preferences, legal requirements, etc.

But taking all of those things into consideration, the conclusion still 
fits: use the language that suits you and the job best. If that language 
is Python, then this is how you can get the best performance if and when 
needed.



-- 
Steve