Compiling Radiance with the Intel (Vectorizing) C Compiler

I think the answer is "no." The Radiance code doesn't work with that compiler, even with optimization turned off. I would like to chase those bugs down, but I don't think I have time right now.

Sigh. Back to the (slower) gcc.

Meantime, here's a few more buglets the icc found:

- In ccyrgb.c, rgb2ccy has two return statements, and only one of them returns a value.

- In tmapcolrs.c, tmMapPicture, returnErr will reference the unset tms pointer if the arguments are bad. I believe this can be fixed by initializing tms to NULL.

- In tmaptiff.c, tmMapTIFF, same problem.

···

On 2011-06-27 14:18:01 -0700, Randolph M. Fritz said:

I've got it to compile...but rpict crashes. Anyone tried this before?
Did you get it to work?

--
Randolph M. Fritz • RFritz@lbl.gov
Environmental Energy Technologies Division • Lawrence Berkeley Labs

shouldn't "gcc -O3 -g -Wall " spot all three ?

I have no idea.

My enquiries into locating industrial funds to look into this had been
stopped then, mostly by Greg stating that setting up vectors takes
longer then gaining cycles. I don't have enough insight into the way
Radiance spends its time and the mystics of automatic vectorizing
compilers to be definitive there. Industry sources stated that anything
below a considerable speed-up-factor (say 2 at least) isn't worth
looking into.

Well...if it can shave 10% off long simulation runs I'd call that good.

IMHO, apart from speed-ups, it'll be sound if Radiance compiled on
different compilers and run.

It would. MSVC too.

Also, looking at rtrace running on eight-core systems, I am seeing CPU times of about five times wall-clock time. I would have hoped for something closer to 8 times wall-clock. I suspect that NFS file locking has become a performance problem.

···

On 2011-06-28 11:05:07 -0700, Peter Apian-Bennewitz said:

--
Randolph M. Fritz • RFritz@lbl.gov
Environmental Energy Technologies Division • Lawrence Berkeley Labs