From: "Ethan Glasser-Camp" <[EMAIL PROTECTED]>
To: <pygame-users@seul.org>
Sent: Saturday, November 03, 2007 8:30 PM
Subject: Re: [pygame] Quick question from newbie
Hi,
Please see attached. Running it on my system gives:
Dummy, True: [0.41186404228210449, 0.37368297576904297,
0.37651586532592773]
.
.
.
Hi Ethan
Yes, the last timing of it makes sense and as I wrote in assembly language the
format probably in memory would require twice as many clock cycles to check for
the greater than 9. Now if you were to reverse the statement logic the speed
would change and only change depending on what numbers are coming into the
check.
In other words if you know there is more of one kind of number then the
other it makes sense to place the order accordingly.
NOTE:
When checking a comparison it takes more clock cycles to do the jump then
to pass right through to the second comparison. So it depends on the numbers
involved both within the comparison trap and not in the trap. For if there are
more numbers above the check it takes the longest for it has passed one check
and jumped in the second, thus 2 comparisons and a jump to get anything over 9
out.
Now if most numbers fall within the check and pass through to do the
statement beneath the if without the jump, then that is the fastest processing
time. Because no jumps out of the check required. Speed will slow down
accordingly on more above then below, and the reverse is also true...
In other words if the numbers are mostly above 9 then that will eat up the
time if thousands of checks are being done or faster if most numbers are below
1. With the least amount of time when most of the numbers are within 1 and 9
because no jumps out of the check were needed.
If you had most numbers above 9 then reverse the logic check then it will
have one comparison and a jump. So you have to know what you expect to see.
Which is true since it was faster to have the 9 check done first as shown below.
SO:
When writing and speed is important the only time this kind of speed is
required is when you are processing large amounts of data and then you will add
up the jumps taken within the check. So just look at your logic and in what
place is it being used. Like the example of time it can appear to me
meaningless, unless you are doing a lot of comparisons and many out of the
bounds of the check have been caught...
If most numbers are in the range then keep the logic as is. If you expect
more above 9 then reverse the logic statement. Or just keep it as is if the
numbers are equally balanced.
Bruce
Hi Ian,
It depends on how they did the comparison. For in machine code you do a
register to memory check or memory to memory check or register to register
check. The clock cycles are more in moving memory or comparing memory because
of the need to address the memory point.
It depends on how they wrote the comparison. It also depends on the order
of checking and if memory had to be moved to do it and that to depends on the
programmer and how they decided to do the logic for the check.
Like assembler code:
cmp [i],1
jl move-on
cmp [i],9
jg move-on
do something here
move-on:
I used [] brackets to indicate the memory location of the i variable. Now in
the other comparison I suspect that the way that check goes they had to either
create a location for 1 or move i into a register and in either case more clock
cycles needed to process the check.
the first one above in my example is the faster check and mirrors the
second comparison and would be standard machine code for the comparison. Now
the other logic on how the stringing of comparisons is done, I suspect that the
one of those check objects have to be moved into an area before the check in
order to decode the logic...
Thus the comparison in the first case below just requires lots more clock
cycles to process it.
Bruce
On 11/3/07, David Muffley <[EMAIL PROTECTED]> wrote:
If I recall correctly, the syntax
if 1 <= i <= 9
runs slower than the syntax
if i <= 9 and i >= 1
Somewhere around 10% slower. If you use psyco, it goes about 40% slower!
Do you know why?
Ian
