> 
> Tor Olav Kristensen wrote:
> >
> > (from megasrc07.zip)
> >
> > I have just had a little peek into that c-file
> > and found that it might be possible to do some
> > simplifications of the code within it.
> >
> [SNIP]
> > This introduces one extra local variable; omc,
> > but I hope there will be a little speed gain anyway.
> 
> Do you have any idea WHEN Compute_Axis_Rotation_Transform is called ?
> And how many time ?
> My current guess is (because I did not check yet,
> only performing from memory of the code):
>  - At parse time only.
>  - once per invoking directive.

Yes, I checked were it was called from prior to posting,
- and found that it was only called from Express.c in
the official version (v3.1g).

But I found that in MegaPOV it was also called from photons.c;
i.e. from ShootPhotonsAtObject() in relation with the jitter
option for area lights. 

So therefore I assumed that it might get called a lot if many
photons were shot from a jittering area light.

(Compute_Axis_Rotation_Transform() is also called from render.c,
in relation with SPHERICAL_CAMERA, but I haven't looked at that
code yet.)

> If you were trying to get some significant speed improvement, I'm afraid
> you will be disappointed: it's in the wrong location, at the wrong time.

Hmmm...
I don't understand how I can be looking in the wrong location
at the wrong time.

I was only looking at a math-part of some POV-Ray code that I
found interesting and told others about something that seemed
to be a simplification to me.

Would you people prefer that I shut up about my findings, just
because POV developers are busy with v3.5 coding ?

My opinion is that knowledge about any potential speed
improvements and simplifications to POV-Ray might be valuable
in the future (be it mathematical, logical or algorithmic).

I think that if one posts such suggestions here, there is a
slight chance that will be read and hopefully remembered when
the time to rewrite POV-Ray comes.

(Yes, I see now that I should probably should have posted to
povray.programming instead.)


> P.S.: If I am wrong, do not hesitate: Open fire... I will apologise later.
> 

The fact that v3.1g does not use Compute_Axis_Rotation_Transform()
to do time consuming stuff, while MegaPOV seems to do, suggests
that it might be wise to code such small "general" routines with
care.


> P.S.2: Smart compiler may already have factored
> the (1 - cosx) result in a register, so forcing to use a named variable
> might even be counter productive (because it must be written to the memory
> location, for nothing).

Yes, a colleague of mine told me that too this morning,

BUT:
Did you look thoroughly at this part of the code I suggested ?

  cosx = cos(angle);
  sinx = sin(angle);
  omc = 1.0 - cosx;

  transform->matrix[0][0] = V1[X] * V1[X] * omc + cosx;
  transform->matrix[0][1] = V1[X] * V1[Y] * omc + V1[Z] * sinx;
  transform->matrix[0][2] = V1[X] * V1[Z] * omc - V1[Y] * sinx;

  transform->matrix[1][0] = V1[X] * V1[Y] * omc - V1[Z] * sinx;
  transform->matrix[1][1] = V1[Y] * V1[Y] * omc + cosx;
  transform->matrix[1][2] = V1[Y] * V1[Z] * omc + V1[X] * sinx;

  transform->matrix[2][0] = V1[X] * V1[Z] * omc + V1[Y] * sinx;
  transform->matrix[2][1] = V1[Y] * V1[Z] * omc - V1[X] * sinx;
  transform->matrix[2][2] = V1[Z] * V1[Z] * omc + cosx;

If so, I hope that you noticed that the (1.0 - cosx) expression
here appears in all of the transform lines, while it did not
appear in 3 of those lines originally.

I doubt that all smart C-compilers today can analyse algebraic
expressions and then rearrange them in order to collect items
(that are common between several C-expressions) and place them
outside parenthesis in all the relevant C-expressions.

There are some calculators and computer programs that can do
such manipulation stuff to a whole lot of different types of
symbolic expressions (differentiation, integration, trigonometry
math, matrix math, complex number math etc...)

But does anybody know if such skills have been implemented in
ANY C-compilers yet ?


Tor Olav

Post a reply to this message