POV-Ray : Newsgroups : povray.general : PowerMac G5 implications Server Time: 22 Oct 2017 21:01:37 GMT
  PowerMac G5 implications (Message 11 to 20 of 21)  
<<< Previous 10 Messages Goto Latest 10 Messages Next 1 Messages >>>
From: Christoph Hormann
Subject: Re: PowerMac G5 implications
Date: 25 Jun 2003 12:05:30
Message: <3EF99009.16D61EB0@gmx.de>
Thomas van der Veen wrote:
> 
> [...]
> 
> 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)

That does not sound very believable, i doubt there ever was a 64bit
machine where skyvase takes 30 minutes.  On my old K6/500 it takes less
than 3 minutes.

Christoph

-- 
POV-Ray tutorials, include files, Sim-POV,
HCR-Edit and more: http://www.tu-bs.de/~y0013390/
Last updated 17 Jun. 2003 _____./\/^>_*_<^\/\.______


Post a reply to this message

From: Warp
Subject: Re: PowerMac G5 implications
Date: 25 Jun 2003 12:10:59
Message: <3ef99153@news.povray.org>
Thomas van der Veen <tho### [at] gmxnet> wrote:
> 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. :(

  Which by the way is fixed in 3.51...

-- 
#macro M(A,N,D,L)plane{-z,-9pigment{mandel L*9translate N color_map{[0rgb x]
[1rgb 9]}scale<D,D*3D>*1e3}rotate y*A*8}#end M(-3<1.206434.28623>70,7)M(
-1<.7438.1795>1,20)M(1<.77595.13699>30,20)M(3<.75923.07145>80,99)// - Warp -


Post a reply to this message

From: Thorsten Froehlich
Subject: Re: PowerMac G5 implications
Date: 25 Jun 2003 16:05:35
Message: <3ef9c84f@news.povray.org>
In article <3EF99009.16D61EB0@gmx.de> , Christoph Hormann 
<chr### [at] gmxde>  wrote:

> That does not sound very believable, i doubt there ever was a 64bit
> machine where skyvase takes 30 minutes.  On my old K6/500 it takes less
> than 3 minutes.

With gcc on non-x86 targets, you would be surprised...

The current release (improved) gcc 3.1 Apple ships with Mac OS X 10.2 is
still about 50% behind the Mac GUI version (which uses CodeWarrior).  And
the 3.3 they used for the latest test is not much better....

Anybody using gcc to benchmark a Mac (or any system for that matter) with
anything must be insane.  However, as Steve Jobs apparently wants everything
under his control, in particular the development tools, they apparently
didn't even bother to ask Metrowerks to provide a prerelease 64 bit version
of the PowerPC backend of CodeWarrior (it targets a few 64 bit embedded
targets with the same frontend already).

Fact is, IBM announced much better SPEC base 2000 results for the 1.7 GHz
version last year, and those were probably based on the same compiler they
use for the Power4.

Sadly on mac OS X Apple effectively closed to road to use AIX executables
because Appole switched to the Mach kernel ABI, which is terribly
inefficient mostly because it also contains some garbage Next added to
support Objective C <sigh>

    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: Ray Gardener
Subject: Memory efficiency
Date: 25 Jun 2003 18:50:59
Message: <3ef9ef13@news.povray.org>
> 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.

Just having that choice available would be nice, yeah.

I was thinking of a general memory saving algorithm that
might apply to some of the structures POV-Ray creates,
but it's utility stems from being broadly applicable
to apps that dynamically create arbitrary objects that
would save memory if they could be shared. The p-code is:

while parsing the input file
    parse the object
    parse its attributes
    create the attribute structures
    for each attribute type
        do a bsearch into the related attribute struct list
        if the struct already exists
            have the object point to the existing copy
        else
            insert the struct to the list to keep it sorted
        endif
    next
wend

If we treat the contents of an attribute struct as
just a big number, then we can easily qsort on them.

One example is the Object->Trans member. It's not a
good example, because POV-Ray already shares this
struct when it can. But the above code would let
you declare objects any way you wanted, and any
identical Trans structures would automatically
collapse down to a single instance. If we knew ahead
of time (from a previous parsing pass) that the
number of such truly unique instances was below
2^32, then we could use 32-bit handles instead
of 64-bit pointers (or maybe even 24- or 16-bit handles).
Handles are easy because we refactor the list to
occupy a linear memory block and then the mapping
of handle to pointer is just an array index.

Scripters already do this manually, by declaring
shared objects/attributes explicitly. The above
would be more for people who wanted to not bother,
and let the computer figure it out. Ideally, what
would be nice is if the computer would not only
do that, but then emit the script that the user
should have written ("oh, you've redundantly
duped these items. Here, let me make the #declare
statements and organize the script better for you...")

Ray


Post a reply to this message

From: Thorsten Froehlich
Subject: Re: Memory efficiency
Date: 25 Jun 2003 20:25:32
Message: <3efa053c@news.povray.org>
In article <3ef9ef13@news.povray.org> , "Ray Gardener" 
<ray### [at] daylongraphicscom> wrote:

> I was thinking of a general memory saving algorithm that
> might apply to some of the structures POV-Ray creates,
> but it's utility stems from being broadly applicable
> to apps that dynamically create arbitrary objects that
> would save memory if they could be shared. The p-code is:

Currently the basically same algorithm this is used for function constants.

    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: Thomas van der Veen
Subject: Re: PowerMac G5 implications
Date: 26 Jun 2003 12:30:01
Message: <Xns93A689423331Eveentukibmcom@204.213.191.226>
Christoph Hormann <chr### [at] gmxde> wrote in
news:3EF99009.16D61EB0@gmx.de: 

> 
> 
> Thomas van der Veen wrote:
>> 
>> [...]
>> 
>> 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) 
> 
> That does not sound very believable, i doubt there ever was a 64bit
> machine where skyvase takes 30 minutes.  On my old K6/500 it takes
> less than 3 minutes.
> 
> Christoph


I posted the result to www.tabsnet.com, just search the AIX results. 28 
minutes and 10 seconds..... That is doing the chess2.pov. And that result 
is probably with the 32 bit compile and as I said the 64 bit compile is a 
bit slower. The processors on that machine are running at 375Mhz and I 
only used one of them, maybe it can go a bit faster if I make sure that 
only one of them is used (this will make sure that pov code and data will 
only be in one of the caches), but I'm not quite sure how to do that.

I can try and run it on one of the Power4(+) machines we have here, they 
are a lot faster.

Thomas


Post a reply to this message

From: William Pokorny
Subject: Re: PowerMac G5 implications
Date: 26 Jun 2003 13:05:01
Message: <web.3efaeeb81b6e269cb0bd6d4b0@news.povray.org>
Thomas, I played with the chess2.pov benchmark a couple years ago on the
same 375mhz processor. With simple optimizations I saw about the
performance you saw. I was able to get it down to about 21 minutes using a
bunch of optimizations, but never really understood why the performance was
so much slower than comparable powerPC processors in Macs...
Bill P.
>
>
>I posted the result to www.tabsnet.com, just search the AIX results. 28
>minutes and 10 seconds..... That is doing the chess2.pov. And that result
>is probably with the 32 bit compile and as I said the 64 bit compile is a
>bit slower. The processors on that machine are running at 375Mhz and I
>only used one of them, maybe it can go a bit faster if I make sure that
>only one of them is used (this will make sure that pov code and data will
>only be in one of the caches), but I'm not quite sure how to do that.
>
>I can try and run it on one of the Power4(+) machines we have here, they
>are a lot faster.
>
>Thomas
>


Post a reply to this message

From: Christopher James Huff
Subject: Re: PowerMac G5 implications
Date: 26 Jun 2003 14:21:25
Message: <cjameshuff-BAB027.09095526062003@netplex.aussie.org>
In article <3EF### [at] informatikuni-freiburgde>,
 Mark Weyer <wey### [at] informatikuni-freiburgde> wrote:

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

Remember I mentioned it would make the code more complex? Making it 
optional won't help, it makes the problem more than twice as bad. I 
think there are better ways to solve the problem.

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

From: Thomas van der Veen
Subject: Re: PowerMac G5 implications
Date: 26 Jun 2003 14:43:44
Message: <Xns93A69FED872F0veentukibmcom@204.213.191.226>
"William Pokorny" <pokorny_attglobal_net> wrote in
news:web.3efaeeb81b6e269cb0bd6d4b0@news.povray.org: 

> Thomas, I played with the chess2.pov benchmark a couple years ago on
> the same 375mhz processor. With simple optimizations I saw about the
> performance you saw. I was able to get it down to about 21 minutes
> using a bunch of optimizations, but never really understood why the
> performance was so much slower than comparable powerPC processors in
> Macs... Bill P.

I didn't try the most agressive optimisation options. I guess I couldn't be 
bothered to try all the different options and see hat kind of difference 
they would make.

Have you tried a Power4(+) yet?

Thomas

ps. I made a mistake earlier when I said that I tried the skyvase 
benchmark.


Post a reply to this message

From: Xplo Eristotle
Subject: Re: PowerMac G5 implications
Date: 1 Jul 2003 06:59:46
Message: <3f013162@news.povray.org>
hamburg 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.

Have you been reading that haxial page? Tsk.

They used GCC for both machines. Granted, this isn't technically "the 
same compiler" as the backend will differ across platforms, but given 
that it's been optimized for Intel processors and that it sees use in 
the real world, I hardly think they "crippled" the PC.

Hyperthreading was turned off because it actually reduced the PC's SPEC 
scores. Another common complaint, which is that SSE2 was disabled, was 
false; it was in fact enabled.

The malloc library was one which would only work with single-threaded 
apps.. but as SPEC was such an app, it seems logical to use it. The 
hardware tweaks they made to the Mac were done to disable one processor 
(since it wouldn't be used anyway) and to reflect how the machines would 
perform when shipped. Or so Apple claims, anyway.

I don't know how Apple LIED about the scores, given that all the details 
are freely available to the public in Veritest's report. The most you 
could really say is that they spun the results.. and everyone does that.

> Also remember that POV is single threaded, so you won't benefit from
> multiple processors.

POV itself won't see much benefit, but being able to use your machine 
almost like normal while a render runs full steam in the background is 
nice. Try it sometime.

FWIW, I think the memory bandwidth and the good FP performance should 
make the G5 a good POV-Ray machine for the price.. although if that's 
all you want it for, you could almost certainly build a bare-bones speed 
demon PC for cheaper.

-Xplo


Post a reply to this message

<<< Previous 10 Messages Goto Latest 10 Messages Next 1 Messages >>>

Copyright 2003-2008 Persistence of Vision Raytracer Pty. Ltd.