> Now that you have a PPC 970 compile, how fast is it compared to the defaults
> provided when rendering the standard benchmark?

With the default build I get 39 minitues in the average(3 runs)

With the 'G5 optimized' build (basically it is -fast without -fcgse) I get
35 minutes in the average(3 runs).

I can reproduce it with a deviation of several seconds.

So it seems to be 10% faster. I'll not spent much more time on optimization,
was just wondering what would be possible for the G5.
A user reported about 27 minutes. Maybe he/she was using another compiler.
Would be nice to know.

The Mac OSX GUI Version is somewhat (~2min) faster. Was it compiled with
gcc?
I assume not!

Let's see if OSX Tiger/gcc 3.5 will improve this.

Post a reply to this message

> With the default build I get 39 minitues in the average(3 runs)
> 
> With the 'G5 optimized' build (basically it is -fast without -fcgse) I get
> 35 minutes in the average(3 runs).

	Interesting.  But also a bit disappointing.  I thought a G5 clocked
at 2 GHz would give a much faster benchmark.  Here you basically get the same
score (even slightly slower) than an AMD Athlon XP 2400+, which architecture
is more than 3 years older.
	But that's most likely the compiler is not good enough for the G5 yet.

 > The Mac OSX GUI Version is somewhat (~2min) faster. Was it compiled with gcc?
 > I assume not!

	Thorsten will better answer than me, but the speed increase may also
be due to the Mac-specific just-in-time compiler that is used for the function
virtual machine, and that you don't get with the Unix version.

	- NC

Post a reply to this message

Nicolas Calimet wrote:
>     But that's most likely the compiler is not good enough for the G5 yet.

gcc has always been very poor at compiling PowerPC code, it is still at 
least 10% slower than CodeWarrior when targeting the same processor.  The 
CodeWarrior builds cannot use PPC 970 (aka G5) optimisation settings yet 
because CodeWarrior does not support them yet.  So it is actually a PPC 7450 
build that outperforms the gcc PPC 970 build.  It is not unreasonable to 
expect the the CodeWarrior build would get another 10% faster if explicitly 
targeting the PPC 970.  Not to mention, there is still at least a 5% 
overhead for the official GUI version.

>  > The Mac OSX GUI Version is somewhat (~2min) faster. Was it compiled 
> with gcc?
>  > I assume not!
> 
>     Thorsten will better answer than me, but the speed increase may also
> be due to the Mac-specific just-in-time compiler that is used for the 
> function
> virtual machine, and that you don't get with the Unix version.

No, that has pretty much zero influence on the benchmark result (10 to 20 
seconds, which is almost below the error threshold).

	Thorsten

Post a reply to this message

> So it is actually a PPC 7450 build that outperforms the gcc PPC 970 build.

Is a CodeWarrior build of the commandline version available?
Of course, everybody has gcc (if you have OSX) but in general no CodeWarrior
or IBM compiler.

A propos IBM compiler, did you try this? According to some guys it should
perform even better than CodeWarrior.

And do you know about the guy reporting 27 min on the G5 2GHz?
Can this be true?

There might be some interest in using the commandline version together with
XCode.

You can easily add language support for POVray to XCode and then you have a
much more powerful editor and development tool than the current GUI offers.
And in addition, all the power of the unix shell scripts is available.

Post a reply to this message

popov wrote:
> Is a CodeWarrior build of the commandline version available?

No, as that would imply a Mach-O build rather than a PEF Carbon version.

> A propos IBM compiler, did you try this? According to some guys it should
> perform even better than CodeWarrior.

When I tested the IBM compiler betas (they were free) I was not too 
convinced, but that was only measuring a PPC 7450 target.  It was slower 
than the CodeWarrior version.

> And do you know about the guy reporting 27 min on the G5 2GHz?
> Can this be true?

It is not unrealistic, but seems to be at the top end of what I would 
expect.  If you manage to get rid of most other processes and minimise GUI 
activity, plus, don't forget to set the energy saver processor speed to 
"highest" not "automatic" (I know that option is available on G5 iMacs, but 
I am sure about PowerMacs), it might be possible.

	Thorsten

Post a reply to this message

Thorsten wrote:
> You need to know the background to understand the answer.  That is given on
> the Apple developer page.  You certainly won't find Apple holding your hand
> and saying: Do not use -mpowerpc64 when compiling POV-Ray because [...]. ;-)

Thorsten, do you have a link to the developer page you mentioned?
I would like to know more about this.
Till now, I mostly get answers like "you are unexperienced...,it shows that
you are...,better do not compile...,"

I make a suggestion:
Could you please communicate in a more constructive way and tell me
references to qualified technical documentation proofing what you are
saying?

Most of the documentation I've consulted so far, recommends/suggests the use
of -fast or -mpowerpc64 for optimization.

And here is the reference from Apple:
http://developer.apple.com/technotes/tn/tn2086.html
http://developer.apple.com/technotes/tn/tn2087.html

What I can say for now is:
-fast does not work! It turns on a combination of optimization flags which
results in simply non working code. I wonder because -fast was intended to
boost performance on the G5. I think it is a gcc bug. Everything which is
not working as described in the documentation I consider as a bug.

-mpowerpc64 can be used (for POVray as well) with most of the optimization
flags. I've worked out a combination of optimization flags (including
mpowerpc64) on the G5 which results in a 10% performance gain compared to
the standard build which is optimized for the G4. That's not a big deal,
but I think it is worth to do it.

Others have made similar experiences according -fast/mpowerpc64
see http://www.math.colostate.edu/~hulpke/osx/

Post a reply to this message

popov wrote:
> Thorsten, do you have a link to the developer page you mentioned?

The page: The whole developer documentation on the compiler flags. Read 
them, understand what they say and what it implies.

> I would like to know more about this.
> Till now, I mostly get answers like "you are unexperienced...,it shows that
> you are...,better do not compile...,"
> 
> I make a suggestion:
> Could you please communicate in a more constructive way and tell me
> references to qualified technical documentation proofing what you are
> saying?

You have a fundamental misconception here: I have absolutely nothing to 
prove when it comes to POV-Ray and in particular when it comes to deal with 
the POV-Ray source code!  Either take my hints and my word for them or leave 
it and deal with the problems if you think you know better.  I am not a 
personal how-to-compile POV-Ray babysitter, nor do I have the time for it. 
This whole discussion is taking longer than it should have in the first 
place.  Sorry to be so direct, but compiling POV-Ray is _your_ problem 
alone, it is unsupported, so take what you can get and be happy!

	Thorsten

Post a reply to this message

Thorsten Froehlich <tho### [at] trfde> wrote:
> popov wrote:
> > Thorsten, do you have a link to the developer page you mentioned?
>
> The page: The whole developer documentation on the compiler flags. Read
> them, understand what they say and what it implies.
>
> > I would like to know more about this.
> > Till now, I mostly get answers like "you are unexperienced...,it shows that
> > you are...,better do not compile...,"
> >
> > I make a suggestion:
> > Could you please communicate in a more constructive way and tell me
> > references to qualified technical documentation proofing what you are
> > saying?
>
> You have a fundamental misconception here: I have absolutely nothing to
> prove when it comes to POV-Ray and in particular when it comes to deal with
> the POV-Ray source code!  Either take my hints and my word for them or leave
> it and deal with the problems if you think you know better.  I am not a
> personal how-to-compile POV-Ray babysitter, nor do I have the time for it.
> This whole discussion is taking longer than it should have in the first
> place.  Sorry to be so direct, but compiling POV-Ray is _your_ problem
> alone, it is unsupported, so take what you can get and be happy!
>
>  Thorsten

Post a reply to this message

Thorsten Froehlich <tho### [at] trfde> wrote:
> popov wrote:
> > Thorsten, do you have a link to the developer page you mentioned?
>
> The page: The whole developer documentation on the compiler flags. Read
> them, understand what they say and what it implies.
>
> > I would like to know more about this.
> > Till now, I mostly get answers like "you are unexperienced...,it shows that
> > you are...,better do not compile...,"
> >
> > I make a suggestion:
> > Could you please communicate in a more constructive way and tell me
> > references to qualified technical documentation proofing what you are
> > saying?
>
> You have a fundamental misconception here: I have absolutely nothing to
> prove when it comes to POV-Ray and in particular when it comes to deal with
> the POV-Ray source code!  Either take my hints and my word for them or leave
> it and deal with the problems if you think you know better.  I am not a
> personal how-to-compile POV-Ray babysitter, nor do I have the time for it.
> This whole discussion is taking longer than it should have in the first
> place.  Sorry to be so direct, but compiling POV-Ray is _your_ problem
> alone, it is unsupported, so take what you can get and be happy!
>
>  Thorsten

Thanx for your replies.
Your initial answer is in contradiction to the documentation I've referenced
to you.
I thought it would be of some interest, since others might have encountered
the same problem.
In the section of documentation about the compiler flags (I think it is the
same as the manual pages - man gcc) I cannot clearly see your point.
The ongoing and (indeed to long and time consuming) discussion has primarly
one goal for me: To find the correct answer.
As you suggested, I think it is best to stop here. Others may contribute to
the discussion..

Again, thank you very much,

Regards,

        wv

Post a reply to this message

For what it is worth, I had successfully compiled an older version of POVRAY
(3.5 I believe) with
gcc version 3.3 20030304 (Apple Computer, Inc. build 1666) using the -fast
flag and/or the -mpowerpc64 flag set.

That is not to say that some combination of compiler version/build and POV
source code may not break, since the data typing in the source code and
libraries was not written in a 64-bit context.

Post a reply to this message