SPEED or no SPEED

radiance-dev
1

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

···

--
Georg Mischler -- simulations developer -- schorsch at schorsch com
+schorsch.com+ -- lighting design tools -- http://www.schorsch.com/

2

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 <[email protected]>
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

3

Greg Ward wrote:

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.

Thanks, removed all traces of SPEED from the SCons system (yeah,
I'm sure someone will make a pun out of this... ;)).

I found that it was still mentioned in doc/notes/compile_switches,
and removed the description there. Doing so, I saw some more
outdated flags listed:

-DALIGN is not used anymore in the current sources.

-DBSD lost most of its former purpose, although it seems we can't
remove it completely yet.

I hope my shortened description of the latter is at least half correct.

-schorsch

···

--
Georg Mischler -- simulations developer -- schorsch at schorsch com
+schorsch.com+ -- lighting design tools -- http://www.schorsch.com/

4

Hi Schorsch,

Your description of -DBSD is fine. I forgot about compile_switches. I just noticed (and fixed) the fact that -DALIGN= was changed to -DALIGNT=. If there's some way to get rid of -DBSD, that would be great. We seem to need it for the resource stuff at the moment.

-Greg

5

I think it changes he behavior of some library routines on some systems that support both BSD-like and POSIX-like code, but I'm not entirely sure of that. On Mac OS X it is actually defined in <sys/param.h>--anyone know about other implementations?

Randolph, still hiding out

···

On Sep 19, 2005, at 8:27 AM, Greg Ward wrote:

Your description of -DBSD is fine. I forgot about compile_switches. I just noticed (and fixed) the fact that -DALIGN= was changed to -DALIGNT=. If there's some way to get rid of -DBSD, that would be great. We seem to need it for the resource stuff at the moment.

6

Randolph Fritz wrote:

Greg Ward wrote:

> Your description of -DBSD is fine. I forgot about
> compile_switches. I just noticed (and fixed) the fact that -
> DALIGN= was changed to -DALIGNT=. If there's some way to get rid
> of -DBSD, that would be great. We seem to need it for the resource
> stuff at the moment.

I think it changes he behavior of some library routines on some
systems that support both BSD-like and POSIX-like code, but I'm not
entirely sure of that. On Mac OS X it is actually defined in <sys/
param.h>--anyone know about other implementations?

FreeBSD has it defined in the same place as follows:

#define BSD 199506 /* System version (year & month). */

It doesn't influence anything else as it seems (and I don't
think it really should, either).

The question is rather how we get rid of those instances
in our own code where it makes Radiance behave differently.

There seem to be three problem areas:

In rpict.c, it includes resource.h, which is necessary
for getrusage(). I can't do a comprehensive check, but on
those BSDish systems I have access to, the SYSV times()
call is also available, so we could probably switch to that
on all posix platforms. We still need a seperate report()
function for Windows, of course.

In random.h, BSD uses random() instead of lrand48()/drand48().
The latter also seem to be available everywhere nowadays,
so we could switch this one too.

The last issue is the different behaviour when IO calls are
interrupted. This is handled by readbuf()/writebuf() in
process.c, which gets called from various places. I have no
idea whether this problem still exists (probably) or if there
are other ways to work around it.

-schorsch

···

--
Georg Mischler -- simulations developer -- schorsch at schorsch com
+schorsch.com+ -- lighting design tools -- http://www.schorsch.com/