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
