 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Hi all-
I just wanted to share some benchmarks I've done with POV Ray 3.5c on a G5
running OSX 10.2.8. The box is the "middle version" with a single 1.8ghz G5
processor and 4gig(!) of ram. It's basically the stock box from Apple. All
tests were done using the benchmark.pov and benchmark.ini file, and all were
rendered via the Unix source code compiled on the machine natively.
POV Ray compiled with gcc3.3 as part of fink distribution (no
optimizations):
Parse Time: 6 seconds
Photon Time: 1 minute, 12 seconds
Trace Time: 43 minutes, 18 seconds
Total Time: 44 minutes, 36 seconds
POV Ray compiled with G5 optimizations in gcc3.3
(switches -mcpu=970 -mtune=970 -mpowerpc64 -mpowerpc-gpopt)
Parse Time: 5 seconds
Photon Time: 1 minute, 6 seconds
Trace Time: 46 minutes, 54 seconds
Total Time: 48 minutes, 5 seconds
POV Ray compiled with IBM's xlC V6.0 BETA compiler
(switches -qarch=ppc970 -qtune=ppc970 -qalign=natural -O3)
Parse Time: 6 seconds
Photon Time: 1 minute, 17 seconds
Trace Time: 43 minutes, 56 seconds
Total Time: 45 minutes, 19 seconds
I would think that POV Ray would always benefit from better floating point
performance, but I could be mistaken. I'd be willing to rerun any and all
tests with any other variations if asked. :)
Again this is an unscientific test done by me for my own amusement ("So what
can I do with this G5 thing?")
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3f94a116$1@news.povray.org>,
"Jenna Olson" <wan### [at] comcast net> wrote:
> The box is the "middle version" with a single 1.8ghz G5
> processor and 4gig(!) of ram.
/me looks at his poor, beaten up old G3...350MHz and 384MB RAM, half the
original handles, and a case warped badly enough the door barely opens
and is even more difficult to get closed again. I'm hoping to stick a G4
processor in it this Christmas, along with a little more RAM.
--
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: chr### [at] tagpovrayorg
http://tag.povray.org/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Mon, 20 Oct 2003 21:59:31 -0500, "Jenna Olson" <wan### [at] comcastnet>
wrote:
> I just wanted to share some benchmarks
What about reporting at http://www.haveland.com/povbench/ ?
ABX
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Jenna Olson wrote:
>I would think that POV Ray would always benefit from better floating point
>performance, but I could be mistaken. I'd be willing to rerun any and all
>tests with any other variations if asked. :)
>
>Again this is an unscientific test done by me for my own amusement ("So what
>can I do with this G5 thing?")
I've been anxiously waiting for someone to try those, thanks!
I'm surprised the IBM compiler didn't help more; I had high hopes for
it with POV-Ray after seeing a presentation. Like you, I thought POV-Ray
used a lot of double-precision floating point, so the G5 should be a
perfect match. Maybe there's some special switch that will make a big
difference. Do you know what "-qalign=natural" does?
I see at http://www.haveland.com/index.htm?povbench/index.php
that a 2 GHz G5 ran the benchmark in 27:27 so it looks like the
standard compile (CodeWarrier) is much faster than gcc. (Since POV-Ray
doesn't take advantage of multiple processors, I'd think your 1.8
would bench very close to the 2.)
Christopher James Huff wrote:
>me looks at his poor, beaten up old G3...350MHz and 384MB RAM, half the
>original handles, and a case warped badly enough the door barely opens
>and is even more difficult to get closed again. I'm hoping to stick a G4
>processor in it this Christmas, along with a little more RAM.
I was feeling sorry for you until I checked your website and found
you cheat :-) and render on a 2400+ Athlon! Nice solution; I had
been looking at an Athlon machine to replace my Mac before they
announced the G5's. I'll probably still get a G5, but I'd hoped for
better POV-Ray performance.
The benchmark page shows a 2400+ running an XP optimized version
at around the same time as a 2GHz G5. Have you tried the benchmark
on your machine?
-Mark
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3f94a116$1@news.povray.org> , "Jenna Olson"
<wan### [at] comcastnet> wrote:
> POV Ray compiled with IBM's xlC V6.0 BETA compiler
> (switches -qarch=ppc970 -qtune=ppc970 -qalign=natural -O3)
Note that -O3 is _not_ the maximum optimisation setting for IBMs compiler.
The maximum is -O5. Also note that the default architecture/tuning will be
automatically selected to be correct for the architecture you are running
on, so if you compile on the G5, no need to tell the compiler to optimise
for it. Also, you shouldn't be forcing unsuitable structure alignment on
the compiler, leaving it at the default for the core code files will be
best.
In any case, make sure you specify -qaltivec, -qnostrict, qfloat=nonans,
-qignerrno . ALso, you may want to try profile guided optimisations on
texture.c .
> POV Ray compiled with gcc3.3 as part of fink distribution (no
> optimizations):
I think there is something wrong with these results if the compiler is
indeed gcc. Most likely the cause is that the ppc970 option (instead of the
ppcv option) for xlc just like the mpowerpc64 option for gcc generates 64
bit code rather than 32 bit code. Hence, with a heavily memory dependent
program like POV-Ray, you will always see a significant loss of performance
when generating 64 bit code, especially with the plain 3.5 source code (but
that is another story).
Thorsten
____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde
Visit POV-Ray on the web: http://mac.povray.org
Post a reply to this message
|
|
| |
| |
|
|
From: Thorsten Froehlich
Subject: Re: Unscientific POV Ray 3.5 on G5 tests
Date: 21 Oct 2003 03:59:38
Message: <3f94e76a@news.povray.org>
|
|
|
| |
| |
|
|
In article <web.3f94c90681b0262316ba2f280@news.povray.org> , "Renderdog"
<slo### [at] hiwaaynet> wrote:
> I'm surprised the IBM compiler didn't help more;
I think the last two results targeted the PowerPC in 64 bit mode rather than
32 bit mode. With the plain 3.5 source code a noticeable loss of
performance can be expected this way, due to complex implementation
"effects" that cannot be noticed when targeting a 32 bit platform.
Thorsten
____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde
Visit POV-Ray on the web: http://mac.povray.org
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Regarding the -O5 switch, I tried compiling with that, but it caused the
compiler itself to crash.
I will try another run with your recommendations.
"Thorsten Froehlich" <tho### [at] trfde> wrote in message
news:3f94e5b8$1@news.povray.org...
> In article <3f94a116$1@news.povray.org> , "Jenna Olson"
> <wan### [at] comcastnet> wrote:
>
> > POV Ray compiled with IBM's xlC V6.0 BETA compiler
> > (switches -qarch=ppc970 -qtune=ppc970 -qalign=natural -O3)
>
> Note that -O3 is _not_ the maximum optimisation setting for IBMs compiler.
> The maximum is -O5. Also note that the default architecture/tuning will
be
> automatically selected to be correct for the architecture you are running
> on, so if you compile on the G5, no need to tell the compiler to optimise
> for it. Also, you shouldn't be forcing unsuitable structure alignment on
> the compiler, leaving it at the default for the core code files will be
> best.
>
> In any case, make sure you specify -qaltivec, -qnostrict, qfloat=nonans,
> -qignerrno . ALso, you may want to try profile guided optimisations on
> texture.c .
>
> > POV Ray compiled with gcc3.3 as part of fink distribution (no
> > optimizations):
>
> I think there is something wrong with these results if the compiler is
> indeed gcc. Most likely the cause is that the ppc970 option (instead of
the
> ppcv option) for xlc just like the mpowerpc64 option for gcc generates 64
> bit code rather than 32 bit code. Hence, with a heavily memory dependent
> program like POV-Ray, you will always see a significant loss of
performance
> when generating 64 bit code, especially with the plain 3.5 source code
(but
> that is another story).
>
> Thorsten
>
> ____________________________________________________
> Thorsten Froehlich, Duisburg, Germany
> e-mail: tho### [at] trfde
>
> Visit POV-Ray on the web: http://mac.povray.org
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <web.3f94c90681b0262316ba2f280@news.povray.org>,
"Renderdog" <slo### [at] hiwaaynet> wrote:
> I'm surprised the IBM compiler didn't help more; I had high hopes for
> it with POV-Ray after seeing a presentation. Like you, I thought POV-Ray
> used a lot of double-precision floating point, so the G5 should be a
> perfect match. Maybe there's some special switch that will make a big
> difference. Do you know what "-qalign=natural" does?
Well, AFAIK, the G5 does have some improvements in that area, but its
main improvements are elsewhere. And it could have been something with
the settings chosen.
> I was feeling sorry for you until I checked your website and found
> you cheat :-) and render on a 2400+ Athlon! Nice solution; I had
> been looking at an Athlon machine to replace my Mac before they
> announced the G5's. I'll probably still get a G5, but I'd hoped for
> better POV-Ray performance.
Hmm, G4 iBooks are out now...
Despite the differences in processing speed, I definitely spend more
time on my Mac. Internet access is almost exclusively done on the Mac,
and early prototyping of programs or simple programs that don't need
much processing power.
The ssh script works, but has a bit too much lag, slowing down quick
edit-render cycles. I've been doing most stuff locally lately.
> The benchmark page shows a 2400+ running an XP optimized version
> at around the same time as a 2GHz G5. Have you tried the benchmark
> on your machine?
Yes, but I don't remember the results. It took around 25-30 minutes, as
I recall.
--
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: chr### [at] tagpovrayorg
http://tag.povray.org/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
I compiled modfied UNIX sources with hardware square root __fsqrt()
substituted for sqrt() in XCODE version 1.1 .
I got about 32 minutes render time on a dual 2Ghz G5 Mac for benchmark.pov
using the benchmark.ini settings file
My conclusion is that you burn up all of the G5 optmizations in GCC3.3 just
to catch up about even with a CODE WARRIOR compilation.
I hard coded __fsqrt because a test on my machine shows erratic (or
non-existent) forced conversion using the "Additional Compiler Flags" in
XCODE
A test on my machine shows that __fsqrt function executes about 6.8 times
faster than sqrt().
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
