POV-Ray

Segfaults also seen on Debian Linux 5.0.3 "Etch" using Intel icpc 11.1 compiler, with same frequency.

As I haven't yet observed any such segfaults with GNU g++ versions of POV-Ray on the same machine, I currently suspect issues introduced by automatic code optimization.

Segfaults also seen on OpenSUSE 11.2 (x86_64), again using Intel icpc 11.1

Trying –benchmark with icpc (static) povray. (povray #5480, icpc 12.0.5 20110719, ubuntu 11.04, boost 1.47)

Found a difference in objects:

----------------------------------------------------------------------------
Parser Statistics
----------------------------------------------------------------------------
Finite Objects:          175
Infinite Objects:          3
Light Sources:             2
Total:                   180

whereas gcc povray

----------------------------------------------------------------------------
Parser Statistics
----------------------------------------------------------------------------
Finite Objects:          177
Infinite Objects:          1
Light Sources:             2
Total:                   180

As benchmark use photons, I fails to segfault (ran 4 times –benchmark, no segfault)

The ratio of bounding goes from 51.64 (gcc) to 30.25 (icpc)

Configuration of povray:
./configure COMPILED_BY="..." –disable-io-restrictions –with-boost-libdir=/opt/intel/lib –with-boost-thread=boost_thread –with-boost=/opt/intel CC="icc" CXX="icpc" –enable-static –disable-debug –enable-optimize

and LD_LIBRARY_PATH extended with /opt/intel/lib (where are libboost*.*)

AFAIK there are changes / bug fixes in photon code in RC4. Has this problem been resolved?

@Jerome: Such a difference in number of objects shouldn't happen; are you sure you used the same source code?

AFAIK there are changes / bug fixes in photon code in RC4. Has this problem been resolved?

@Christoph: my last generation with icpc was done with the following configure (on a tree-copy of the smp sources, as extracted for my gnu-compile of smp, at #5480, with just a 3 changes (local/declare) in benchmark.cpp to be able to run it.)

(it is now dynamic link, allowing usage of SDL to view the render in progress)

(quotes added back from config.log)
$ ./configure COMPILED_BY="Jérôme Grimbert jgrimbert@free.fr" –disable-io-restrictions –with-boost-libdir=/opt/intel/lib –with-boost-thread=boost_thread –with-boost=/opt/intel CC=icc CXX=icpc –disable-debug

The total count of objects is the same, it's only the finite/infinite which are different. (but I do not know (yet ?) which ones)

I want to amend my object count: both smp (gnu & icpc) are reporting 175+3 ; only my experimental branch is reporting 177+1, so the problem is mine, all mine.
Do not waste time on that count. Sorry.

(Now, if you can provide a scene which fails with photons, so that I can try it also with icpc, that would be great)

Please try the following sample scenes:

advanced/balcony
advanced/diffuse_back.pov
advanced/optics.pov

Ran optics 4 times, diffuse 1, balcony twice... no problem.
My system : i7, 6 cores with hyperthreading (+WT12), 64 bits, linux ubuntu 11.04
icpc 12.0.5

$ file /usr/local/bin/povrayicpc
/usr/local/bin/povrayicpc: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.15, stripped

Render Options

Quality:  9
Bounding boxes.......On   Bounding threshold: 3
Antialiasing.........On  (Method 1, Threshold 0.030, Depth 3, Jitter 1.00,

Gamma 2.50)

In ~/.povray/3.7/povray.ini
Verbose=Off
Display=On
Bounding_Threshold=3

Optics has a parse warning:
File 'optics.pov' line 32: Parse Warning: Camera location to look_at direction
and sky direction should be different. Using default/supplied right vector
instead.

@ Christoph : can you state the difference between your and my settings ?

My system: AMD Phenom X4, 4 cores, no HT (implicit +WT4), 64 bit, varying Linux distros (Debian 4.0r5 and 5.0.3, OpenSUSE 11.2
varying icpc versions (11.0, 11.1, 12.0.3)

povray: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.4, stripped

You're using icpc on a AMD ? Can't it be some differents implementation of op-codes (time & schedule) that become problematic ?
(well, how could we know ?)
Or some issue with the SSE level ?

Looking at icc flags: http://www.gentoo-wiki.info/HOWTO_ICC_and_Portage Did you try to also get some generic code (-axX (X:=(K,W,P,T,S) ) ?

It seems that: icc generates code that detects the brand of processor on which it is executing. On Intel CPUs, the binary will execute with SSE instructions, whereas it will execute 386 level instructions on AMD CPUs regardless of availability of SSE instruction sets.

If that's true, is there any interest to run icpc compiled povray on AMD ?

I suspect the information on that gentoo page might be outdated; at any rate I found the ICPC-compiled binaries to render a bit faster on average than the GCC-compiled ones, even on the Phenom X4 machine.

Yes, that information is outdated. IIRC it has been subject to legal action by AMD against Intel several years ago, and ICC optimizes for AMD just as well nowadays.

Ah, yes, Intel settled this in 2009: http://download.intel.com/pressroom/legal/AMD_settlement_agreement.pdf

Is this still an issue?

Haven't tested lately, so I suspect it's still there. But as apparently I'm still the only one seeing this issue, I'd be ok with demoting the severity and priority.

Now tracked on github as issue #127.