Specs:
	Athlon 1.1 gHz Thunderbird
	RedHat 7.2
	gcc v.2.96 (stock on rh7.2)

Problem:
	Can't get 3.5 source to compile.


Errors:

Making all in src
make[1]: Entering directory `/home/jgentry/temp/povray-3.50a/src'
g++ -DPREFIX=\"/usr/local\" 
-DPOV_LIB_DIR=\"/usr/local/share/povray-3.5\" 
-DCOMPILER_VER=\".Linux.gcc\" -DSYSCONFDIR=\"/usr/local/etc\"     `if [ 
"Xgcc" = "Xgcc" ]; then echo "-Wno-multichar"; fi ` -c atmosph.cpp
g++ -DPREFIX=\"/usr/local\" 
-DPOV_LIB_DIR=\"/usr/local/share/povray-3.5\" 
-DCOMPILER_VER=\".Linux.gcc\" -DSYSCONFDIR=\"/usr/local/etc\"     `if [ 
"Xgcc" = "Xgcc" ]; then echo "-Wno-multichar"; fi ` -c bbox.cpp
In file included from bbox.cpp:47:
optout.h:75: syntax error before `char'
bbox.cpp: In function `int sort_and_split (BBOX_TREE **, BBOX_TREE **&,
long int *, long int, long int)':
bbox.cpp:1872: warning: assignment to `long int' from `double'
bbox.cpp:1872: warning: argument to `long int' from `double'
make[1]: *** [bbox.o] Error 1
make[1]: Leaving directory `/home/jgentry/temp/povray-3.50a/src'
make: *** [all-recursive] Error 1

I solved the "optout.h:49: #error You must complete the following 
DISTRIBUTION_MESSAGE macro " problem thanks to Micha's post.  Now I'm 
running into all of these different sytax errors during make.  The 
configure process went fine, no probs.  I'm not a programmer, so these 
error codes mean little.  any help would be appreciated.

-- Jeff

Post a reply to this message

earthdog wrote:

> Specs:
> Athlon 1.1 gHz Thunderbird
> RedHat 7.2
> gcc v.2.96 (stock on rh7.2)
> 
> Problem:
> Can't get 3.5 source to compile.

  I can't help specifically, but it compiled here with the same system 
(only this is 1.2Ghz). I had to update libpng and zlib to the latest 
versions, but then it compiled fine. I added then the optimization flags 
and it worked a 33% faster. Later I upgraded gcc to 3.1.1 and compiled 
again, this time with better optimizations, and now it runs at the same 
speed as in windows.

-- 
Jaime Vives Piqueres

La Persistencia de la Ignorancia
http://www.ignorancia.org

Post a reply to this message

earthdog wrote:
> Specs:
>     Athlon 1.1 gHz Thunderbird
>     RedHat 7.2
>     gcc v.2.96 (stock on rh7.2)
> 
> Problem:
>     Can't get 3.5 source to compile.


I finally had a chance to compile 3.5 on my system (rh7.1 Athlon XP
1900+ gcc 2.96). I didn't run into any problems other than having to
edit optout.h like everyone else and creating a povray.conf file in the
/usr/local/etc directory to stop the I/O Restriction problem.

After doing ./configure and make, I tested the resulting binary out and 
it worked fine. Then I edited the src/Makefile to add some compiler
optimization flags. The CXXFLAGS now look like this:

CXXFLAGS = -g -O3 -DCPU=athlon -march=athlon -finline-functions \
-fomit-frame-pointer -Wall -funroll-loops -fexpensive-optimizations \
-malign-double $(NOMULTICHAR)

There's probably some redundant flags but it works ;) I then ran
benchmark.pov (+a0.3 +w320 +h240) and got the following results:

windows prebuilt binary = 25m 48s (1548s)
linux prebuilt binary = 55m 40s (3340s)
Micha's p3 optimized = 25m 14s (1514s)
my gcc2.96 optimized = 28m 1s (1681s)

I then applied Micha's patch and got the following result:

my optimized + patch = 28m 14s (1694s)

So the patch didn't really help me but it may help with gcc 3.1. I'm
going to get that next and see what the results are. It sure looks like
gcc has improved :)


 > Errors:
 >
 > Making all in src
 > make[1]: Entering directory `/home/jgentry/temp/povray-3.50a/src'
 > g++ -DPREFIX=\"/usr/local\"
 > -DPOV_LIB_DIR=\"/usr/local/share/povray-3.5\"
 > -DCOMPILER_VER=\".Linux.gcc\" -DSYSCONFDIR=\"/usr/local/etc\"     `if
 > [ "Xgcc" = "Xgcc" ]; then echo "-Wno-multichar"; fi ` -c atmosph.cpp
 > g++ -DPREFIX=\"/usr/local\"
 > -DPOV_LIB_DIR=\"/usr/local/share/povray-3.5\"
 > -DCOMPILER_VER=\".Linux.gcc\" -DSYSCONFDIR=\"/usr/local/etc\"     `if
 > [ "Xgcc" = "Xgcc" ]; then echo "-Wno-multichar"; fi ` -c bbox.cpp
 > In file included from bbox.cpp:47:
> optout.h:75: syntax error before `char'

[snip]

Since it looks like the first error is in optout.h and you had edited
optout.h, I'm wondering if something weird happened as a result of the
edit. Perhaps you could yank the original optout.h from the tarball,
edit the DISTRIBUTION_MESSAGE_2, comment out the error line above it and 
give it another go.

-Roz

Post a reply to this message

Roz <Rzl### [at] netscapenet> wrote:
> windows prebuilt binary = 25m 48s (1548s)
> linux prebuilt binary = 55m 40s (3340s)
> Micha's p3 optimized = 25m 14s (1514s)
> my gcc2.96 optimized = 28m 1s (1681s)

  I am wondering if it's a good idea to keep such slow version of povray
for linux in www.povray.org if even gcc2 can do such good job at optimizing.
  By the way, how is it possible that the official version is so slow? Was
it compiled with no optimizations at all?-o

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

Roz wrote:

> CXXFLAGS = -g -O3 -DCPU=athlon -march=athlon -finline-functions \
> -fomit-frame-pointer -Wall -funroll-loops -fexpensive-optimizations \
> -malign-double $(NOMULTICHAR)
> 

use also -ffast-math 

My currently fastest binary was produced with (for gcc 3.1)
CXXFLAGS = -Wno-multichar -O3 -ffast-math -march=pentium3 -mcpu=pentium3 
-fomit-frame-pointer -foptimize-sibling-calls -funroll-loops -malign-double 
-minline-all-stringops

- Micha

-- 
http://objects.povworld.org - the POV-Ray Objects Collection

Post a reply to this message

Warp wrote:
> Roz <Rzl### [at] netscapenet> wrote:
> 
>>windows prebuilt binary = 25m 48s (1548s)
>>linux prebuilt binary = 55m 40s (3340s)
>>Micha's p3 optimized = 25m 14s (1514s)
>>my gcc2.96 optimized = 28m 1s (1681s)
> 
> 
>   I am wondering if it's a good idea to keep such slow version of povray
> for linux in www.povray.org if even gcc2 can do such good job at optimizing.
>   By the way, how is it possible that the official version is so slow? Was
> it compiled with no optimizations at all?-o
> 

It looked like the default optimization settings were "-g -O2". Now that 
I think about it, that might have been only in the CFLAGS but not in the 
CXXFLAGS. Yep, there's the problem. So the default compiling results in
no optimization at all because at least on my system, it's the CXXFLAGS 
that are being passed to g++. I placed my optimization flags in both
CFLAGS and CXXFLAGS (leaving the NOMULTICHAR part in the CXXFLAGS
intact). Of course, my optimization settings included targeting the 
Athlon architecture. But even without those machine specific flags, the
other optimizations should help.

It would be nice to have a faster pre-compiled Linux binary available
for people to use. Alternatively, maybe some optimized versions like
Micha's p3 one could be provided in addition to the generic (slow :P)
binary.

-Roz

Post a reply to this message

Warp wrote:

>   I am wondering if it's a good idea to keep such slow version of povray
> for linux in www.povray.org if even gcc2 can do such good job at
> optimizing.
>   By the way, how is it possible that the official version is so slow? Was
> it compiled with no optimizations at all?-o

 Only -O2... but I think what make the great difference is using specific 
-mcpu and -march. Perhaps for the official distribution -O3 can be used, 
but not much more can be done, I think, except encouraging to compile the 
sources for your rendering palataform, perhaps with recommended flags. It's 
not that difficult at all: I myself have done it and I've no knowledge 
about c, c++, compilers and optimization. 

-- 
Jaime Vives Piqueres

La Persistencia de la Ignorancia
http://www.ignorancia.org

Post a reply to this message

Micha Riser wrote:
> Roz wrote:
> 
> 
>>CXXFLAGS = -g -O3 -DCPU=athlon -march=athlon -finline-functions \
>>-fomit-frame-pointer -Wall -funroll-loops -fexpensive-optimizations \
>>-malign-double $(NOMULTICHAR)
>>
> 
> 
> use also -ffast-math 
> 
> My currently fastest binary was produced with (for gcc 3.1)
> CXXFLAGS = -Wno-multichar -O3 -ffast-math -march=pentium3 -mcpu=pentium3 
> -fomit-frame-pointer -foptimize-sibling-calls -funroll-loops -malign-double 
> -minline-all-stringops
> 
> - Micha
> 

I actually tried the -ffast-math option, then tried to render 
balcony.pov and got spammed with the following lines repeatedly:

Warning: Illegal grid value in dda_traversal().
The height field may contain dark spots. To eliminate them
moving the camera a tiny bit should help. For more information
read the user manual!

Weird, huh? Since that scene rendered fine before the -ffast-math flag, 
I figured it's better for me not to use it. Maybe it's buggy with gcc 
2.96 but works with gcc 3.1?

I'll give the other flags a go and run some more benchmark renders.

-Roz

Post a reply to this message

Jaime Vives Piqueres wrote:
> Warp wrote:
> 
> 
>>  I am wondering if it's a good idea to keep such slow version of povray
>>for linux in www.povray.org if even gcc2 can do such good job at
>>optimizing.
>>  By the way, how is it possible that the official version is so slow? Was
>>it compiled with no optimizations at all?-o
> 
> 
>  Only -O2... but I think what make the great difference is using specific 
> -mcpu and -march. Perhaps for the official distribution -O3 can be used, 
> but not much more can be done, I think, except encouraging to compile the 
> sources for your rendering palataform, perhaps with recommended flags. It's 
> not that difficult at all: I myself have done it and I've no knowledge 
> about c, c++, compilers and optimization. 
> 

Yes, the cpu targeting helps some. But it turns out to help a lot just 
to get the -O2 optimization settings in both CFLAGS and CXXFLAGS. The 
default compiliation only put the -g -O2 flags in CFLAGS. I ran 
benchmark.pov against a build with only the -O2 optimization flag in 
both CFLAGS and CXXFLAGS and here's the resulting times:

default options (only in CFLAGS) = 55m 40s (3340s)
-O2 optimized (in both directives) = 29m 1s (1741s)

So maybe just getting a build based on the intended optimizations would 
be a good thing to provide on the POV-Ray web site.

-Roz

Post a reply to this message

On Sat, 03 Aug 2002 16:16:28 -0400, Warp wrote:

>   I am wondering if it's a good idea to keep such slow version of povray
> for linux in www.povray.org if even gcc2 can do such good job at
> optimizing.

I plan to have an updated binary by the end of the weekend.

-Mark Gordon

Post a reply to this message