 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Nicolas Calimet <pov### [at] free fr> wrote:
> https://premier.intel.com
For some reason (after registering) that gives me just a 404.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Nicolas Calimet <pov### [at] freefr> wrote:
> ./configure COMPILED_BY=you --disable-optimiz CXX=icpc CXXFLAGS="-O3 -ip"
I have been for long time wanting to try to compile povray with icc,
and this post inspired me to download it and try.
The registration (for downloading the compiler and getting the
registration code) and installation process went just fine, except for
the registration to the support forum, which failed for some unexplained
reason. (It might be that since I had already registered there with my
email address, trying to register again with the same address failed,
but the installer didn't tell the reason why it failed.)
Well, the installer jumped back to the main menu (which now told me
that it had detected icc 9.0 as being installed) so I exited.
No binary (icc, icpc or anything). I quickly discovered that the
installer had installed everything ok into /opt/intel, but it had
both failed to give read and execution rights to those directories
and it had not created any links to the actual binaries into a
directory in my path (eg. /usr/bin). This seemed odd and a strong
symptom of something having gone wrong and the installation process
having not completed completely.
Anyways, not knowing what else to do, I set the reading and executing
rights to the proper directories there and created a link to icc
(into /usr/local/bin) as well as added the lib directory to my
LD_LIBRARY_PATH (something which I quickly realized was necessary in
order to run any programs compiled with icc, and another sympton of
the installation having not completed completely successfully).
A simple hello world program as well as a simple gtk example program
compiled and ran just fine now.
However, when I tried to compile povray after configuring it as
suggested, the compilation itself went fine, but linking the final
binary was unsuccessful. icc gave several dozens of pages of "undefined
reference to" errors. The huge list starts like this:
unix.o(.gcc_except_table+0x457): undefined reference to `typeinfo for char const*'
unix.o(.gcc_except_table+0x45b): undefined reference to `typeinfo for int'
unix.o(.gcc_except_table+0xe63): undefined reference to `typeinfo for int'
unix.o(.text+0x3d0): In function `main':
unix.cpp: undefined reference to `operator new[](unsigned int)'
unix.o(.text+0x4bd):unix.cpp: undefined reference to `__cxa_begin_catch'
unix.o(.text+0x4e4):unix.cpp: undefined reference to `__cxa_end_catch'
unix.o(.text+0x528):unix.cpp: undefined reference to `__cxa_end_catch'
...
Rather unusually, I'm rather puzzled and have no idea what to do
about it. I can't even begin to imagine what could be causing this,
except that it's most probably caused by the (for some reason) incomplete
installation procedure, somehow.
Given that my previous small tests compiled and ran just fine, I just
have no idea what could be causing this.
Curiously, I am having problems with Intel's online support system
as well. I can log in to their system (and it correctly says "logged
in as <my email>"), but when I try to click on the "Intel Premier Support"
link, it jumps to a page which says "You are attempting to access Intel
Premier Support but you do not have a user account."
Why am I experiencing all these problems I have never heard anyone else
having?
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp <war### [at] tagpovrayorg> wrote:
> icc gave several dozens of pages of "undefined
> reference to" errors.
Didn't realize that the binary has to be linked with icpc instead of icc.
That's the problem with the general ".o" extension. The compiler can't
know that it's actually a C++ object file, not a C one.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
