On 24/02/2018 00:45, Dan Stromberg wrote:
On Fri, Feb 23, 2018 at 1:32 PM, bartc <b...@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
--
https://mail.python.org/mailman/listinfo/python-list

Reply via email to