 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Thomas van der Veen <tho### [at] gmx net> 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
|
|
| |
| |
|
|
|
|
| |
