[Python-Dev] 2.4 news reaches interesting places
I was pleasantly surprised to find a pointer to this article in a news
digest that the ACM emails me regularly (ACM TechNews).
http://gcn.com/vol1_no1/daily-updates/28026-1.html
One thing that bugs me: the article says 3 or 4 times that Python is
slow, each time with a refutation ("but it's so flexible", "but it's
fast enough") but still, they sure seem to harp on the point. This is
a PR issue that Python needs to fight -- any ideas?
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
[EMAIL PROTECTED]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] 2.4 news reaches interesting places
At 02:18 PM 12/8/04 -0800, Guido van Rossum wrote:
I was pleasantly surprised to find a pointer to this article in a news
digest that the ACM emails me regularly (ACM TechNews).
http://gcn.com/vol1_no1/daily-updates/28026-1.html
One thing that bugs me: the article says 3 or 4 times that Python is
slow, each time with a refutation ("but it's so flexible", "but it's
fast enough") but still, they sure seem to harp on the point. This is
a PR issue that Python needs to fight -- any ideas?
The only thing that will fix the PR issue is to have a Python compiler
distributed as part of the language. It doesn't matter if it doesn't
support the full generality of Python, or even if it doesn't speed many
operations up much. The only real requirements are that it can be used to
produce "native" executables, and that it be an official part of the
language, not a separately-distributed tool like Psyco or Pyrex. Then, it
will perhaps be a sufficient "security blanket" to stop people FUDding
about it.
I imagine you could speed up the Python interpreter until it's faster than
half the Java JIT's out there, and people will still ask, "But can I
compile to an .exe?" On the other hand, if you add a compiler, we'll see
articles like the above talking about how Python can now be compiled and so
therefore it's suitable for all kinds of things it wasn't before. :)
Of course, it would be *really* useful if the compiler were coupled with
optional type declarations for Python-the-language, because then we could
ultimately dispense with the current syntax warts of Pyrex (and the
runtime/distribution warts of ctypes) for interfacing with C. But I don't
think that having the compiler actually be useful is a prerequisite for
solving the PR issue. :)
___
Python-Dev mailing list
[EMAIL PROTECTED]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] 2.4 news reaches interesting places
Guido van Rossum wrote:
I was pleasantly surprised to find a pointer to this article in a news
digest that the ACM emails me regularly (ACM TechNews).
http://gcn.com/vol1_no1/daily-updates/28026-1.html
One thing that bugs me: the article says 3 or 4 times that Python is
slow, each time with a refutation ("but it's so flexible", "but it's
fast enough") but still, they sure seem to harp on the point. This is
a PR issue that Python needs to fight -- any ideas?
In public documents - documentation, release notes, etc etc.:
Remove all references to the performance of Python. From now on, Python
has always been extremely fast, has no need to get any faster, and any
speed increases are of so little importance that they barely rate a
mention (no percentage increases mentioned in release notes).
If you must mention performance, do it in terms of the use of C modules
such as numarray, and for benchmarks that other languages cant compete
in. Write a benchmark which uses common C extensions, that Java cant
compete with.
Replace all references to a 'Python interpreter' with 'Python Virtual
Machine'
Ensure that the terms 'Python compiler' and 'compiled python' are
liberally sprinkled around. Start emphasising the compilation step from
python source to python bytecodes instead of making it transparent.
___
Python-Dev mailing list
[EMAIL PROTECTED]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] 2.4 news reaches interesting places
The only thing that will fix the PR issue is to have a Python compiler distributed as part of the language. It doesn't matter if it doesn't support the full generality of Python, or even if it doesn't speed many operations up much. The only real requirements are that it can be used to produce "native" executables I don't hink it's a matter of native executables. Hopefully all the real algorithms are already in native executables as builtins (dictionary lookup, etc). And generally, one can wrap all the tough code in C and take advantage of the flexibility of python at a higher level. pygame is the best example of this! Basic stuff from complexity theory: the real complex parts are few and isolated in C. For the other we can take advantage of a higher level dynamic language. Stelios ___ Python-Dev mailing list [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] 2.4 news reaches interesting places
On Wed, Dec 08, 2004 at 02:18:48PM -0800, Guido van Rossum wrote: > This is a PR issue that Python needs to fight -- any ideas? I'm not good at PR so I will continue to try to make it faster. In my copious free time I plan to: * finish the AST compiler (no performance benefit but makes other things easier) * optimize module namespaces as per the PEPs (whose numbers I cannot recall) * optimize function/method invocation (we must be able to do something better here, they are currently very expensive). Fredrik has mentioned "call-site caching". * write a new, register based VM ___ Python-Dev mailing list [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] 2.4 news reaches interesting places
[Guido van Rossum Wed, Dec 08, 2004 at 02:18:48PM -0800]
> I was pleasantly surprised to find a pointer to this article in a news
> digest that the ACM emails me regularly (ACM TechNews).
>
> http://gcn.com/vol1_no1/daily-updates/28026-1.html
>
> One thing that bugs me: the article says 3 or 4 times that Python is
> slow, each time with a refutation ("but it's so flexible", "but it's
> fast enough") but still, they sure seem to harp on the point. This is
> a PR issue that Python needs to fight -- any ideas?
What about doing a survey on c.l.py asking questions like:
what do you find runs slowly in Python
that should run faster?
Could you help with some concrete -
preferably real life examples with speed problems?".
If python-dev takes the time to seriously debate (and debunk :-)
upcoming code and suggestions then such a process could
be very useful for all sides and also for PR purposes.
IMO the biggest PR problem is that python programmers themselves [*]
tend to say that Python is slow and it's interesting to find
out why they think so, document and discuss the "answers" if any.
I am not saying that such questioning/discussion doesn't already
happen sometimes. But doing a survey in a more systematic way
might let us find out how pervasive the perception of "Python
is too slow" really is. Maybe it turns out that not many people
have concrete problems to offer? Anyway, this would probably also
be interesting for the various alternative Python implementations
currently in the works.
just an idea,
holger
[*] For example, something i stumbled upon today:
http://unununium.org/articles/languages
where it states (without providing any details!):
But what about that fast system? Python isn't a slow
language; it just has a slow implementation. There are many
projects underway to correct this situation: Psyco, PyPy,
Starkiller, IronPython, and Parrotcode are among them. It's
likely these projects will be nearing completion when the time
comes for Unununium to look at optimizations.
___
Python-Dev mailing list
[EMAIL PROTECTED]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] 2.4 news reaches interesting places
At 01:25 AM 12/9/04 +0200, Stelios Xanthakis wrote: The only thing that will fix the PR issue is to have a Python compiler distributed as part of the language. It doesn't matter if it doesn't support the full generality of Python, or even if it doesn't speed many operations up much. The only real requirements are that it can be used to produce "native" executables I don't hink it's a matter of native executables. As I explained later in that message, "native" simply means, "has an .exe extension on Windows". For PR purposes, it would suffice to bundle py2exe with Python 2.5 and say that Python "now includes a compiler to produce executable files". This will then be picked up and misinterpreted by the trade press in exactly the same way that the article Guido cited picked up and misinterpreted what was said about 2.4. If you read the article carefully, you will notice that the author translated "we rewrote a few modules in C" into "we made Python faster by switching to C". If you ask anybody what language is faster, language X or C, most everybody will answer "C", regardless of what X is (unless it's assembly, of course). All of the discussion about *actually* improving Python's performance is moot for PR purposes. Public perception is not swayed by mere facts (as one might cynically observe of the U.S. political system). If the goal is to achieve a PR win, the important thing is to pick a meme that's capable of succeeding, and stay "on message" with it. The *only* meme that's organically capable of trumping "Python is slow because it's interpreted" is "Python is compiled now". Me, I don't really care one way or the other. I used to sell software I wrote in TRS-80 Basic, so Python's performance is fine for me, and I'm certainly not a compiler bigot. I'm just responding to Guido's inquiry about what might work to increase Python's *perceived* speed in popular consciousness, not its actual speed. ___ Python-Dev mailing list [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] 2.4 news reaches interesting places
Well, for a lot of applications for Python, the performance that really
counts is time from no code but a pile of data to code and processed
data. Python shines at that because nearly always the time to write
the code dominates, so it doesn't matter what the run time is.
I wrote a little tool to translate a bunch of free data into scenery
for the X-Plane flight simulator. If I'd tried to do it in C, I'd
still be debugging it, whereas I released it and the scenery I was
building six months ago. The run time of the C version would be, I
speculate, about 5 times faster than the Python (given that psyco
speeds it up about 8 times, and I would not have been so fancy with the
algorithms in C). But a 5x improvement on a 24 hour runtime is not 6
months of improvement.
The other thing we can do is finish the portable backend for psyco and
make it a standard module. Then Python won't be slow, it will be
compiled, and py2exe will be able to make a single-file executable.
Andrew
On 9/12/2004, at 11:18 AM, Guido van Rossum wrote:
I was pleasantly surprised to find a pointer to this article in a news
digest that the ACM emails me regularly (ACM TechNews).
http://gcn.com/vol1_no1/daily-updates/28026-1.html
One thing that bugs me: the article says 3 or 4 times that Python is
slow, each time with a refutation ("but it's so flexible", "but it's
fast enough") but still, they sure seem to harp on the point. This is
a PR issue that Python needs to fight -- any ideas?
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
[EMAIL PROTECTED]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/
andrew%40indranet.co.nz
___
Python-Dev mailing list
[EMAIL PROTECTED]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] 2.4 news reaches interesting places
On Wed, 8 Dec 2004, Guido van Rossum wrote:
> One thing that bugs me: the article says 3 or 4 times that Python is
> slow, each time with a refutation ("but it's so flexible", "but it's
> fast enough") but still, they sure seem to harp on the point. This is
> a PR issue that Python needs to fight -- any ideas?
>
On PR side of the issue one idea would be to avoid using the words
interpreted/intepreter less and use the
words compiler/byte-compilation/virtual machine instead...
On non-PR side of the issue (I do think that python slowness is a real
problem for at least some people/domains): would
bundling of Psyco with Python be a good idea?
Ilya
___
Python-Dev mailing list
[EMAIL PROTECTED]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
RE: [Python-Dev] 2.4 news reaches interesting places
> One thing that bugs me: the article says 3 or 4 times that Python is
> slow, each time with a refutation ("but it's so flexible", "but it's
> fast enough") but still, they sure seem to harp on the point. This is
> a PR issue that Python needs to fight -- any ideas?
* Ask a prominent PSF member, ESR, to stop bagging on that point in his
book (python is much faster since he wrote it and Moore's law has made
it less of an issue over time). Py1.5.2 running on a 133Mhz 386 is not
the same beast as well designed Py2.4 code running on a 3Ghz Pentium IV
(also I would argue that many apps are computationally bound anyway).
* Have python.org prominently feature an article of Python's use in
high-performance environments. IIRC, somebody wrote a realtime voice
over internet system and found that with good design, there was no speed
issue. Also, the cellphone apps may make a good example.
* Another prominent developer and PSF member wrote a much publicized,
unfavorable log entry basically saying that he was unimpressed with
Py2.4. While that log entry was subsequently revised, it did serve as
anti-advocacy. Also, my request was denied for better presentation of
performance related benchmarks in the widely read What's New document.
Right now, it features somewhat unimpressive and misleading pystone
results.
Were we to show comparative pybench results 2.0 to 2.1 to 2.2 to 2.3 to
2.4, it would become clear that some of the performance concerns are out
of date.
Parrotbench and test_decimal also reveal some modest gains over 2.3.
* A ZDNet reporter had setup a phone interview with me but did not
follow through. I had planned to nip the issue in the bud by focusing
on the Py2.4's vastly improved scalability:
- The trend toward use of iterators, generators, generator expressions,
and itertools scale-up well because of their superb memory performance
and ability to save state. Apps using generators and genexps save all
the time that was formerly lost to accessing instance variables. And
apps keying off of itertools can sometimes completely avoid interpreter
overhead. IOW, Py2.4 provides a strong toolset for writing clean,
high-performance apps with a minimum of development time.
- Behind the scenes, almost every important building block has either
improved algorithms, memory optimizations, speed optimizations, and/or
has been rewritten in C (while still preserving their pure Python
equivalents). The bytecodes get optimized for speed and readability,
and the eval-loop itself is tighter. Lists initialize, append, pop, and
extend much faster and are more conservative with memory. List comps
are up to twice as fast. Dictionary iteration is speedier. Sets,
bisect, and heaps now have C implementations like other basic building
blocks. All of the fifo queues in the library now use an O(1) algorithm
instead of O(n) -- this improves scalability for everything from
threading and queues to mutexs and asynchat.
* Any PR effort should also emphasize that no usability trade-offs were
made along the way. A number of features make Py2.4 easier to use than
1.5.6: list comps, genexps, generators, sets, nested scopes, int/long
unification, decorators, etc. Some might argue that it takes a modicum
effort to learn listcomps, generators, and decorators, but they cannot
make any bones about the cleanliness, simplicity, beauty, and speed of
the resulting code. Python will always lead in maintainability and
development time.
* Python's website has traditionally been self-centered, leaving others
to have to make the case for their own products. Perhaps, it is time to
change that. Those who really care about speed cannot make a balanced
decision about Python without considering psyco, pyrex, numpy, and the
like as part of the total development environment.
* There is another angle that is difficult to present but a reality
never-the-less. It is easy to write toy C / C++ code that is blazingly
fast. However, when you add error checking, fault tolerance,
interaction with real world, etc, the code gets slower. Also because
that code is harder to write, it is somewhat common to use crummy
algorithms (linear searches for example). I really liked Tim's comment
that code using Python's dictionaries runs 10,000 times faster than
anything written in any other language. That seems to get to the point
across well enough.
* A bit of good news is that the upcoming Python cookbook will make a
strong case for Py2.4 being a tool of choice for those who care speed,
space, maintainability, and development time. It is a nice, highly
visible bit of advocacy.
* One last thought. Articles will always pick on something. It's not
really a terrible thing to have someone say the superb productivity
gains come at the price of running slower than C. I would much rather
hear that than have people bag on the docs or standard library or launch
into a diatribe @decocrator destroying the beauty of the language.
Raymond
__
[Python-Dev] PyOS_InputHook enhancement proposal
PyOS_InputHook is a pointer to a function that is called periodically (ten times per second) while Python is idle, for example, when waiting for a user command. Python C extension modules can set this pointer to a hook function defined in the extension module. For example, _tkinter.c makes use of PyOS_InputHook to get messages delivered to its widgets. A problem arises when two or more extension modules want to set PyOS_InputHook. For example, the scientific plotting package pygist needs PyOS_InputHook to get messages delivered to its graphics windows, and may therefore conflict with the Python GUI IDLE, which uses Tkinter. Chaining won't work, as it will fail when an extension module wants to remove its hook function. My suggestion is therefore to replace PyOS_InputHook by two functions PyOS_AddInputHook and PyOS_RemoveInputHook, and let Python keep track of which hooks are installed. This way, an extension module can add a hook function without having to worry about other extension modules trying to use the same hook. Any comments? Would I need to submit a PEP for this proposal? --Michiel, U Tokyo. -- Michiel de Hoon, Assistant Professor University of Tokyo, Institute of Medical Science Human Genome Center 4-6-1 Shirokane-dai, Minato-ku Tokyo 108-8639 Japan http://bonsai.ims.u-tokyo.ac.jp/~mdehoon ___ Python-Dev mailing list [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] The other Py2.4 issue
Acceptance for Py2.4 partially hinges on how quickly third party apps have their binaries updated. I wonder if there is anything we can do to help. Raymond -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Tuure Laurinolli Sent: Tuesday, December 07, 2004 2:51 AM To: [EMAIL PROTECTED] Subject: [Image-SIG] Re: Python 2.4 Spencer Ogden wrote: > I was wondering if there was a time frame for a windows binary for Py > 2.4. Is it possible to compile the source against 2.4 myself? There didn't seem to be any problems compiling it against 2.4. I managed to get some version up and running, but problems with the required shared libraries(I seem to have many, incompatible versions of jpeg around...) killed my enthusiasm and I returned to 2.3. ___ Image-SIG maillist - [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/image-sig ___ Python-Dev mailing list [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
