Ok, a test render of abyss.pov (with -w800 -h300 +a +am2 -f -p -x +d) took
5 minutes 7 seconds using a gcc-compiled binary of povray (using the options
-O3 -march=pentium4 -ffast-math -mfpmath=sse -msse2 -funroll-loops
-ftsp-ordering, which are the best I have found), while the same render
using the icpc-compiled binary (using just -O3 -ip) took 5 minutes 14 seconds.

  Any ideas what other icpc optimization parameters could be used?

-- 
                                                          - Warp

Post a reply to this message

>   Didn't realize that the binary has to be linked with icpc instead of icc.

	I don't get it.  If you have CXX=icpc specified at the configure
command-line, then the linker should also be invoqued with icpc automatically.
Otherwise something is odd.

	- NC

Post a reply to this message

> -ftsp-ordering

	This option or anything similar doesn't seem to exist in any gcc version
I've tried (up to 4.1.0).  How come?

>   Any ideas what other icpc optimization parameters could be used?

	You might also try those:

-xP or -xN
-no-prec-div (icc 9.0 and above, might slow down abyss.pov though)

	If you find another set of interesting compiler flags on the p4, please
share it  :-)

	- NC

Post a reply to this message

Nicolas Calimet <pov### [at] freefr> wrote:
> > -ftsp-ordering

>         This option or anything similar doesn't seem to exist in any gcc version
> I've tried (up to 4.1.0).  How come?

  That's odd. I'm using gcc 3.3.5. From the info page:

`-ftsp-ordering'
     In addition to heuristic used at `-freorder-blocks', use also a
     more powerful method based on the reduction to the Travelling
     Salesman Problem to determine the good order of basic blocks in
     the function.  This generally produces smaller and faster
     programs, at the expense of longer compile times.

  It doesn't have a *big* effect, but it consistently made abyss.pov render
about 1 second faster than without it (307 vs 308 seconds), so I left it in.
Leaving it out isn't much of a loss.

-- 
                                                          - Warp

Post a reply to this message

Nicolas Calimet <pov### [at] freefr> wrote:
>         If you have CXX=icpc

  But I didn't. I had CXX=icc. I didn't realize the difference between
the two (iow that icc is equivalent to gcc and icpc is equivalent to g++).

-- 
                                                          - Warp

Post a reply to this message

>   That's odd. I'm using gcc 3.3.5. From the info page:

	Ok, this option simply disappeared in the 3.4 and 4.x branches.
	That means: not useful any longer.

>   It doesn't have a *big* effect, but it consistently made abyss.pov render
> about 1 second faster than without it (307 vs 308 seconds), so I left it in.

	Not significant IMHO.

	- NC

Post a reply to this message

>   But I didn't. I had CXX=icc.

	*Bang*  :-)

I didn't realize the difference between
> the two (iow that icc is equivalent to gcc and icpc is equivalent to g++).

	IIRC the distinction appeared in icc-8.1, and it was probably
necessary due to the kind of problem you encountered.

	- NC

Post a reply to this message

Nicolas Calimet <pov### [at] freefr> wrote:
>         IIRC the distinction appeared in icc-8.1, and it was probably
> necessary due to the kind of problem you encountered.

  The only problem is that ".o" files are ambiguous. The extension doesn't
indicate what kind of object file it is.

  gcc and icc have no problems whatsoever in compiling C++ source files
as long as they are named appropriately (ie. eg. ".cc" or ".cpp" or
whatever). However, when they are used as a linker they have no way of
knowing that they should be linking in C++ mode instead of C mode.

  You *can* actually use gcc (and probably icc) to link C++ binaries.
You just have to provide the proper -l options. g++ (and thus icpc) simply
uses these options by default. Otherwise there's probably little difference
between the two.

-- 
                                                          - Warp

Post a reply to this message

Warp wrote:
>   gcc and icc have no problems whatsoever in compiling C++ source files
> as long as they are named appropriately (ie. eg. ".cc" or ".cpp" or
> whatever). However, when they are used as a linker they have no way of
> knowing that they should be linking in C++ mode instead of C mode.

Actually, they do: The name mangling should be different, with C using 
basically unmangled names, while for C++ the ABI is rather specific. After 
all, that is why there is 'extern "C" ' in C++ ...

As such, unless something is very wrong, a linker can easily auto-detect 
what it is dealing with. The C++ files will have mangled names according to 
the ABI specification, assuming they do actually declare any C++ 'stuff'.

	Thorsten

Post a reply to this message

Thorsten Froehlich <tho### [at] trfde> wrote:
> As such, unless something is very wrong, a linker can easily auto-detect 
> what it is dealing with. The C++ files will have mangled names according to 
> the ABI specification, assuming they do actually declare any C++ 'stuff'.

  If nothing else, the linker (well, gcc) could have a logic like
"hey, this is an undefined reference to something, but I know what it is,
it's a C++ function (or whatever); I'll try it again with C++ linking
options to see if it links".

-- 
                                                          - Warp

Post a reply to this message