I'm afraid that No amount of optimisation will suffice--even C is too slow.
I've found examples of how to use shaders on the GPU. This should be
faster, and relevant too, as the algorithm in question is somewhat
pertinent to graphics processing.
Ian
On Sat, 26 Apr 2008, Ian Mallett wrote:
I would conclude this message simply by saying, for those working on
Python, keep working on making it faster. Good job.
And as I've mentioned so many times, this is not the place to post such a
message.
Richard
Ian,
Below is a simple check knowing only the angle of the vector. The while
loop is moving along that vector in steps. Now this is what is needed inside a
normal screen with 2 or more objects. For the angle between them is what is
being used here. This assumes one is static and one
OK, my point here is that if C languages can do it, Python should be able to
too. I think all of this answers my question about why it isn't...
On Fri, Apr 18, 2008 at 9:23 AM, Ian Mallett [EMAIL PROTECTED] wrote:
OK, my point here is that if C languages can do it, Python should be able to
too. I think all of this answers my question about why it isn't...
You don't have to use C to get fast programs. OCaml is very fast
(between C and
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of Nathan Whitehead
Sent: Friday, April 18, 2008 11:24 AM
To: pygame-users@seul.org
Subject: Re: Re: [pygame] Python and Speed
On Fri, Apr 18, 2008 at 9:23 AM, Ian Mallett [EMAIL PROTECTED] wrote:
OK
On Apr 18, 2008, at 9:23 AM, Ian Mallett wrote:
OK, my point here is that if C languages can do it, Python should be
able to too. I think all of this answers my question about why it
isn't...
C can do what? C is, at best, a constant time improvement in
performance over python. A bad
True, although that constant is often on the order of 20, and 40 FPS is
a lot different than 2FPS.
--Mike
Casey Duncan wrote:
On Apr 18, 2008, at 9:23 AM, Ian Mallett wrote:
OK, my point here is that if C languages can do it, Python should be
able to too. I think all of this answers my
On Apr 18, 2008, at 1:31 PM, Michael George wrote:
True, although that constant is often on the order of 20, and 40 FPS
is a lot different than 2FPS.
--Mike
Casey Duncan wrote:
On Apr 18, 2008, at 9:23 AM, Ian Mallett wrote:
OK, my point here is that if C languages can do it, Python should
Ian Mallett wrote:
What is the difference between a tree and a cell? Cells
are regular?
Yes. The term tree implies a recursive data structure --
in this case, that the cells can be further divided
into subcells, and those into subsubcells, etc., to
arbitrary depth.
If the division only goes
Casey Duncan wrote:
And I further
propose that when the time arrives that machine intelligence exceeds
our own, this will not be the problem foremost on my mind ;^)
Python 49.7 (#1, Aug 5 2403, 15:52:30)
[GCC 86.3 24020420 (prerelease)] on maxbrain
Type help, copyright, credits or license
-I think it has been thoroughly established that Python cannot be as fast as
C.
-As far as algorithms go, intelligence is better, but I hold by using vastly
simpler ones to speed development. Someone just mentioned sorting methods.
In that case, obviously, a little extra coding doesn't hurt, but
Learn to write C. The best software is written as a hybrid of multiple
technologies, each serving a different purpose. Python's strengths are rapid
development and succint, easy to read code. C's strengths are flexibility and
machine optimization. MMX and SSE assembly code are for maximum
On Fri, Apr 18, 2008 at 8:14 PM, Richard Goedeken
[EMAIL PROTECTED] wrote:
Learn to write C. The best software is written as a hybrid of multiple
technologies, each serving a different purpose. Python's strengths are
rapid development and succint, easy to read code. C's strengths are
The way I speed up my python code is Ctypes.
I just make a dll file in C or asm and then call it with Ctypes and presto.
I have tons of speed at my fingertips.
Just my 2 cents :)
On Thu, Apr 17, 2008 at 2:21 PM, Greg Ewing [EMAIL PROTECTED] wrote:
René Dudfield wrote:
2. - asm optimizations. There seems to be
almost no asm optimizations in CPython.
That's a deliberate policy. One of the goals of CPython
is to be very portable and written in a very
René Dudfield [EMAIL PROTECTED] wrote:
On Thu, Apr 17, 2008 at 2:21 PM, Greg Ewing
[EMAIL PROTECTED] wrote:
René Dudfield wrote:
2. - asm optimizations. There seems to be
almost no asm optimizations in CPython.
That's a deliberate policy. One of the goals of CPython
Hi!
No, this is the place to discuss it because if we wish to make games,
work with existing platforms, and want speed, that is the way to go. Now
that we have had this discussion, and found solutions, now we have a list of
ways to resolve it.
This is the place to discuss all of this
On Thu, Apr 17, 2008 at 2:21 PM, Greg Ewing [EMAIL PROTECTED]
wrote:
René Dudfield wrote:
2. - asm optimizations. There seems to be
almost no asm optimizations in CPython.
That's a deliberate policy. One of the goals of CPython
is to be very portable and written in a
I see a slight problem with these architecture specific optimisations,
once you
release your game out onto the general public, even if you were using
super
optimized awesomeness and everything ran fine, the majority of people will
be running whatever version of the library came with there
On Apr 16, 2008, at 6:36 PM, Ian Mallett wrote:
Recently, I've been having issues in all fortes of my programming
experience where Python is no longer fast enough to fill the need
adaquately. I really love Python and its syntax (or lack of), and
all the nice modules (such as PyGame) made
On Apr 17, 2008, at 11:59 AM, Ian Mallett wrote:
[..]
This is precisely the problem I have run into in one of my in-dev
games--iterating over large arrays once per frame. Actually, it is
basically a collision detection algorithm--I have two arrays, both
containing 3D points. The points
On Apr 17, 2008, at 12:15 PM, Casey Duncan wrote:
Note ode already implements efficient 3D collision detection in
naive code, I believe pymunk does this for 2D. pyode is a python
wrapper for ode.
heh, I meant to say native code 8^)
-Casey
On Thu, Apr 17, 2008 at 12:15 PM, Casey Duncan [EMAIL PROTECTED] wrote:
Note this is not the most efficient way to do this, using a partitioned
space you may be able to avoid comparing most points with one another most
of the time. To do this in 2D you could use quad-trees, in 3D you could use
On Wed, Apr 16, 2008 at 7:30 PM, Ian Mallett [EMAIL PROTECTED] wrote:
Thus it falls to you as a developer to choose your implementation strategy
wisely:
But again, this is treating the symptoms, not the problem...
I actually think the line of thinking I read in the comment above (thinking
On Apr 17, 2008, at 12:26 PM, Ian Mallett wrote:
On Thu, Apr 17, 2008 at 12:15 PM, Casey Duncan [EMAIL PROTECTED]
wrote:Note this is not the most efficient way to do this, using a
partitioned space you may be able to avoid comparing most points
with one another most of the time. To do this
On Thu, Apr 17, 2008 at 12:39 PM, Brian Fisher [EMAIL PROTECTED]
wrote:
I actually think the line of thinking I read in the comment above
(thinking that I shouldn't have to optimize things, because the stupid
language is slow) is in fact a counterproductive attitude in application
Hi!
I am just making an observation on this and objects, maybe I am missing
the point, but when checking collisions, if you know your objects size, the
vertex, or point depending on direction, could you not not solve this by
just the direct line between the 2 objects and not the surface?
On Thu, Apr 17, 2008 at 12:45 PM, Casey Duncan [EMAIL PROTECTED] wrote:
Partitioned space is certainly a more complex algorithm, but so long as
all of your points (spheres?)
Yes, one can think of one array as points and the other as spheres.
are not close together, it is usually vastly more
I'm not sure precisely what you mean...
Again, remember that this is an example, not the question. The question is
How can Python be made Faster? This is an example of one of the problems
resulting from Python's relative slowness.
Here's the example:
-There is a list of 3D points
-There is
In that specific case, no matter which programming language you use,
your code will not be very fast. Do you think programmers write
unoptomized code in c, and get speedy execution every time? Have you
not ever used a program or played a game which ran slower than it
should, which was actually
On Thu, 17 Apr 2008, you wrote:
No, this is the place to discuss it because if we wish to make games,
work with existing platforms, and want speed, that is the way to go. Now
that we have had this discussion, and found solutions, now we have a list
of ways to resolve it.
Sure, discuss
Patrick Mullen wrote:
Also, if you are using sqrt for your
distance check, you are likely wasting cpu cycles, if all you need to
know is whether they are close enough.
Also note that if you do need to compare exact Euclidean
distances for some reason, you can avoid square roots
by comparing
Ian Mallett wrote:
Here's the example:
-There is a list of 3D points
-There is another list of 3D points.
-Every frame, for every point in the first list, if any point in the
second list is a certain 3D distance away, then there is a collision.
The responses to it also provide a good example
René Dudfield wrote:
- SIMD instructions are the fast ones...
It's doubtful there's much in the Python core that would
benefit from SIMD, though. Most of what it does doesn't
involve doing repetitive operations on big blocks of
data.
--
Greg
Ian Mallett wrote:
How do you write an extension module in C and call it from Python?
Someone gave some instructions earlier, but I found them too vague...
Another way I forgot to mention earlier is to use the
ctypes module (I often forget about it, because it wasn't
in the stdlib until very
Ian Mallett wrote:
Yes, I've tried this, but there are issues with points being in two
separate places. For example, if the collision radius is 5, and it is 3
away from the edge, then all the points in the neighboring trees must be
tested.
Rather than a tree, you may be just as well off
ctypes is great stuff! I find it much harder to crash the interpreter
with ctypes than with extensions I've developed and debugged. It is
quite resilient. I've used it to interface with the Windows API to
simulate keystrokes, to interface to a USB Digital IO interface, in a
wrapper for the
Hi!
Another thought, same as before but adding the other comment about bins.
If your object is heading in a certain direction and you know the surface
point of that object, now make a dictionary key point for it. Same for all
other objects, knowing there direction.
Ian Mallett wrote:
Programmers shouldn't have to
optimize their inefficiently executed code, the code should just be
executed efficiently.
Even if your inefficient algorithm is being executed as fast
as possible, it's still an inefficient algorithm, and you
will run into its limitations with
Devon Scott-Tunkin wrote:
would you set out 2d partitioning the
screen in pygame by making say 4 invisible sprites
with rects ... or by just using x,y values
Just use coordinates. Sprites are totally unnecessary,
since they're not something that appears on the screen.
--
Greg
On Thu, Apr 17, 2008 at 3:03 PM, Greg Ewing [EMAIL PROTECTED]
wrote:
Patrick Mullen wrote:
Also, if you are using sqrt for your
distance check, you are likely wasting cpu cycles, if all you need to
know is whether they are close enough.
Nope; in this case, the calculations' margin of
Ian Mallett [EMAIL PROTECTED] wrote:
... if C++ can do it, Python should be able to too. Obviously, I don't know
how Python is structured ...
Then please learn more about CPython's internals and the general problem of
optimising a dynamic language like Python. The CPython code is incredibly
On Wed, Apr 16, 2008 at 6:43 PM, Dan Krol [EMAIL PROTECTED] wrote:
Are you familiar with the handful of ways to optimize parts of your code?
I've used Psyco to great effect, but all of these extra modules seem to be
treating the symptoms, not the problem. The problem is flat-out and
Ian Mallett wrote:
I feel like Python is living down to its namesake's pace...
Ah yes, the speedy Monty Python.
On Wed, Apr 16, 2008 at 6:59 PM, Aaron Maupin [EMAIL PROTECTED] wrote:
Ah yes, the speedy Monty Python.
I love Monty Python!
I was referring to the general lethargic natural of the snake.
Ian
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.
There's also work on things like pypy - which might one day be quite
fast. I think pypy will drive Cpython to get faster
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
Hi Ian,
I think what you are saying and I agree, is that when someone has fixed
something by going back to C code, then why not make a module for that code.
Thus all you do is insert the C code using a Python/Pygame module name...
But slowing down is when it uses the Python interpreter,
On Wed, Apr 16, 2008 at 7:46 PM, FT [EMAIL PROTECTED] wrote:
Hi Ian,
I think what you are saying and I agree, is that when someone has fixed
something by going back to C code, then why not make a module for that
code.
Thus all you do is insert the C code using a Python/Pygame module
Ian Mallett wrote:
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.
But adopting the same procedures as C would mean becoming
a
On Wed, Apr 16, 2008 at 9:10 PM, Greg Ewing [EMAIL PROTECTED]
wrote:
There are various ways of addressing the speed issue
with dynamic languages. One is what's known as type
inferencing, where the compiler examines the whole
program, thinks about it very hard, and tries to convince
itself
René Dudfield wrote:
2. - asm optimizations. There seems to be
almost no asm optimizations in CPython.
That's a deliberate policy. One of the goals of CPython
is to be very portable and written in a very straightforward
way. Including special pieces of asm for particular
architectures isn't
53 matches
Mail list logo
