[Radiance-general] multiprocessor systems, Radiance, and you

[Peter Apian-Bennewitz]

Hi Rob,
...
> 
> (several paragraphs later he gets to the questions...)  My questions are
> for those of you on the list with MP linux experience.  I guess I'm hazy
> on the way the two processors are utilized.  Do you tend to run one job
> on one CPU and a second one on the other, or do you use rpiece to work
> one job across both, as if the the CPUs are two different hosts?  Or is
> there some OS and/or Radiance compile tweak that you do to simply make
> both CPUs act as one, obviating the need for rpiece? Seems like you
> still need rpiece so the ambient cache is managed properly. As far as
> CPU, do I *have* to use the Athlon MP, or can I run two XPs?  Anyone
> have hardware recommendations?  I like Abit motherboards, but they don't
> seem to offer a dual socket variant.  What about OS?  I had great
> success with RHL 8.0 on an old Dell -- it installed and compiled
> Radiance without a single hiccup.  Anyone using it on a dual box?  Any
> compile changes to either the OS or Radiance?

+ compile changes - most certainly not (Greg relies on the general idea
of copy-on-demand page reuse for standard fork/exec, that seems to work.
I'm not a system guru, maybe threading would be better for whatever
reasons) . There's no general, UNIX internal, way to present two CPUs as
one to a program. Except PVM (parallel virtual machine) or other
libraries (which are operating in user space and not kernel space, if
I'm correctly aligned). LBNL had a project which extended Radiance for
that, - don't know if and when that gets merged back into mainstream
Radiance.

+ Linux distributions - Slackware 8.0 seems ok (gcc version 2.95.3, 
/lib/libc-2.2.3.so), if others experienced problems, I'd suggest adding
output of ("gcc -v" and "ls -la /lib/libc*so", maybe more)

+ MP hardware - dual PIII/1Ghz on Tyan motherboard, no known problems,
(dual PII/400 on ASUS had been fine too, some years ago)

+ rpiece/ambient/rpict - rpiece organizes just the rpicts; sharing
ambient values works with rtraces started by hand too. Running two
rtraces/rpicts on the same octree is memory efficient, as the scenery is
shared (that's what the earlier "copy-on-demand page reuse" yuckspeak
wants to say). If scene memory is not a limiting factor, I wouldn't care
how rendering is organized. Depends on your coding style of shell
scripts, makefiles, m4 etc. 

+ NFS (now, I fear this will haunt me for years) is working between
slackware boxes if nfs-3 is used. However, I do had weird experiences
with lockd/statd on IRIX,HP-UX,Linux over the years, so anyone building
on NFS file locking for commercial work should add a few weeks of
testing before going productive with the machines. (file locking is
crucial to sharing ambient files via NFS)

cheers
Peter

-- 
 pab-opto, Freiburg, Germany, www.pab-opto.de