(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.


So here's my suggestion:

Replace this:
(27 multiplications and 18 additions/subtractions)


#ifdef AxisRotFixPatch
void Compute_Axis_Rotation_Transform (TRANSFORM *transform, VECTOR
AxisVect, DBL angle)
{
  DBL cosx, sinx;
  VECTOR V1;

  VNormalize(V1, AxisVect);
#else
void Compute_Axis_Rotation_Transform (TRANSFORM *transform, VECTOR V1,
DBL angle)
{
  DBL l, cosx, sinx;

  VLength(l, V1);
  VInverseScaleEq(V1, l);
#endif

  MIdentity(transform->matrix);

  cosx = cos(angle);
  sinx = sin(angle);

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

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

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

  MTranspose(transform->inverse, transform->matrix);
}


With this:
(24 multiplications and 10 additions/subtractions)


#ifdef AxisRotFixPatch
void Compute_Axis_Rotation_Transform (TRANSFORM *transform, VECTOR
AxisVect, DBL angle)
{
  DBL cosx, sinx, omc;
  VECTOR V1;

  VNormalize(V1, AxisVect);
#else
void Compute_Axis_Rotation_Transform (TRANSFORM *transform, VECTOR V1,
DBL angle)
{
  DBL l, cosx, sinx, omc;

  VLength(l, V1);
  VInverseScaleEq(V1, l);
#endif

  MIdentity(transform->matrix);

  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;

  MTranspose(transform->inverse, transform->matrix);
}


This introduces one extra local variable; omc,
but I hope there will be a little speed gain anyway.


Tor Olav

Post a reply to this message

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.

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.


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

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).

Post a reply to this message

> 
> 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

Tor Olav Kristensen wrote:
> 

> >
> > 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.
> 

I did not know about MegaPov sources.

> > 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.

Wrong location and time : 
   trying to speed the parser (location of the optimisation), 
   for an very rarely called function (how many 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 ?

I cannot speak for the TAG or the Pov-Team, 
but if you expect your finding to be incorporated in 3.5, 
I think you will be disappointed.
Most people want now a stable and final 3.5, with sources,
then the everybody-patching process could restart 
and the super/mega/hyper/pov family shows up again.
Then you could make your own version of povray and show us the speed up.
(which may be real for photons, I do not know).

Moreover, I do not have the code of 3.5, do you ?


> 
> 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 there is an entry for you in the FAQ...

> 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.

If you really want to search for optimisation, in 3.1, I have one
to keep you busy: In the pigment evaluation, due to a limited number 
of arguments, one heavy something is done twice (once at top level, 
and another time in a called function). 
Find that, and then solves it cleanly.

> 
> (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.

If you really want to be smarter than the compiler, you might as well
replace the 'transform->matrix' indirection to something more direct.
It will be useless with most modern CPU, it will render the code more
obfuscated.
You may also want to assign V1[...] to some variable, because they are
used a lot and some believe than index of array take time to resolve.
It would be also useless.

I agree nevertheless with you, that care should be taken to correctly
write the code to avoid unnecessary operations, but the most important
thing should be to COMMENT the tricky code at high/medium and low level.
(High level being the pure math thing, : 
        compute a rotation matrix around axis V at the origin...
 Medium level : 
     formula of the matrix is ....
 Low level:
     (1 - cosx) is used everywhere, do it only once.
)


> 
> > 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 ?
> 
Not really, I confess.

>   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.

The original lines where easier for math people, because they were
simply the traditionnal matrix. 
Your lines are more difficult to recognize as a rotation (at least for me).

> 
> 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.

They might do it with a two pass optimiser: first pass count the use of
 sub-expression. second pass assign a register for the most useful
 sub-result, according to the available register in the window.

But they do not have to.
All they usually need is to keep a symbolic map of the register contents,
so that if (1-cosx) is still in a register, they used it directly.
 
It's not really useful on Intel family, due to the lack of generic
registers in x8086 mode, but on most RISC cpu it make the code really flies.
(It's also great on the old M680xx family, which is a CISC cpu).

If the optimiser is allowed to perform out-of-order execution, it can even 
be more surprising. (you may want to try to store V1[X]*omc, V1[Y]*omc and
 V1[Z]*omc , because these three sub-expression are used three time in your
code.

Anyway, rearranging expressions is also the very first step of 
common optimisation, but usually they try only to factor constant expressions.



If povray was not portable across various CPU, you could even go further
with the exact timeframe of CPU operation (with also possible out-of-order
optim)
and hand-code in assembly the PERFECT sequence of operation.

Alas, even in the pentium family, the Perfect sequence of P1 is not the
perfect one for P2/P3 and not even for P4. (And you did not look at AMD...)

Post a reply to this message

>> BUT:
>> Did you look thoroughly at this part of the code I suggested ?
>>
>Not really, I confess.

[code removed]

>> 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.
>
>The original lines where easier for math people, because they were
>simply the traditionnal matrix.
>Your lines are more difficult to recognize as a rotation (at least for me).

Does this matter?  His code will run faster.

>They might do it with a two pass optimiser: first pass count the use of
> sub-expression. second pass assign a register for the most useful
> sub-result, according to the available register in the window.
>
>But they do not have to.
>All they usually need is to keep a symbolic map of the register contents,
>so that if (1-cosx) is still in a register, they used it directly.


Did you look at what Tor did?  No compiler in the world will make that
particular optimization, because it involves symbolic algebra.  In the
original code, the expression (1.0 - cosx) appears *six* times.  An
optimizing compiler will notice this and evaluate it only once, storing the
result in either a CPU register or memory, whichever is appropriate.  What
Tor did was notice that with a certain algebraic manipulation, the
expressions such as V1[X] * V1[X] + cosx * (1.0 - V1[X] * V1[X])could be
converted into expressions like V1[X] * V1[X] * (1.0 + cosx) + cosx,
allowing the *nine* occurrences of (1.0 - cosx) to be recognized as a common
subexpression which need only be evaluated once.

--
Mark

Post a reply to this message

Mark Wagner wrote:
> 
> Does this matter?  His code will run faster.

Unproven assertition (yet).

> 
> >They might do it with a two pass optimiser: first pass count the use of
> > sub-expression. second pass assign a register for the most useful
> > sub-result, according to the available register in the window.
> >
> >But they do not have to.
> >All they usually need is to keep a symbolic map of the register contents,
> >so that if (1-cosx) is still in a register, they used it directly.
> 
> Did you look at what Tor did? 

[This discussion is turning ad hominem, so I will not enter more into it]

> No compiler in the world will make that
> particular optimization, because it involves symbolic algebra. 

May be I'm too optimistic about optimisers, or you're too pessimistic.

Only solution to settle this patch down:
 1. Get the pov source.
 2. Make your own compilation to obtain povray-1.
 3. Patch as suggested
 4. Make another clean compilation to obtain povray-2.
 5. Testing time (either, or both, as you like):
   5.1 : make povray-1 and povray-2 render all the pov-scenes that comes 
         with the source.
         Keep the time log. 
         Any difference of less that the precision is irrelevant.
         (precision is usually 1 second).
   5.2 : create a specific scenes on purpose of triggering the patch. 
         Render with both.
         Compare the time needed.
 6. Report the result worldwide.

For both compilation, exactly the same compiler and the same options must be
used.

As the current code of pov is assumed to be innocent, 
the charge of the proof fall to the evolution-requestor.

Post a reply to this message

>...
> The original lines where easier for math people, because they were
> simply the traditionnal matrix.
> Your lines are more difficult to recognize as a rotation (at least for me).
>...

Ok, then I'll try to explain how to see that my lines
represent such a rotation...

Please see my post to povray.advanced-users 30. Nov;
"Rotation around an arbitrary axis":
news://news.povray.org/3C06D0B8.9DE747A0%40hotmail.com
http://news.povray.org/povray.advanced-users/20370/

- and my explanation below.


Tor Olav


Here's is a matrix expression that shows how one can
build a general rotation matrix R, that will represent
a rotation around a given unit vector v = <a, b, c>
in a left handed coordinate system:

R = -Sin*S + (1 - Cos)*S*S + I

(Sin means sin(Angle) and Cos means cos(Angle).)

S is this skew symmetric matrix:

     0 -c  b
S =  c  0 -a
    -b  a  0

(I have seen this written like this S = skew(v))

And I is an identity matrix:

     1  0  0
I =  0  1  0
     0  0  1

Rewriting the first expression:

                  0  -c   b    -Sin*0  Sin*c -Sin*b
-Sin*S = -Sin  *  c   0  -a  = -Sin*c -Sin*0  Sin*a
                 -b   a   0     Sin*b -Sin*a -Sin*0

     0    c*Sin -b*Sin
= -c*Sin    0    a*Sin
   b*Sin -a*Sin    0  


Then we'll work with the rest of the expression.

Multiplying matrix S by itself:

       0 -c  b     0 -c  b     0*0-c*c-b*b -0*c+c*0+b*a -0*b+c*a-b*0
S*S =  c  0 -a  *  c  0 -a  = -c*0-0*c+a*b -c*c+0*0-a*a  c*b+0*a+a*0
      -b  a  0    -b  a  0     b*0+a*c+0*b  b*c-a*0-0*a -b*b-a*a+0*0

  -(b^2+c^2)     b*a         c*a   
=     a*b    -(a^2+c^2)      c*b   
      a*c        b*c     -(a^2+b^2)


Since v is a vector with unit length:

sqrt(a^2 + b^2 + c^2) = 1

or simply:

a^2 + b^2 + c^2 = 1

Here's three ways to rearrange that:

-(b^2 + c^2) = a^2 - 1
-(a^2 + c^2) = b^2 - 1
-(a^2 + b^2) = c^2 - 1


Substitution:

       a*a-1   b*a    c*a      a*a  b*a  c*a     1  0  0
S*S =  a*b     b*b-1  c*b   =  a*b  b*b  c*b  -  0  1  0
       a*c     b*c    c*c-1    a*c  b*c  c*c     0  0  1


Scaling with (1 - Cos):
                
(1-Cos)*S*S

            a*a  b*a  c*a               1  0  0
= (1-Cos) * a*b  b*b  c*b  -  (1-Cos) * 0  1  0
            a*c  b*c  c*c               0  0  1

            a*a  b*a  c*a     Cos  0   0     1  0  0
= (1-Cos) * a*b  b*b  c*b  +   0  Cos  0  -  0  1  0
            a*c  b*c  c*c      0   0  Cos    0  0  1


Adding an identity matrix:

(1-Cos)*S*S + I

            a*a  b*a  c*a     Cos  0   0 
= (1-Cos) * a*b  b*b  c*b  +   0  Cos  0 
            a*c  b*c  c*c      0   0  Cos 


Now we can tell that:

R = -Sin*S + (1-Cos)*S*S + I

     0    c*Sin -b*Sin               a*a  b*a  c*a     Cos  0   0 
= -c*Sin    0    a*Sin  +  (1-Cos) * a*b  b*b  c*b  +   0  Cos  0 
   b*Sin -a*Sin    0                 a*c  b*c  c*c      0   0  Cos 

    Cos   c*Sin -b*Sin               a*a  b*a  c*a
= -c*Sin   Cos   a*Sin  +  (1-Cos) * a*b  b*b  c*b
   b*Sin -a*Sin   Cos                a*c  b*c  c*c

    Cos   c*Sin -b*Sin     a*a*(1-Cos)  b*a*(1-Cos)  c*a*(1-Cos)
= -c*Sin   Cos   a*Sin  +  a*b*(1-Cos)  b*b*(1-Cos)  c*b*(1-Cos)
   b*Sin -a*Sin   Cos      a*c*(1-Cos)  b*c*(1-Cos)  c*c*(1-Cos)


Finally we'll do another matrix addition to get one single matrix:

     a*a*(1-Cos)+Cos    b*a*(1-Cos)+c*Sin  c*a*(1-Cos)-b*Sin
R =  a*b*(1-Cos)-c*Sin  b*b*(1-Cos)+Cos    c*b*(1-Cos)+a*Sin
     a*c*(1-Cos)+b*Sin  b*c*(1-Cos)-a*Sin  c*c*(1-Cos)+Cos  

And from this we see that:

R[0][0] = a*a*(1 - Cos) + Cos
R[0][1] = b*a*(1 - Cos) + c*Sin
R[0][2] = c*a*(1 - Cos) - b*Sin

R[1][0] = a*b*(1 - Cos) - c*Sin
R[1][1] = b*b*(1 - Cos) + Cos
R[1][2] = c*b*(1  -Cos) + a*Sin

R[2][0] = a*c*(1 - Cos) + b*Sin
R[2][1] = b*c*(1 - Cos) - a*Sin
R[2][2] = c*c*(1 - Cos) + Cos


Now if:

v = V1 (a = V1[X], b = V1[Y], c = V1[Z])
cosx = Cos
sinx = Sin
omc = 1-Cos

Then it's easy to see that:

transform->matrix = R

> >   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;

Post a reply to this message

>...
> Tor Olav Kristensen wrote:
> >...

> > >...
> > > 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.
> 
> Wrong location and time :
>    trying to speed the parser (location of the optimisation),
>    for an very rarely called function (how many 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 ?
> 
> I cannot speak for the TAG or the Pov-Team,
> but if you expect your finding to be incorporated in 3.5,
> I think you will be disappointed.
> Most people want now a stable and final 3.5, with sources,
> then the everybody-patching process could restart
> and the super/mega/hyper/pov family shows up again.
> Then you could make your own version of povray and show us the speed up.
> (which may be real for photons, I do not know).

I thought that you meant that the time I posted my
suggestion (late november 2001) was a bad time
because the POV-team had more important things to
do now.

And: I did not expect anything.

- I just made a little suggestion.



>...
> Moreover, I do not have the code of 3.5, do you ?

No, unfortunately not   =(



>...
> Tor Olav Kristensen wrote:
> >...
> > 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 there is an entry for you in the FAQ...

I had a look, but I'm not sure which you mean.
Please show me.



>...
> Tor Olav Kristensen wrote:
> >...
> > 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.
> 
> If you really want to search for optimisation, in 3.1, I have one
> to keep you busy: In the pigment evaluation, due to a limited number
> of arguments, one heavy something is done twice (once at top level,
> and another time in a called function).
> Find that, and then solves it cleanly.

Since I'm new to POV's source code I think that
I'll stick to what interests me most within it;
the linear algebra.



>...
> Tor Olav Kristensen wrote:
> >...
> > 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.
> 
> They might do it with a two pass optimiser: first pass count the use of
>  sub-expression. second pass assign a register for the most useful
>  sub-result, according to the available register in the window.
> 
> But they do not have to.
> All they usually need is to keep a symbolic map of the register contents,
> so that if (1-cosx) is still in a register, they used it directly.

Then please show me step by step how they will make
use of a pre-calculated value for (1 - cosx) while
parsing these expressions:

V1[X] * V1[X] + cosx * (1.0 - V1[X] * V1[X])

V1[Y] * V1[Y] + cosx * (1.0 - V1[Y] * V1[Y])

V1[Z] * V1[Z] + cosx * (1.0 - V1[Z] * V1[Z])



Tor Olav

Post a reply to this message