 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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] daylongraphics com> 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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> 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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Tue, 01 Jul 2003 11:07:02 -0500, Christopher James Huff
<cja### [at] earthlinknet> wrote:
> From: Christopher James Huff <cja### [at] earthlinknet>
> Newsgroups: povray.general,povray.off-topic
> Subject: Re: PowerMac G5 implications
I noticed that this kind of message will be removed from server just like
message completly targeted to off-topic group. Could it be possible to leaving
messages where off-topic is only one of targets ? It is not especially important
in this thread probably but I had a case when thread started to be on-topic and
moved to other group, but off-topic leaved for marking continuation caused
further removal of somehow useful post.
ABX
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
