On Fri, 23 Feb 2018 11:00:28 +0100, Stefan Behnel wrote:
> I've even seen proper Cython benchmark code that a C compiler can fully
> analyse as static and replaces by a constant, and then get wonder
> speedups from it that would never translate to any real-world gains.
This is one of the reasons why typical benchmarks are junk. If you're not
benchmarking actual, real-world code you care about, you have no idea how
the language will perform with actual, real-world code.
There is a popular meme that "Python is slow" based on the results of
poorly-written code. And yet, in *real world code* that people actually
use, Python's performance is not that bad -- especially when you play to
its strengths, rather than its weaknesses, and treat it as a glue
language for stitching together high-performance libraries written in
high-performance languages like C, Fortran, Rust and Java.
Speaking of bad benchmarks, I recall an anecdote about a programmer
running some benchmarks on Fortran code on various mainframes, and found
that one specific machine was millions of times faster than the others.
It turns out that the code being tested was something like this
(translated into Python):
for i in range(1, 1000000):
pass
and the Fortan compiler on that one machine was clever enough to treat it
as dead code and remove it, turning the entire benchmark into a single
no-op.
Your point that we must consider benchmarkers carefully is a good one.
--
Steve
--
https://mail.python.org/mailman/listinfo/python-list
