 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Hi,
I'm trying to built an optimized commandline version of Povray 3.6.1 based
on the latest unix tarball on a 2GHz Powermac G5 running OSX 10.3.7.
In order to optimize for the G5, my gcc compiler flags are -O3 -mcpu=G5
-mtune=G5 -mpowerpc-gpopt -mpowerpc64
Compilation is successful, however running povray -benchmark results in a
segmentation fault at the very beginning of execution.
The reason of the segmentation fault seems to be the -mpowerpc64
optimization flag. If I compile without -mpowerpc64, everything is working
fine and I get a benchmark of 36 minutes.
Is the 3.6.1 source not compatible with the mpowerpc64 flag?
Because this flag is turned on when compiling with -fast (this turns on
various optimization flags), I get also a segmentation fault.
My gcc compiler is:
gcc (GCC) 3.3 20030304 (Apple Computer, Inc. build 1671)
Any idea?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> Is the 3.6.1 source not compatible with the mpowerpc64 flag?
I can't tell as it was not tested with it, but at least the
unix version of povray-3.6.1 is known to work on several other
64-bit platforms (for instance GNU/Linux on AMD64; IRIX64).
Can you compile a simple test program with this flag
and see if it works? If so, you could try to recompile povray
using the --enable-debug flag for configure and -mpowerpc64 in
your CXXFLAGS, run povray under a debugger, and report the
backtrace right after it segfaults.
My feeling is that gcc produces wrong code with this
optimization flag, but I didn't search google about it yet.
- NC
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
popov wrote:
> Hi,
<snip>
Please do not multi-post questions in several groups. If you post to
multiple groups you very likely get confusing answer that will just send you
and those trying to help you on a wild goose chase.
Here is my answer from p.macintosh:
-------- Original Message --------
Subject: Re: G5 optimization
Date: Wed, 02 Feb 2005 08:03:23 -0600
From: Thorsten Froehlich <tho### [at] trf de>
Newsgroups: povray.macintosh
References: <web.4200d9c11bb956ed95579c20@news.povray.org>
popov wrote:
> In order to optimize for the G5, my gcc compiler flags are -O3 -mcpu=G5
> -mtune=G5 -mpowerpc-gpopt -mpowerpc64
>
> Compilation is successful, however running povray -benchmark results in a
> segmentation fault at the very beginning of execution.
>
> The reason of the segmentation fault seems to be the -mpowerpc64
> optimization flag. If I compile without -mpowerpc64, everything is working
> fine and I get a benchmark of 36 minutes.
>
> Is the 3.6.1 source not compatible with the mpowerpc64 flag?
The flag -mpowerpc64 is simply wrong in this context. I recommend you read
and understand the Apple developer documentation or don't build POV-Ray
yourself. It is not feasible to explain a topic like this in newsgroup posting.
Thorsten
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> The flag -mpowerpc64 is simply wrong in this context.
Just a wild guess: Mac OS X 10.3 is not yet 64-bit, only the
next 10.4 version ("Tiger") is/will be?
http://developer.apple.com/macosx/tiger/64bit.html
- NC
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Nicolas Calimet <pov### [at] freefr> wrote:
> > The flag -mpowerpc64 is simply wrong in this context.
>
> Just a wild guess: Mac OS X 10.3 is not yet 64-bit, only the
> next 10.4 version ("Tiger") is/will be?
>
> http://developer.apple.com/macosx/tiger/64bit.html
>
> - NC
Look at:
http://developer.apple.com/technotes/tn/tn2087.html
and
http://developer.apple.com/technotes/tn/tn2086.html
and search for powerpc64
(Thorsten?)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Nicolas Calimet wrote:
>> The flag -mpowerpc64 is simply wrong in this context.
>
>
> Just a wild guess: Mac OS X 10.3 is not yet 64-bit, only the
> next 10.4 version ("Tiger") is/will be?
No, Mac OS X correctly handles 64-bit registers. Yet, changing a native data
type has all kinds of implications one needs to consider. One either knows
how to track down the incompatibilities this might cause or one does not.
If the later is the case, one should stay away from the option. It would
take ages to explain everything to a person asking why does compiler switch
xyz not work as he/she expects. Hence my recommendation to just not do
something like that and use the default build.
Thorsten
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Thorsten Froehlich <tho### [at] trfde> wrote:
> Nicolas Calimet wrote:
> >> The flag -mpowerpc64 is simply wrong in this context.
> >
> >
> > Just a wild guess: Mac OS X 10.3 is not yet 64-bit, only the
> > next 10.4 version ("Tiger") is/will be?
>
> No, Mac OS X correctly handles 64-bit registers. Yet, changing a native data
> type has all kinds of implications one needs to consider. One either knows
> how to track down the incompatibilities this might cause or one does not.
> If the later is the case, one should stay away from the option. It would
> take ages to explain everything to a person asking why does compiler switch
> xyz not work as he/she expects. Hence my recommendation to just not do
> something like that and use the default build.
>
> Thorsten
I think the reason why the mpowerpc64 flag is not working is a gcc bug.
I've found some information about this on the web.
http://www.vtk.org/Bug/bug.php?op=show&bugid=491&pos=10
-mpowerpc should clearly work, according to the documentation. It is turned
on if you compile the code with -fast for example. -fast turns on different
optimization flags.
Apples benchmarks for the G5 were done with -fast.
In fact it is not mpowerpc64 which produces the runtime error, it is the
combination of -mpowerpc64 together with -fgcse. Both (and about 20 other
optimization flags are turned on with -fast). If you skip just -fsce and
leave mpowerpc64, the code runs ok.
Again, the flag -fast was introduced to get optimized performance on the G5.
And Thorsten, you do not have to explain me why '-mpowerpc64 is simply
'wrong in this context', but maybe you can just give me a reference to the
apple developer documentation for this.
The default build is optimized for the PPC7450 (G4), which in some aspects
is quite different to the G5. So it is natural trying to tune the
compilation
flags according to http://developer.apple.com/hardware/ve/g5.html.
For example the -mpowerpc-gpot enables the G5's hardware floating point
square root support.
There is nothing wrong about people are playing with this. This very
important in the open software community in order to improve software and
working out bugs.
Answers a la Thorsten however are not very constructive...
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
popov wrote:
> And Thorsten, you do not have to explain me why '-mpowerpc64 is simply
> 'wrong in this context', but maybe you can just give me a reference to the
> apple developer documentation for this.
Look up what it does - it enables use of 64-bit instructions, which has far
more implications than just "speeding up long long", it also implies
something about how much bytes end up on the stack. As there is no 64-bit
memory model (yet), the use of the flag is wrong in this context - which is
compiling of POV-Ray.
> The default build is optimized for the PPC7450 (G4), which in some aspects
> is quite different to the G5.
Now that you have a PPC 970 compile, how fast is it compared to the defaults
provided when rendering the standard benchmark?
> There is nothing wrong about people are playing with this. This very
> important in the open software community in order to improve software and
> working out bugs.
> Answers a la Thorsten however are not very constructive...
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
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> 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
|
|
| |
| |
|
|
|
|
| |
