I was wondering if anyone had or is planning
to collect MacPOV benchmarks on the new PowerMac G5.
Apparently the floating-point performance is exceptional.

Also, since the physical address space is up
to four terabytes, how complex a POV scene could be
(assuming a 64-bit OS X port).


Ray Gardener
Daylon Graphics Ltd.
"Heightfield modeling perfected"
http://www.daylongraphics.com

Post a reply to this message

In article <3ef7eaf1$1@news.povray.org> , "Ray Gardener" 
<ray### [at] daylongraphicscom> wrote:

> I was wondering if anyone had or is planning
> to collect MacPOV benchmarks on the new PowerMac G5.
> Apparently the floating-point performance is exceptional.

The systems ship in August, and that doesn't mean the compilers used to
benchmark it are available on Macs.  To be precise, to benchmark its Power
processors (and the PowerPC 970 processor is just a stripped down Power4
with a SIMD extension), IBM always uses IBM C for AIX, and
IBM VisualAge C++ Professional for AIX, benchmarking on, well AIX as you can
for example see on the SPEC results page:
<http://www.spec.org/cpu2000/results/res2002q4/cpu2000-20021111-01822.html>

And the only other currently available compiler support it, which is gcc, is
unfortunately, substandard as far as optimisations for non-x86 targets, and
Power(PC)) processors in particular, are concerned.  The only compiler
generating code with reasonable performance for Mac OS is Metrowerks
CodeWarrior, and it usually takes Metrowerks a few month before optimisation
for a specific processor is supported.

So it will take until the end of the year to get really serious benchmark
results.  Nevertheless, POV-Ray performance does tend to be well in line
with SPEC benchmark predictions, so good performance is to be expected.

Of course, *if* Motorola should feel insulted, they *could* order Metrowerks
not to provide a PowerPC 970 optimisation options.  Also I do *not* think
they would, given the turf wars that have crippled Motorola's semiconductor
products sector in the past decade (and before), nothing is impossible.  For
example, they are still holding back source code for their old, but still
fast, optimized floating-point C library routines that shipped with the
first PowerMac development tools (in compiled form only).  So nobody has
been able to retarget that library for later generations of PowerPC
processors with longer pipelines and different instruction scheduling
requirements :-(

    Thorsten

____________________________________________________
Thorsten Froehlich
e-mail: mac### [at] povrayorg

I am a member of the POV-Ray Team.
Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

> Also, since the physical address space is up
> to four terabytes, how complex a POV scene could be
> (assuming a 64-bit OS X port).

For many years (up to 4 years ago) I used to run Povray on
64 bit alphas and now on itaniums.
The memory stuff is a two edged sword, I often had to
revert to 32 bit processors because on a 64 bit machine
(with the same total ram as as a 32 bit machine) I used 
to run out of memory because more memory was needed due
to longer addresses etc.
-- 
Paul Bourke
pdb_NOSPAMswin.edu.au

Post a reply to this message

Ray Gardener wrote:
> I was wondering if anyone had or is planning
> to collect MacPOV benchmarks on the new PowerMac G5.
> Apparently the floating-point performance is exceptional.

Yeah.  Although if you read the fine print in the veritest pdf, it becomes
clear that they rather lied about some of that.  Used lousy compilers for
the competition, disabled their hyperthreading, etc.  Used a fast but
memory-inefficient malloc library for their own tests.  Used compiler flags
that aren't useful in realworld apps.  If you compare to, say, Dell's
benchmarks of their own systems (which are probably similarly deceptive),
Apple's are competitive but not the best.

Also remember that POV is single threaded, so you won't benefit from
multiple processors.  It is very difficult to multithread an application
like POV, so it's unlikely to happen soon.  There existed a multithreaded
version out there somewhere, but AFAIK it's not up-to-date (Thorsten would
know).

Enough of the bad news... It's possible that the Altivec SIMD unit does make
the G5 the fastest desktop for some applications (Photoshop, codebreaking,
FFT).  IIRC the G4-optimized version of POV uses Altivec, which would help
in the G5 code too.  And render speeds would benefit immensely from the
increased memory bandwidth in the G5.

Thorsten Froehlich wrote:
>The systems ship in August, and that doesn't mean the compilers used to
>benchmark it are available on Macs.  To be precise, to benchmark its Power
>processors (and the PowerPC 970 processor is just a stripped down Power4
>with a SIMD extension), IBM always uses IBM C for AIX, and
>IBM VisualAge C++ Professional for AIX, benchmarking on, well AIX as you can
>for example see on the SPEC results page:
><http://www.spec.org/cpu2000/results/res2002q4/cpu2000-20021111-01822.html>

It was compiled with GCC 3.something.

>And the only other currently available compiler support it, which is gcc, is
>unfortunately, substandard as far as optimisations for non-x86 targets, and
>Power(PC)) processors in particular, are concerned.  The only compiler
>generating code with reasonable performance for Mac OS is Metrowerks
>CodeWarrior, and it usually takes Metrowerks a few month before optimisation
>for a specific processor is supported.

Apple is releasing a G5-optimizing version of GCC as part of the free
devtools upgrade (XCode I think it's called).  I don't know how good their
optimizations are, but they are there.

So, it may be possible to get them sooner.  Although as Thorsten mentioned
in the Mac thread, some POV developer would have to go buy a G5 in order to
optimize, which would be a tad expensive for a free software project and is
unlikely to happen immediately.

Mike

Post a reply to this message

Yeah, I notice that POV uses lots of pointers
inside scene object structures. I'm wondering of some
of them can be collapsed to bitmask flags with a
pointer tacked onto the object only if its associated
bit flag is on.

Ray Gardener
Daylon Graphics Ltd.
"Heightfield modeling perfected"
http://www.daylongraphics.com


"Paul Bourke" <pdb### [at] swineduau> wrote in message
news:pdb### [at] netplexaussieorg...
> > Also, since the physical address space is up
> > to four terabytes, how complex a POV scene could be
> > (assuming a 64-bit OS X port).
>
> For many years (up to 4 years ago) I used to run Povray on
> 64 bit alphas and now on itaniums.
> The memory stuff is a two edged sword, I often had to
> revert to 32 bit processors because on a 64 bit machine
> (with the same total ram as as a 32 bit machine) I used
> to run out of memory because more memory was needed due
> to longer addresses etc.
> --
> Paul Bourke
> pdb_NOSPAMswin.edu.au

Post a reply to this message

In article <web.3ef882511b6e269c7f877a1c0@news.povray.org> , "hamburg" 
<ham### [at] fasharvardedu> wrote:

> Yeah.  Although if you read the fine print in the veritest pdf, it becomes
> clear that they rather lied about some of that.

I suppose you read that strange page macnn.com pointed to?  That person
there actually didn't really understand SPEC benchmarking at all.  Half of
the conclusions were wrong there because the person did not notice that SPEC
speed tests run always only run on a single processor.  And single processor
systems do outperform multiprocessor systems (using even exactly the same
configuration otherwise) in a single processor benchmark by a few percent
because there is some unavoidable overhead managing multiple CPUs in
hardware.

> If you compare to, say, Dell's
> benchmarks of their own systems (which are probably similarly deceptive),
> Apple's are competitive but not the best.

Actually, the problem is that Apple used gcc on the Macs while IBM always
uses the AIX compiler when publishing SPEC results.  gcc is just plain
terrible compared to any vendor specific compiler tuned for maximum SPEC
benchmark performance.  Intel is kind of king there because, if you actually
look closely at the stats, the Intel compiler does a really almost perfect
job optimising for the SPEC benchmark.  That is why everybody publishing
results for x86 (or IA64) uses the Intel compiler, and not any other.

gcc on the other hand has always even been at least 20% behind code
generated by CodeWarrior for the PowerPC (as well as Power) platform.  In
fact, Apple is constantly working to improve gcc code generated for PowerPC
for exactly this problem.  Another problem is that gcc is one of the slowest
compilers available - CodeWarrior will easily run ten or 20 times faster
compiling the exact same source code (and still generate faster code).

> Apple is releasing a G5-optimizing version of GCC as part of the free
> devtools upgrade (XCode I think it's called).  I don't know how good their
> optimizations are, but they are there.

Apple cannot fix some inherent problems with certain high-level
optimisations in gcc.  It cannot really fix the speed problems the compiler
has itself (only hide them a bit by adding support for precompiled headers,
as they did recently).  In particular, gcc does tend to have a serious
problem with its loop-optimiser being ten years behind even the published
methods for optimising loops (this is something supposedly being addressed
in gcc 3.4 or 3.5).  All Apple can do is to add good instruction scheduling.
However, there is still no DFA scheduler for PowerPC processors yet, which
did some boost of performance of x86 code generated by gcc.

So, in some sense, Apple did use a fair comparison.  However, given that
they don't have any better compiler for Macs, that is indeed their problem.
And a processor as complex as the Power4 or PowerPC 970 simply needs a damn
good compiler.  Intel has really proven that the compiler makes all the
difference when they addressed performance problems of the Pentium 4 due to
its extremely long pipeline (which helps it to rise clock rates though).

    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 <3ef88efe$1@news.povray.org>,
 "Ray Gardener" <ray### [at] daylongraphicscom> wrote:

> Yeah, I notice that POV uses lots of pointers
> inside scene object structures. I'm wondering of some
> of them can be collapsed to bitmask flags with a
> pointer tacked onto the object only if its associated
> bit flag is on.

Ugh...

Yes, I suppose you *could* do this. It depends on whether you value 
processor or memory more. It would add overhead to check all those 
flags, as well as code complexity making the program harder to maintain 
and extend, and increasing worst-case memory consumption, all for very 
little benefit. Memory usage could be improved in places, and data 
structures shifted around for more efficient general use, but I don't 
think this idea will be useful for anything but than the most 
memory-hungry structures.

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

In article <web.3ef882511b6e269c7f877a1c0@news.povray.org>,
 "hamburg" <ham### [at] fasharvardedu> wrote:

> Yeah.  Although if you read the fine print in the veritest pdf, it becomes
> clear that they rather lied about some of that.  Used lousy compilers for
> the competition, disabled their hyperthreading, etc.  Used a fast but
> memory-inefficient malloc library for their own tests.  Used compiler flags
> that aren't useful in realworld apps.  If you compare to, say, Dell's
> benchmarks of their own systems (which are probably similarly deceptive),
> Apple's are competitive but not the best.

They used the same compiler on both, GCC 3.3, a compiler that actually 
has a reputation for optimizing much better for x86 based architectures. 
They didn't weight the tests as highly in Intel's favor as they could 
have, that certainly doesn't mean they were deceptive. And they did not 
"lie", they said exactly what they did. For most people running a Linux 
or Unix system on the PC and Mac OS X on the Mac, these results are very 
close to what they will see.


> Also remember that POV is single threaded, so you won't benefit from
> multiple processors.  It is very difficult to multithread an application
> like POV, so it's unlikely to happen soon.  There existed a multithreaded
> version out there somewhere, but AFAIK it's not up-to-date (Thorsten would
> know).

You're a little off here...POV would benefit a little, since it could 
have an entire processor to itself, and system would have plenty left 
over for user interaction or other tasks. And if you're working on an 
animation or running multiple renders, having each instance of POV 
restricted to a single processor is much less of a problem..


> Enough of the bad news... It's possible that the Altivec SIMD unit does make
> the G5 the fastest desktop for some applications (Photoshop, codebreaking,
> FFT).  IIRC the G4-optimized version of POV uses Altivec, which would help
> in the G5 code too. 

Altivec could help with color calculations and some shape stuff. It 
would take some modifications to POV to get maximum benefit from it, but 
it could still help.


> And render speeds would benefit immensely from the
> increased memory bandwidth in the G5.

Yes...I'm guessing things like high-res meshes, photon mapping, and 
radiosity probably stress memory bandwidth pretty heavily.

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

> Yes, I suppose you *could* do this. It depends on whether you value 
> processor or memory more. It would add overhead to check all those 
> flags, as well as code complexity making the program harder to maintain 
> and extend, and increasing worst-case memory consumption, all for very 
> little benefit. Memory usage could be improved in places, and data 
> structures shifted around for more efficient general use, but I don't 
> think this idea will be useful for anything but than the most 
> memory-hungry structures.

I have often run out of memory (I tend to make overly detailed scenes)
but am unlikely to run out of patience just by a factor of 2. Plus, I
do not assume the factor in runtime to be that high. What portion of
the runtime is due to pointer reference anyway?

So, I would be happy for any option (I agree it should not be the
default) that trades memory usage for time usage in a reasonable way.


-- 
merge{#local i=-11;#while(i<11)#local
i=i+.1;sphere{<i*(i*i*(.05-i*i*(4e-7*i*i+3e-4))-3)10*sin(i)30>.5}#end
pigment{rgbt 1}interior{media{emission x}}hollow}//  Mark Weyer

Post a reply to this message

"Thorsten Froehlich" <tho### [at] trfde> wrote in
news:3ef7f070$1@news.povray.org: 

> In article <3ef7eaf1$1@news.povray.org> , "Ray Gardener" 
> <ray### [at] daylongraphicscom> wrote:
> 
>> I was wondering if anyone had or is planning
>> to collect MacPOV benchmarks on the new PowerMac G5.
>> Apparently the floating-point performance is exceptional.
> 
> The systems ship in August, and that doesn't mean the compilers used
> to benchmark it are available on Macs.  To be precise, to benchmark
> its Power processors (and the PowerPC 970 processor is just a stripped
> down Power4 with a SIMD extension), IBM always uses IBM C for AIX, and
> IBM VisualAge C++ Professional for AIX, benchmarking on, well AIX as
> you can for example see on the SPEC results page:
> <http://www.spec.org/cpu2000/results/res2002q4/cpu2000-20021111-01822.h
> tml> 


I have a GCC and a Xlc compile for AIX and there is hardly any difference 
at all in the POV times. If I remember correctly the skyvase scene took 
about 30 minutes on one of the machines I tried on about 2 years ago. The 
64 bit compile of 3.1 took just a bit longer (just a minute or two)

I have never really tried to run 3.5 on AIX nor have I tried to run 64 
bit code for a long time since the radiosity is broken on 64 bit 
compiles. :(

I haven't really tried to use a Power 4 or a Power 4+ machine yet, 
although we have several of them. But they are very fast indeed, 
unpacking a compressed file goes very quickly indeed.

Thomas

Post a reply to this message