[Radiance-dev] SPEED or no SPEED

[Greg Ward]

Hi Schorsch,

I agree that the SPEED macro has outlived its usefulness.  I will go  
in and make the appropriate changes to remove it from makeall and the  
source tree, and you can follow by removing it from your SCons  
configuration.

It is possible within rvu to detect the machine speed using a timer  
function or something of the sort, but as you say, it's probably not  
worth the effort.  I'll just fix it at something reasonable and allow  
the user to redefine it if they like.

-Greg

> From: Georg Mischler <schorsch at schorsch.com>
> Date: September 17, 2005 1:22:07 AM PDT
>
> Hi all,
>
> the recent efforts to compile under mingw have directed my attention
> to an issue in Radiance that has bothered me for quite a while.
> The makeall script (and consequently my SCons configuration) defines
> a value of SPEED for every known platform. This is used as follows:
>
> In px/clrtab.c, the closest color routines are activated when SPEED  
> > 8.
> The lowest SPEED setting in makeall is 80, so this test has become
> rather pointless.
>
> In px/neuclrtab.c, DEFSMPFAC is defined as 240/SPEED+3.
> With the current values of SPEED, this ends up somewhere between 1  
> and 3.
> If DEFSMPFAC was already defined before (eg. through a -Dxxx  
> directive),
> then it gets *redefined* to 30. This difference of about an order of
> magnitude makes me thing that this also isn't what was originally
> intended.
>
> In rt/rv3.c, WFLUSH is set depending on SPEED. This is the only case
> where I can still agree with the original intention, even if the
> method fails in similar ways as with the other cases.
>
> By principle, there's no way to determine the performance of the
> target system at compile time. And one of the worst ways to even
> try is by looking at the OS of the compiling system. I'm not sure
> if this ever was a good idea, but it certainly isn't on todays
> hardware/operating systems.
>
> For clrtab.c, the test can be removed without further thought.
>
> For neuclrtab.c, I assume that the original intention was a tradeoff
> between performance and memory use. Since both criteria are not
> really critical anymore, I suggest we find a value of DEFSMPFAC
> that is optimal for the algorithm in most situations and leave
> it at that.
>
> For rv3.c, we could also just set a reasonable fixed value (as the
> Windows version does). If we really want to optimize to the actual
> performance of the machine, then we'll have to test its speed
> at run time. I'm not sure if that's really worth the effort, though.
>
> The goal in any case is to eliminate the compile variable SPEED.
> Any objections or other comments?
>
>
> -schorsch
>