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