I've been running the Linux povray binary under linux emulation on 
(NetBSD 1.6_BETA4) without any problems but I decided trying to 
compiling from source to see if there would be a significant speed 
defference. The thing is there seems to be,... only the linux binary is 
faster than my (statically linked!) compile.
Does anyone know the optimisation settings/ other performance tweaks 
used to compile the linux binary distributed from the pov site?

Rob

Post a reply to this message

Rob Hoopman <rob### [at] tunanl> wrote:
> Does anyone know the optimisation settings/ other performance tweaks 
> used to compile the linux binary distributed from the pov site?

  There was a thread about that issue, I think it was in this same group,
and there were good compiler flag suggestions there. I don't remember
the name of the thread, but you should browse previous threads here.

  Anyways, the usual gcc optimization flags (which are not platform-specific)
used are something like "-O6 -ffast-math -fomit-frame-pointer".
  Besides these, you should use the optimization flags dependant on your
system. IIRC these include several -m* flags, such as -mcpu=(your cpu type)
and other similar ones.
  "gcc -v --help |& less" should give you a full list of options.

-- 
#macro N(D)#if(D>99)cylinder{M()#local D=div(D,104);M().5,2pigment{rgb M()}}
N(D)#end#end#macro M()<mod(D,13)-6mod(div(D,13)8)-3,10>#end blob{
N(11117333955)N(4254934330)N(3900569407)N(7382340)N(3358)N(970)}//  - Warp -

Post a reply to this message

Warp wrote:
> Rob Hoopman <rob### [at] tunanl> wrote:
> 
>>Does anyone know the optimisation settings/ other performance tweaks 
>>used to compile the linux binary distributed from the pov site?
> 
> 
>   There was a thread about that issue, I think it was in this same group,
> and there were good compiler flag suggestions there. I don't remember
> the name of the thread, but you should browse previous threads here.
> 
I already had a look around but haven't been able to find anything, but 
I'll have a closer look.


>   Anyways, the usual gcc optimization flags (which are not platform-specific)
> used are something like "-O6 -ffast-math -fomit-frame-pointer".
>   Besides these, you should use the optimization flags dependant on your
> system. IIRC these include several -m* flags, such as -mcpu=(your cpu type)
> and other similar ones.
>   "gcc -v --help |& less" should give you a full list of options.

Those are the obvious ones and the ones I used already, my gcc is at 
2.95.3 is gcc 3+ used for the pov builds and could this result in a 
significant speed gain?

I'm not talking about a small increase, for illlustration a simple scene 
( FWIW: 4 panes of glass on a checkered floor using photons )

linux precompiled binary:
	2 secs parse 55 secs trace
native build:	
	2 secs parse 201 secs trace

Something is _really_ strange here, this can't be only optimisation flags?

System Athlon TB 1Ghz, 512Mb CAS2.5 DDR SDRAM


Rob

Post a reply to this message

Rob Hoopman wrote:
> Those are the obvious ones and the ones I used already, my gcc is at 
> 2.95.3 is gcc 3+ used for the pov builds and could this result in a 
> significant speed gain?

gcc 3.1.1 did show a pretty good speed boost over gcc 2.96 (those are
the versions I tested). For instance, rendering benchmark.pov produced
the following times using the same optimization settings:

gcc 2.96:  28m 1s
gcc 3.1.1: 25m 14s

The prebuilt binary from 8/7/02 took 34m 10s (the earlier prebuilt binary
was MUCH slower).

> I'm not talking about a small increase, for illlustration a simple scene 
> ( FWIW: 4 panes of glass on a checkered floor using photons )
> 
> linux precompiled binary:
>     2 secs parse 55 secs trace
> native build:   
>     2 secs parse 201 secs trace
> 
> Something is _really_ strange here, this can't be only optimisation flags?
> 
> System Athlon TB 1Ghz, 512Mb CAS2.5 DDR SDRAM

You need to place the optimization flags in 2 places; at least that worked
for me. What I did was run the ./configure then edited the src/Makefile
and changed the CXXFLAGS and CFLAGS to the following:

CXXFLAGS = -g -O3 -s -mcpu=athlon -march=athlon -finline-functions 
-ffast-math \
-fomit-frame-pointer -Wall -funroll-loops -fexpensive-optimizations \
-malign-double -foptimize-sibling-calls -minline-all-stringops 
$(NOMULTICHAR)

CFLAGS = -g -O3 -s -mcpu=athlon -march=athlon -finline-functions 
-ffast-math \
-fomit-frame-pointer -Wall -funroll-loops -fexpensive-optimizations \
-malign-double -foptimize-sibling-calls -minline-all-stringops

You'll notice that they're almost identical except for the NOMULTICHAR part.

Hope this helps!

-Roz

Post a reply to this message

Roz <Rzl### [at] netscapenet> wrote:
> CXXFLAGS = -g

  Don't use -g.
  That flag is for debugging purposes only. Since you are compiling a final
version with extreme optimizations, -g is not only useless and cause the
binary to be uselessly large (until stripped), but it even *might* contradict
with some optimizations, thus resulting in a slightly less optimized binary
(perhaps this is not the case, but it could be).

-- 
#macro M(A,N,D,L)plane{-z,-9pigment{mandel L*9translate N color_map{[0rgb x]
[1rgb 9]}scale<D,D*3D>*1e3}rotate y*A*8}#end M(-3<1.206434.28623>70,7)M(
-1<.7438.1795>1,20)M(1<.77595.13699>30,20)M(3<.75923.07145>80,99)// - Warp -

Post a reply to this message

Warp wrote:
> Roz <Rzl### [at] netscapenet> wrote:
> 
>>CXXFLAGS = -g
> 
> 
>   Don't use -g.
>   That flag is for debugging purposes only. Since you are compiling a final
> version with extreme optimizations, -g is not only useless and cause the
> binary to be uselessly large (until stripped), but it even *might* contradict
> with some optimizations, thus resulting in a slightly less optimized binary
> (perhaps this is not the case, but it could be).
> 

That's what I get for piecing together everyone's suggestion for flags :P

Thanks Warp, I'll do some test renders without that debugging flag!

-Roz

Post a reply to this message

Roz wrote:
> Warp wrote:
> 
>> Roz <Rzl### [at] netscapenet> wrote:
>>
>>> CXXFLAGS = -g
>>
>>
>>
>>   Don't use -g.
>>   That flag is for debugging purposes only. Since you are compiling a 
>> final
>> version with extreme optimizations, -g is not only useless and cause the
>> binary to be uselessly large (until stripped), but it even *might* 
>> contradict
>> with some optimizations, thus resulting in a slightly less optimized 
>> binary
>> (perhaps this is not the case, but it could be).
>>
> 
> That's what I get for piecing together everyone's suggestion for flags :P
> 
> Thanks Warp, I'll do some test renders without that debugging flag!

Strangely, it didn't make any difference. The file size is the same and
the rendering times didn't really change. Perhaps the -s flag overrides
the -g flag? Either way, it might as well not be there.

-Roz

Post a reply to this message

Roz <Rzl### [at] netscapenet> wrote:
> Strangely, it didn't make any difference. The file size is the same and
> the rendering times didn't really change. Perhaps the -s flag overrides
> the -g flag? Either way, it might as well not be there.

  Ah, I didn't notice that you had a -s flag as well. If I had, I would have
also said that "the -g is even more useless since you are removing all the
debugging information it produces with -s".
  AFAIK -s does not turn off -g, but it simply tells the linker to strip the
final binary. The compiler still adds the extra debugging information when
you specify -g (you can see this from the difference in size of the .o files).

  If -g does not have any negative effect in speed, then that's good. However,
it's still useless to specify it, and you only get a lot larger object files,
wasting your disk space.
  (Note that -s still makes a difference even when you don't specify -g; the
binary still has some debugging information which can be stripped; what -g
does is to add *extra* debugging information.)

-- 
#macro N(D)#if(D>99)cylinder{M()#local D=div(D,104);M().5,2pigment{rgb M()}}
N(D)#end#end#macro M()<mod(D,13)-6mod(div(D,13)8)-3,10>#end blob{
N(11117333955)N(4254934330)N(3900569407)N(7382340)N(3358)N(970)}//  - Warp -

Post a reply to this message

Warp wrote:
> Roz <Rzl### [at] netscapenet> wrote:
> 
>>CXXFLAGS = -g
> 
> 
>   Don't use -g.
>   That flag is for debugging purposes only. Since you are compiling a final
> version with extreme optimizations, -g is not only useless and cause the
> binary to be uselessly large (until stripped), but it even *might* contradict
> with some optimizations, thus resulting in a slightly less optimized binary
> (perhaps this is not the case, but it could be).
> 

NetBSD does not have a gcc 3+ packages yet but I compiled it from source 
using the compiler glags suggested by you and Roz.

This turns out to give a major speed gain, I've attached some data in 
case anyone is interested.

Rob

Post a reply to this message

Attachments:
Download 'us-ascii' (2 KB)