POV-Ray : Newsgroups : povray.binaries.programming : matrices.c : Re: matrices.c Server Time
19 Apr 2024 07:15:15 EDT (-0400)
  Re: matrices.c  
From: Jérôme Grimbert
Date: 29 Nov 2001 04:43:32
Message: <3C060348.E711BB85@atosorigin.com>
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

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.