On 07/03/2016 20:47, Chris Angelico wrote:
On Tue, Mar 8, 2016 at 7:19 AM, BartC <b...@freeuk.com> wrote:
What can be more perfect for comparing two implementations?
rosuav@sikorsky:~$ python2 -m timeit -s 'from fp import Float'
'Float("1234.567")'
1000000 loops, best of 3: 1.84 usec per loop
rosuav@sikorsky:~$ python3 -m timeit -s 'from fp import Float'
'Float("1234.567")'
100000 loops, best of 3: 2.76 usec per loop
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. But I tried your code, calling Float a
million times, and 2.7 took 8.3 seconds; 3.4 took 10.5 seconds. But that
is meaningless according to you.
(3.1 took 8.5 seconds. What happened between 3.1 and 3.4 to cause such a
slow-down? Do you think it might be a good idea for /someone/ at least
to take pay some attention to that, before it grinds to a halt
completely by version 4.0?)
(I tried near-equivalent code on my byte-coded language. It took 0.7
seconds. Then I tried a fairer test, as I use a bit of ASM to help the
interpreter along: I created a C source version of the interpreter,
compiled it with Tiny C, which generates some of the worst code around,
and ran it again on the byte-code. It took 3 seconds; still faster than
either of the Pythons!)
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.
You write *real world* code and then profile that. You get actual real
programs that you actually really use, and you run those through
timing harnesses.
Sorry, but that is useless. It tells you that slow, interpreted
languages can be viable with certain kinds of usage. Everyone knows that
(I've been creating applications which balance compiled code and
interpreted code since about the mid-80s).
If you want an interpreted language to take on wider range of tasks,
then you need to make it faster, and that means measuring how efficient
it is at executing algorithms itself, not measuring how long some
library in a different language takes to execute.
CPython 2.5 and 2.7 are very different. Even 2.7.0 and 2.7.11 are
going to differ in performance. And that's without even looking at
what core devs would refer to as "other Pythons", which would include
IronPython, Jython, PyPy (well, you got that, but you're treating it
as an afterthought), MicroPython, Brython, wpython, Nuitka,
Cython..... these are *other Pythons*.
What are you suggesting here? That all these Pythons are going to be
faster or slower than each other? I would guess that most of them are
going to be roughly the same, other than PyPy. If there was a fast
version, then I would have heard about it!
the
performance of array.array() is far from stable. It's not a core
language feature; you're using it because it's the most obvious
translation of your C algorithm,
I'm using it because this kind of file reading in Python is a mess. If I
do a read, will I get a string, a byte sequence object, a byte-array, or
array-array, or what?
Are you saying there array.array will not work on some implementations?
In that case it's more of a mess than I thought!
not because it's the best way to use
Python. So I say again, your measurement has little to no significance
to real-world code.
Real world use of Python appears to be as a scripting language and for
glue code, with most of the real work done in libraries implemented in
native code. I acknowledge that. And I understand that the 10-20%
difference between Py2 and Py3 will largely disappear for these kinds of
uses.
But I also said I am interested in using the languages to directly
implement programs and algorithms not just for scripting. Then you need
to be able to measure what the core language is capable of.
--
Bartc
--
https://mail.python.org/mailman/listinfo/python-list
