On Wed, Apr 16, 2008 at 7:04 PM, Richard Jones <
[EMAIL PROTECTED]> wrote:
> Ian Mallett <[EMAIL PROTECTED]> wrote:
> > Are there any plans to improve Python's speed to
> > at least the level of C languages?
>
> This isn't really the best forum for asking such a question. I would
> recommend asking on the general Python mailing list / newsgroup
> ("comp.lang.python" on http://www.python.org/community/lists/).
I know, but this list is so responsive, and the problem can actually be
related to pygame--although somewhat remotely. Python is slower than C and
so will be used less. Pygame depends on Python's success. We should be
concerned about the future of Python because it determines our future as
well. OK, so I posted to the wrong list...
> I think I speak for all Python developers when I say that we'd love for
> the language to run faster. And of course the large body of core CPython
> developers are aware of this. I've personally attended a sprint in Iceland
> during which we spent a week solely focused on speeding up the CPython
> interpreter.
>
> There's just not much that can be done with the current CPython
> implementation to make it faster.
Why not? If C is faster, why can't Python be equally so? If we assume that
C is the fastest a language available, then that implies that Python
*could*be faster should it adopt the same procedures as C.
I've gathered that Python is based on C code, so it translates your code
into C code on the fly. I have not idea whether this is veritable...
Obviously, this results in slow-downs. Do what C does, don't try to copy
it...
> Thus it falls to you as a developer to choose your implementation strategy
> wisely:
But again, this is treating the symptoms, not the problem...
> 1. pick sensible libraries that handle large amounts of processing for you
> (whether that be numeric or graphic)
I assume these libraries are written in C, correct? What if it didn't
matter and they culd be written in Python or C with no noticeable speed loss
or gain? that would be great!
> 2. where there is no existing library, you may need to code speed-critical
> parts of your application using C, or the more programmer-friendly Pyrex
> (er, Cython these days I believe :)
This last I am interested in. Obviously, I can't really do much for
Python's speed, so I do need to consider my implementations. How can you
run a C file from a Python script? This would speed some of my projects up
enormously...
On Wed, Apr 16, 2008 at 7:04 PM, René Dudfield <[EMAIL PROTECTED]> wrote:
> hi,
>
Hi
> Each release of python gets a little faster... but not massively. It
> really needs to get 10-20x faster - but generally only gets up to 1.2x
> faster with each release.
Why is this? If Python is based on C, is C getting faster by only 1.2x each
release?
> There's also work on things like pypy - which might one day be quite
> fast. I think pypy will drive Cpython to get faster through
> competition - and ideas. An example of this recently happening is the
> method cache (which I think the idea actually came from tinypy...).
> The method cache was shown to work well with pypy, and then Cpython
> added the idea. If pypy becomes faster, then I think the Cpython
> people will try harder to make Cpython faster too.
I would like to get to the point where Python and C are competing
speed-wise.
> However mainly it's good to try and make highly reusable, and fast
> basic building blocks - and then glue them together with python.
in C?
> For example, if you see something that most pygame games would get
> faster with, then add it to pygame. Or to SDL, or to python. If the
> drawing part of the game takes 10% less time, that leaves 10% of time
> for game code. As examples in the last pygame release - The
> pygame.sprite.LayeredDirty sprite work, the threading work, and
> modifications to some functions to allow reusing surfaces(eg
> transform.scale) in the last pygame should make a lot of pygame games
> quicker. For SDL the blitters have been optimized with mmx, and
> altivec assembly - and the upcoming SDL 1.3 can optionally use opengl,
> and direct3d hardware acceleration.
>
> Also the included PixelArray should allow you to do a lot of things
> quicker - and you can rely on it to be included with pygame(unlike
> numeric/numpy). We hope to have fast vector, and matrix types
> included at some point in the future too.
>
> If you've got any ideas for reusable speed ups - we'll gladly consider
> them in pygame.
The things I included in my Pygame Advance Graphics Library I think are good
candidates. I use the particle systems all the time, for instance. These
are just shortcuts--they really aren't *speed-improvements*, except in the
game development field, where they would help people rapidly prototype a
game concept. Ideally, I would like to see my library become obsolete by
adding similar stuff to PyGame. But:
At a certain point, too, PyGame would provide too much--for example, though
faster, pygame.draw.dotted_line() would be used so infrequently as to
clutter the documentation and library in general. The correct method would
be to leave these functions out of PyGame, and just let other people, like
me, come up with extensions--which would provide the function at a balance
between speed and clarity.
Again, all this is just treating the symptoms. Python is slow, and while
optimizations can only be made, it's like fixing a broken submarine with
duct tape. Solution, get a new sub.
> cheers,
Ian
