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 • [email protected]
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 • [email protected]
Environmental Energy Technologies Division • Lawrence Berkeley Labs