I suspect the binary distribution of povray (linux) is compiled without
optimizations. (correct?)

My question is if I rebuild and compile with optimizations from source, will
that give me a noticeable performance speedup? Has anybody noticed
significant speedup this way?

I've had problems using optimizations on OpenGL code and others as it can
produce unexpected results with transformations (primarily rotations) on
different graphics hardware. Could that be a problem here too?

Any input is apprectiated.

Thanks in advance.

Post a reply to this message

space_cadet wrote:

> I suspect the binary distribution of povray (linux) is compiled without
> optimizations. (correct?)

I think it IS compiled with optimizations - it is highly unlikely not to be.
Why don't you ask in the povray.unix forum? Nicolas Calimet (I think)
should be able to give you a detailed answer.
 
> My question is if I rebuild and compile with optimizations from source,
> will that give me a noticeable performance speedup? Has anybody noticed
> significant speedup this way?

I've tried compiling on the IA32 architecture with a 2.6.14.3 kernel with
GCC 3.4 with the following compiler flags:

-O3 -fomit-frame-pointer -ffast-math -fexpensive-optimizations -fstrict-aliasing 
-funroll-loops -funroll-all-loops -fforce-addr -finline-functions -frerun-loop-opt 
-falign-loops=4 -falign-jumps=4 -falign-functions=4 -march=i686 -mmmx -msse2

(which may or may not be stupid flags, I just threw a few things in
experimentally to see what happens.)

On a 3GHz P4 HT system with a Gigabyte GA8-TRS350MT motherboard with 1GB of
RAM I could not find any human-perceptible increase in rendering speed over
a stock binary or a self-compiled binary, using GCC. No, I did not time a
run computationally myself, I checked subjectively by checking the timings
at the end of the run on a non-standard scene I designed myself, and
rendered with both binaries. I suspect this is because the raytracing
bottleneck is mostly floating point performance, or how many MFLOPS /
GFLOPS your system can squeeze out.
 
I've heard that is IS possible to get some (not much, apparently)
improvement by using Intel's C compiler instead of GCC. There was a thread
about a year ago about this in the Unix forum, if I remember correctly.

> I've had problems using optimizations on OpenGL code and others as it can
> produce unexpected results with transformations (primarily rotations) on
> different graphics hardware. Could that be a problem here too?

Not as far as I know. Povray doesn't use any accelerated graphics hardware.
It lives in the FPU. Mostly optimisations using GCC should not (mostly)
affected floating point operations. You can just as happily run POV on a
system with an ISA CGA card or on a system with SLIed Nvidia 8800 GTX PCI
Express accelerated cards with 1GB of video RAM each, you'll see no
difference in rendering speed...
 
-- 
Stefan

Post a reply to this message

Stefan Viljoen wrote:

> Not as far as I know. Povray doesn't use any accelerated graphics
> hardware. It lives in the FPU. Mostly optimisations using GCC should not
> (mostly) affected floating point operations. You can just as happily run
> POV on a system with an ISA CGA card or on a system with SLIed Nvidia 8800
> GTX PCI Express accelerated cards with 1GB of video RAM each, you'll see
> no difference in rendering speed...

... but you can of course split the scene and distribute them to a cluster,
if you have one available. (PVMPov)

This can give incredible improvements in overall rendering speed.

See

http://local.wasp.uwa.edu.au/~pbourke/modelling_rendering/renderexamples/  

for a scene I designed that took WEEKS to render three or four lines, but
was rendered by Paul Bourke in a few hours on a DEC Alpha cluster.

-- 
Stefan

Post a reply to this message

space_cadet <poc### [at] grcnasagov> wrote:
> I suspect the binary distribution of povray (linux) is compiled without
> optimizations.

  Why do you suspect that?

-- 
                                                          - Warp

Post a reply to this message

Warp <war### [at] tagpovrayorg> wrote:
> space_cadet <poc### [at] grcnasagov> wrote:
> > I suspect the binary distribution of povray (linux) is compiled without
> > optimizations.
>
>   Why do you suspect that?
>
> --
>                                                           - Warp

Per the advice of a colleague, who has far more experience than I in such
things, believes that distributed binaries are usually compiled without
optimizations in order to make them compatible with the broadest range of
processors possible, since optimizations tend to be processor specific.

Thanks for all responses, guys. appreciated.

Post a reply to this message

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

space_cadet wrote:
> Warp <war### [at] tagpovrayorg> wrote:
>> space_cadet <poc### [at] grcnasagov> wrote:
>>> I suspect the binary distribution of povray (linux) is compiled without
>>> optimizations.
>>   Why do you suspect that?
> 
> Per the advice of a colleague, who has far more experience than I in such
> things, believes that distributed binaries are usually compiled without
> optimizations in order to make them compatible with the broadest range of
> processors possible, since optimizations tend to be processor specific.
> 
	This is both right and wrong: some optimizations are processor
specific and those are not used in distributed binaries. But there
are a lot of generic optimizations that can be applied no matter
what your target is (i.e they are valid for power pc as well as x86
or any other) and other optimizations that are valid for all CPUs in
any family (eg for all x8 CPUs). Those optimizations are usually
active in all distributed binaries. AFAIK the official PC povray
binaries are compiled with all optimizations for the i686 (PentiumII
and above) so you may gain a little if you recompile with  the
optimizations specific to your precise CPU, but probably not much...

		Jerome
- --
+------------------------- Jerome M. BERGER ---------------------+
|    mailto:jeb### [at] freefr      | ICQ:    238062172            |
|    http://jeberger.free.fr/     | Jabber: jeb### [at] jabberfr   |
+---------------------------------+------------------------------+
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)

iD8DBQFFk/eHd0kWM4JG3k8RArBMAJ0SYKq3sOYwgmypQHJOLiP+5VQ0GgCcCGiG
Kxc0vdBLQdEzvx5hQgub358=
=VXup
-----END PGP SIGNATURE-----

Post a reply to this message

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


> space_cadet wrote:
> 	This is both right and wrong: some optimizations are processor
> specific and those are not used in distributed binaries. But there
> are a lot of generic optimizations that can be applied no matter
> what your target is (i.e they are valid for power pc as well as x86
> or any other) and other optimizations that are valid for all CPUs in
> any family (eg for all x8 CPUs).
	This should of course read "all x86 CPUs"...

> Those optimizations are usually
> active in all distributed binaries. AFAIK the official PC povray
> binaries are compiled with all optimizations for the i686 (PentiumII
> and above) so you may gain a little if you recompile with  the
> optimizations specific to your precise CPU, but probably not much...
> 
		Jerome
- --
+------------------------- Jerome M. BERGER ---------------------+
|    mailto:jeb### [at] freefr      | ICQ:    238062172            |
|    http://jeberger.free.fr/     | Jabber: jeb### [at] jabberfr   |
+---------------------------------+------------------------------+
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)

iD8DBQFFk/jCd0kWM4JG3k8RAjSFAJ0d4Hs+netxTw4UKFgJdY0ygZHz7wCePxVQ
/GX9b+IS6VDDHdLovaEumsw=
=a7rB
-----END PGP SIGNATURE-----

Post a reply to this message

> 	This is both right and wrong: some optimizations are processor
> specific and those are not used in distributed binaries.

It is possible to make a further distinction among processor-specific
optimizations:

- some use features that are specific to a certain processor, or available
  only above a given release, and will result in binaries that do not work
  on other processors;

- some use only generic features, but tune the code according to the
  strengths and weaknesses of a given processor, and will result in binaries
  that run on others processors, only slower than a binary with generic
  optimizations.

For example, optimizing for Pentium 4 may mean using SSE2, causing
incompatibility with earlier processors, but it may also mean tuning for the
long pipeline, causing just slowness.

Post a reply to this message

Nicolas George <nicolas$george@salle-s.org> wrote:
> - some use only generic features, but tune the code according to the
>   strengths and weaknesses of a given processor, and will result in binaries
>   that run on others processors, only slower than a binary with generic
>   optimizations.

  The most common tactic is indeed to instruct the compiler to optimize
for a certain processor (such as Pentium4) but using only opcodes of an
older processor (such as the 386). The result may not be the fastest
possible for that processor (eg. P4 in this case) because opcodes
specific to that processor are not used, but the difference is usually
not very large (you might get something like 10% or such speedup by
recompiling for P4 specifically, which is not really a whole lot). And
the binary will still work in a 386 if needed (even though it might not
be the most optimal for that processor either because the optimization
was made for the P4, not the 386).

  Perhaps a bit surprisingly, and a rather positive thing, it seems that
optimizing code for the P4 also makes the code faster in the AMD Athlon
and newer (even though not exactly as fast as an Athlon-specific
optimization, but not very far away either).

  Of course if you really want to get even the last bit of optimization,
you should download the source code distribution and compile it (the
current configure script tries to detect your hardware and tune the
optimizations for them, but you can of course also add your own optimization
flags to it). How much this will benefit will depend a lot on your system.

  Btw, there's an additional possible way of creating a binary: One which
actually has multiple binaries inside it, each optimized for a certain
processor. The binary will at runtime detect the type of processor and
run code optimized for it. I don't know if any binary distro of povray
uses this technique, though. (The Mac version might.)

-- 
                                                          - Warp

Post a reply to this message

This should answer some of your questions:

http://pov4grasp.free.fr/articles/fastpov1/

	- NC

Post a reply to this message