Re: [Arianne-general] TODO Lists

[Guido de J. <gu...@us...>]

On Monday 04 March 2002 23:47, MIGUEL ANGEL BLANCH LARDIN wrote:
> Mensaje citado por: Guido de Jong <gu...@us...>:
> > Assuming that you mean Piece::isInRange():
> > I think I can do something about the performance issue here. According
> > to the
> > comment:
> >
> > /** Returns objects in the given cylinder. */
> >
> > The keyword here is "cylinder". Is that still what you want? If so it
> > most
> > certainly can be havily optimized. If not I think I can still do a
> > little on
> > performance, but an extra dimension requires more instructions.
>
> To be exactly, I think it is a sphere.
> It will be whatever object that is nearer than the max lenght.

OK, a sphere it is. I suppose that's better indeed.

> Anyway, what is your idea to improve it?

The first option is by design. That's why I asked about the cylinder/sphere. 
I have some more questions in that respect.

- All objects have a cylindrical shape. I assume that the position of an 
object is the exact center of that cylinder, right?

- An object also has an orientation which determines how the object is 
turned. A sword could be lying on the ground or hanging upright on a wall or 
whatever. Right?

- From the code I understand that even if only a tiny tip of an object is 
inside the spher, than it should be returned in the list by isInRange. Note 
that the current code does not take the orientation of an object into 
account. The question really is: can this be simplified by only returning 
objects of which the position (= center?) is inside the sphere? Determining 
whether a tiny tip is just inside involves a lot more calculations.

When the code is optimized by design, there's still a lot that can be done by 
implementation details. It is very important to make the loops that are 
executed the most are the shortest. You will have to take into account that 
some instructions take more time than others.

In this case:

- The variable vol_split is not used, so it can be removed.

- All instructions using the same variables should be moved after eachother 
to give the optimizer of the compiler a hint (or trust the optimizer to do 
that for you, but personally I do not trust gcc too much in that respect)

- The part before || in the condition for adding to the list can be removed 
too because the second part is enough.

- The Distance() method should not be used. In stead calculate the square of 
the Distance parameter before entering the loop. Then only calculate the sum 
of the squares of the position coordinates of each object. Next compare the 
square distances. This saves taking the square root for each object in the 
list, which is an extremely costly function!

I can think of a few more optimisations, but those will gain you less. Also 
I'm a bit worried about the current Distance calculation, because it means 
that the distance along one coordinate can not be more than about 65000, 
otherwise squaring will result in overflows.

Guido