(original) (raw)

Le 24/04/15 19:45, Paul Sokolovsky a écrit :

Hello,

On Fri, 24 Apr 2015 18:27:29 +0100
Ronan Lamy <ronan.lamy@gmail.com> wrote:

PyPy's FAQ
has an explanation of why type hints are not for performance.
http://pypy.readthedocs.org/en/latest/faq.html#would-type-annotations-help-pypy-s-performance

You probably intended to write "why type hints are not for \*PyPy's\*
performance". There're many other language implementations and
modules for which it may be useful, please don't limit your
imagination by a single case.

Those points apply to basically any compliant implementation of
Python relying on speculative optimisation. Python is simply too
dynamic for PEP484-style hints to provide any useful performance
improvement targets.

What's your point - saying that type annotations alone not enough to
achieve the best ("C-like") performance, which is true, or saying that
if they are alone not enough, then they are not needed at all, which
is ... strange ?

My point is that the arguments in the PyPy FAQ aren't actually specific to PyPy, and therefore that the conclusion, that hints are almost entirely useless if you’re looking at performance, holds in general.
So let me restate these arguments in terms of a generic, performance-minded implementation of the full Python language spec:

\* Hints have no run-time effect. The interpreter cannot assume that they are obeyed.
\* PEP484 hints are too high-level. Replacing an 'int' object with a single machine word would be useful, but an 'int' annotation gives no guarantee that it's correct (because Python 3 ints can have arbitrary size and because subclasses of 'int' can override any operation to invoke arbitrary code).
\* A lot more information is needed to produce good code (e.g. “this f() called here really means this function there, and will never be monkey-patched” – same with len() or list(), btw).
\* Most of this information cannot easily be expressed as a type
\* If the interpreter gathers all that information, it'll probably have gathered a superset of what PEP484 can provide anyway.

And speaking of PyPy, it really should think how to improve its
performance - not of generated programs, but of generation itself.
If compilation of a trivial program on a pumpy hardware takes 5
minutes and gigabytes of RAM and diskspace, few people will use it
for other purposes beyond curiosity. There's something very
un-Pythonic in waiting 5 mins just to run 10-line script. Type
hints can help here too ;-) (by not wasting resources propagating
types thru the same old standard library for example).

Sorry, but that's nonsense. PyPy would be a seriously useless
interpreter if running a 10-line script required such a lengthy
compilation, so, obviously, that's not what happens.

You seem to misunderstand what PyPy is: it's an interpreter with a
just-in-time compiler, not a static compiler. It doesn't generate
programs in any meaningful sense. Instead, it interprets the program,
and when it detects a hot code path, it compiles it to machine code
based on the precise types it sees. No resources are wasted on code
that isn't actually executed.

Regardless of whether I understood that meta-meta stuff, I just
followed couple of tutorials, each of them warning of memory and disk
space issues, and both running long to get results. Everyone else
following tutorials will get the same message I did - PyPy is a
slow-to-work-with bloat.

Ah, I suppose you're talking about the RPython tool chain, which is used to build PyPy. Though it's an interesting topic in itself (and is pretty much comparable to Cython wrt. type hints), it has about as much relevance to PyPy users as the inner workings of GCC have to CPython users.

Well, the thing is that people don't seem to want to write PyPy tutorials, because it's boring. However, I can give you the definitive 3-line version:
1\. Download and install PyPy \[http://pypy.org/download.html\]
2\. Launch the 'pypy' executable.
3\. Go read https://docs.python.org/2/tutorial/

As for uber-meta stuff PyPy offers - I'm glad that's all done in
my favorite language, leaving all other languages behind. I'm saddened
there's no mundane JIT or static compiler usable and accepted by all
community - many other languages have that.

This all goes pretty offtopic wrt to the original discussion, so again,
what's your point - you say that all these things can't be done in
Python, or there's no need for it to be done? That people should look
somewhere else? I submitted a bug to jinja2 project and posted message
on its mailing list - I didn't get reply for 3 months. Why? Because its
maintainer went hacking another language, how was it called, alGOl, or
something. You want me and other folks to go too? Sorry, I'm staying so
far, and keep dreaming of better Python's future (where for example if
I need to get more performance from existing app, I can gradually
optimize it based on need, not rewrite it in another language or be
hitting "not implemented" in uber-meta stuff).

"If you want your code magically to run faster, you should probably just use PyPy" - Guido van Rossum - https://www.youtube.com/watch?feature=player\_detailpage&v=2wDvzy6Hgxg#t=1010

\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: https://mail.python.org/mailman/options/python-dev/kmod%40dropbox.com