Following up to the thread in p.general (Input file size restrictions).

Nicolas,

Success! :-)  the intel c++ compiler for linux is installed on our altix
itanium cluster. I ran the ./configure command exactly as you indicated
(since you da man) with the addition of --prefix for a local install.

I didnt know what cxx options "-03 -ip" meant, but I threw them in there.
During the compile, warnings were issued that -03 is an unknown option to
icpc, and was ignored.

Also, I didnt get the flood of NOP warnings that the g++ build gave me.

I ran 'make install', watching nervously as file after file compiled. And it
built a 64bit version successfully. Kudos to you on the slick scripts! (I
assume you wrote the scripts since you wrote the install doc) Probably the
most hassle-free 3rd party build I've ever done (once I got a working
compiler).

So I ran my 500MB input pov file.  First, it parsed much quicker than the
povlinux version parsed. by about a 3:1 speed up, assuming due to povlinux
running in 32bit emulation layer. Then rendered the image in only 2
seconds. LOL. (of course, I had all costly settings turned off for the test
render).

It appears that the povlinux version was indeed completing the parsing phase
successfully based on the number of tokens reported parsed, but was dying in
the rendering phase.

So now I'm ready to try the 2.5GB input file. woo hoo!!

Thanks again for all your help! Really saved the day.
Phil

Post a reply to this message

> Success! :-)

	Good to know that.  Please follow the instructions of the INSTALL file
about giving architecture infos so that the Compatibility section is updated
accordingly  :-)

> I didnt know what cxx options "-03 -ip" meant, but I threw them in there.
> During the compile, warnings were issued that -03 is an unknown option to
> icpc, and was ignored.

	The "-O3 -ip" options are usually used to tell the icpc compiler
(at least the x86 and x86-64 versions) that it should use a high level of
code optimization (there are more options for that, but those are usually
quite enough for POV-Ray).  I'm surprised though that icpc on IA-64 does
not recognize the quite common -O3 option.  Try -O2 or even -O instead.
It might be that -O2 is the default, but please check the icpc documentation
(or at least command-line help) to be sure.
	Which version of icpc are you using BTW?

> Probably the
> most hassle-free 3rd party build I've ever done (once I got a working
> compiler).

	Thanks!  :-)

> due to povlinux
> running in 32bit emulation layer.

	Yes, that should be the main reason of the large speedup offered
by your native build at this point.  Rendering should also be dramatically
faster (especially if you make sure icpc is using some -O optimization).

	- NC

Post a reply to this message

> During the compile, warnings were issued that -03 is an unknown option to
> icpc, and was ignored.

     Please make sure to use -O3 with an uppercase 'o' character (*not* zero).

     - NC

Post a reply to this message

Nicolas Calimet <pov### [at] freefr> wrote:
> > During the compile, warnings were issued that -03 is an unknown option to
> > icpc, and was ignored.
>
>      Please make sure to use -O3 with an uppercase 'o' character (*not* zero).
>
>      - NC

Ah, there's the problem.  I did indeed use a zero.

I'm using icpc version 9.0.

One other thing I forgot to mention is that your suggested ./configure
command you gave me only specified the c++ compiler, not the c compiler. So
it was still using the gnu c compiler.  I thought about changing that
myself, but figured I'd try it your way first time out, and see if it
works. And of course, it did.

I am on a bit of a time critical project right now. So now that I have a
working executable on this platform, I'm a bit hesitant to rebuild it
(murphy's law, you know).  But once I have a little breathing room, I'll
rebuild using icc and -O3 and see what happens.

I do need to compliment you a bit more on those wonderful scripts. I love
how they check absolutely everything about the development environment,
report the results, and automatically make fixes to anything it needs.
Particularly the libs (png, z, tiff, etc), if they're not the right
version, you provide the right ones automatically and link them in. Just
fantastic. Thats the exact sort of thing that is usually the demise of
other third party builds. And your verbose messages are just so thorough
and intuitive. Just a joy to work with.

Thanks.

Post a reply to this message

> One other thing I forgot to mention is that your suggested ./configure
> command you gave me only specified the c++ compiler, not the c compiler.

	The C compiler is required only when the support libraries need to
build too.  In this case, if you want to build them using icc as well (it's
desirable but not mandatory) you can also pass additional options to the
configure command-line:  CC=icc CFLAGS="-O3 -ip"

> But once I have a little breathing room, I'll
> rebuild using icc and -O3 and see what happens.

	It could make your binary somewhat faster, since the default icc
optimization level seems -O2 (in fact -O but the icc help page says that
-O2 and -O1/-O are equivalent).  Probably not so critical either.

> Just a joy to work with.

	Thanks!  One of the major goal for POV-Ray 3.6 for Unix was exactly
that: make it build out-of-the-box.  I'm glad it does also work on some
architecture/environment I had no chance to test myself.

	- NC

Post a reply to this message

Nicolas Calimet <pov### [at] freefr> wrote:
> > > But once I have a little breathing room, I'll
> > rebuild using icc and -O3 and see what happens.
>
>  It could make your binary somewhat faster, since the default icc
> optimization level seems -O2 (in fact -O but the icc help page says that
> -O2 and -O1/-O are equivalent).  Probably not so critical either.
>
>

I am actually a bit weary of compiler optimizations on graphics code.
They've burned me before. On two separate projects, using ms dev studio
vc++, my work was derailed by optimizations. In both cases, it was rotation
operations. The rotations worked just fine on my machine, so I passed my
code onto QA and/or the customer, only to have them report very
embarrassing bugs of those rotations doing utterly ludicrous things (making
me look like an idiot for turning in code like that). ie, it worked fine on
my graphics card, but was a mess on their graphics card.  So I rebuilt the
code turning off compiler optimizations, and it worked as intended on all
graphics cards.

Things like that annoy me to no end. How could a compiler impart
optimizations without ensuring the coded computation is not undermined?
Yet its hard to blame the compiler when it worked on SOME graphics
hardware, but clearly the optimizations were at least a party to the crime.

But I'm drifting off topic...

Post a reply to this message