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

[Steven D'Aprano]

On Fri, 23 Feb 2018 19:25:35 +0000, bartc wrote:

> On 23/02/2018 18:05, Steven D'Aprano wrote:
>> On Fri, 23 Feb 2018 13:51:33 +0000, Ben Bacarisse wrote:
> 
>> Stop writing crap code and then complaining that the language is "too
>> slow". Write better code, and then we'll take your complaints
>> seriously.
> 
> I write compilers for static languages, which are generally considered
> toys, partly because the code generated is not great.

I have no idea whether your compilers are toys, or what "not great" means 
for your generated code.

- too slow for the intended purpose?
- full of bugs?
- generated code is enormous?
- requires too much memory?
- all of the above?

If the actual answer is, "none of the above", then apart from your 
failure to attract users and build a full ecosystem around your compiler, 
I see no reason to call them toys.

If your compilers can get within 10% of best-of-breed C compilers, even 
if only on trivial problems, that's nothing to sneer at. If you can do it 
on non-trivial applications (say, the Linux kernel) without introducing a 
vast number of compiler-generated bugs, then you're doing very well 
indeed.

In another post (responding to Chris) you wrote:

> Python is 10 times slower than a competitor = doesn't matter
> My language is 1.5 times slower than the big boys' = matters 
> a great deal

Maybe it matters to *you*. You are the one who stated it was a toy 
compiler. To me, I have *no idea* whether the compiler is any good. 
Nobody but you uses it. I once tried to compile it, and couldn't get it 
to compile.

As for Python's order-of-magnitude speed difference, thank you for being 
generous. If you cherry-pick the right benchmarks, you could easily have 
said it was two orders-of-magnitude slower. On the other hand, if you use 
PyPy, and similarly cherry-pick the right benchmarks, you can justifiably 
say that *Python is faster than C*. (On carefully chosen examples which 
probably aren't representative of full application performance.)

But okay, let's take "Python is an order of magnitude (between 10 and 90 
times) slower than C" for the sake of the argument. Does it matter?

Maybe. Maybe not. Sometimes it matters. Sometimes it doesn't.

The world's fastest street-legal production car is, so I'm told, the 
Bugatti Veyron Super Sport. It has a top speed of 268 mph and the engine 
has 1200 horsepower. And yet literally *billions* of car drivers choose 
to drive something slower. They wouldn't buy a Veyron even if they could 
afford it. Why shouldn't people make choices based on factors other than 
speed, speed, speed, speed, speed?

Ruby has fallen out of favour now, but for quite a few years it was 
looking like a contender despite being an order of magnitude slower than 
Python. Which is an order of magnitude slower than Java, which is an 
order of magnitude slower than C, according to some benchmarks at least.

People write business applications using Excel spreadsheets and macros. 
And why not?

So it is quite possible to get practical work done and be a competitive, 
useful language despite being (allegedly) a thousand or more times slower 
than C.


[...]
> Have you ever written a benchmark in your life? If so, did it do
> anything useful? Other than what benchmarks are normally used for.

Yes I have, not for what benchmarks are normally used for (dick-measuring 
contests between programmers competing to see whose language is more 
macho) but for the very practical purposes of:

(1) Deciding which algorithm to use in practice;

(2) Ensuring that updates to the code don't suffer serious performance 
regressions;

(3) And checking that the code is *fast enough* (not as fast as 
conceivably possible) for its purpose.

They are the sorts of benchmarks I care about.


-- 
Steve