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
Hello,
On Fri, Apr 25, 2008 at 3:26 PM, Casey Duncan <[EMAIL PROTECTED]> wrote:
> Perhaps you could post the code or a synapsis of the algorithm and a hint
> at what you are trying to do (I'm not sure if we're still talking about the
> collision detection thing or something else)?
I've already do
On Apr 25, 2008, at 2:15 PM, Ian Mallett wrote:
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.
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
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 moving
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
>
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 pe
-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 c
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 "li
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 go
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
Hi!
I guess we could talk any language to death on speed, but being smart on
how to speed up the existing one is the best approach.
As I said, Ian could use the example I gave him and the other comments
which he has already said he does. The distance instead of the square root
for that is
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 quest
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 algor
> -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 M
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
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...
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 incredib
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'
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
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 a
Ian Mallett wrote:
I see the
difficulty in speeding it up, but it seems like it can't be that
incredibly hard, and I expect that already there are modifications that
could be done to Python that simply haven't been.
There are an extremely large number of modifications
that could be made to Py
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.
key=str(x)+str(-y)+str(
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 huge
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 us
Hi,
yeah, the point is to make it so that on for example, the Debian i386
platform, there are optimised versions compiled too. So that if you
have a p4, on debian the p4 library will be loaded - not the i386 one.
Much like how the current blitters use mmx if it is available on the
platform now.
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
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:
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
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 t
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
On Thu, Apr 17, 2008 at 1:47 PM, Devon Scott-Tunkin
<[EMAIL PROTECTED]> wrote:
> Just out of curiousity as a complete newbie
> programmer, would you set out 2d partitioning the
> screen in pygame by making say 4 invisible sprites
> with rects like say:
The way I do binning is to keep track of
>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 oct-trees
Just out of curiousity as a complete newbie
programmer, woul
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 pr
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 ano
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 vastl
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: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
> devel
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 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 (th
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 coul
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 11:59 AM, Ian Mallett <[EMAIL PROTECTED]> 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 poi
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 in
On Thu, Apr 17, 2008 at 11:08 AM, Casey Duncan <[EMAIL PROTECTED]> wrote:
>
> Python is slow, it is an interpreted language geared toward rapid
> application development at the expense of execution speed. It is also
> designed to be highly portable, also at the potential expense of execution
> spee
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 fo
>
> 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 t
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 p
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 and
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. On
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
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 :)
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 u
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
> i
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 statica
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 modu
On Thu, Apr 17, 2008 at 12: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
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: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 aski
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.
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 thro
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
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: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
final--P
Are you familiar with the handful of ways to optimize parts of your code?
Swig is the classic one I think, it wraps some C source into a python module.
Pyrex does a similar thing, but it lets you wrap it yourself with a
python-esque language; it lets you use python types and C types within
the sa
65 matches
Mail list logo