On 08/03/2016 00:05, Ben Finney wrote:
BartC <b...@freeuk.com> writes:
On 07/03/2016 20:47, Chris Angelico wrote:
Look! Creating a floating-point value is faster under Python 2 than
Python 3. What could be more perfect?
This is like a microbenchmark in that it doesn't tell you anything
about real-world usage.
Microbenchmarks have their uses, when you are concentrating on a
particular aspect of a language.
The “micro” is not referring to the focus of the operation; that's a
good thing to do and is a way to produce useful, salient results. Choose
a specific aspect and design a test case which focusses as narrowly as
possible on that aspect. Then you can gather data to make meaningful
statements about that aspect in isolation from others.
What is “micro” about the benchmark you showed is that it doesn't gather
enough data to be useful. The test should not just do one statement; it
should do some relevant complete unit of the algorithm. Focussed, but
interesting: a huge amount of data, or a complex data conversion, or
something else that qualifies as “real”.
What's the purpose of the measurement? In my case, I'm not just
measuring, but also implementing: either developing a program (the
decoder for example) and trying to get it fast, and/or using it to tweak
some interpreter or other I'm working on. Then I might well want to
focus on particular single byte-code or some narrow aspect of the program.
Anyway, is reading a jpeg not real world usage? It's a task normally
done with a compiled language, but can also be a good test for an
interpreted one.
Try testing on a large battery of highly varied JPEG images, and getting
the aggregate results from that. Or something that is more interesting
(i.e. relevant to the real usage) than one image.
If your efforts manage to double the speed of reading file A, then
probably the reading file B is also going to be improved! In practice
you use a variety of files, but one at a time will do.
If there was a fast version, then I would have heard about it!
The mistake, I think, is in assuming a “fast version” means anything.
Yes of course it does. As does 'being slow'. Take another microbenchmark:
def whiletest():
| i=0
| while i<=100000000:
| | i+=1
whiletest()
Python 2.7: 8.4 seconds
Python 3.1: 12.5 seconds
Python 3.4: 18.0 seconds
Even if you don't care about speed, you must admit that there appears to
be something peculiar going on here: why would 3.4 take more than twice
as long as 2.7? What do they keep doing to 3.x to cripple it on each new
version?
(For comparison, my interpreter managed 0.4s, PyPy 0.3s (it's hot on
loops) and part-optimised C might be 0.07s (fully-optimised would be 0s).)
So you might say that a 'fast' version wouldn't give silly timings like
the above.
Trying something like the silly loop above on a new language can be
quite revealing.
--
Bartc
--
https://mail.python.org/mailman/listinfo/python-list
