|
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |