 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
>> It can't be fixed, the GUI eats that much.
>
> If that was true, then *all* GUI'ed OSes would eat 10-15% of CPU time
> with POV-Ray. Obviously this is not the case.
> I don't understand what do you mean by "it can't be fixed".
It is the way Mac OS X is. Now, look, I don't care if you don't understand
it, or to get you understand it. It is just a fact, period. If you don't
believe me, get yourself a Mac and test yourself.
Thorsten
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Thanks Thorsten. He said it is a powerbook not an ibook. Yes, it's os x.
All settings were fully throttled, no battery-saving. Apparently the
fastest time he got on the mac was about 24 mins with the display off.
The athlon time was actually 5:05. The p3 times were display-on. Doing a
quick/unofficial 160x120 no AA render of benchmark.pov showed more expected
results with the 2ghz athhlon finishing about twice as fast as the 1ghz p3.
(~2:40 vs. ~5:45) He started the g4 on the same, but I didn't wait to hear
back about the time.
Charles
Thorsten Froehlich <tho### [at] trf de> wrote:
> That applies only to a desktop system, and if you have it in a notebook most
> likely power saving was enabled (it is by default, cuts clock by half), plus
> if it was in an iBook rather than a PowerBook, memory will have been slower.
> Plus, if it was running on Mac OS X rather than Mac OS 9, you lost another
> 10%-15% right there. Plus, if you did it with display enabled, that would
> again change results, especially on Mac OS X that simply is slower due to
> the double-buffered windows forced on applications (it especially hurts if
> you have less than 32 MB of graphics card RAM).
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Thorsten Froehlich <tho### [at] trfde> wrote:
> Warp wrote:
> >> It can't be fixed, the GUI eats that much.
> >
> > If that was true, then *all* GUI'ed OSes would eat 10-15% of CPU time
> > with POV-Ray. Obviously this is not the case.
> > I don't understand what do you mean by "it can't be fixed".
> It is the way Mac OS X is. Now, look, I don't care if you don't understand
> it, or to get you understand it. It is just a fact, period. If you don't
> believe me, get yourself a Mac and test yourself.
Beats me how I could test for myself if such slowdown can be fixed or
not, regardless of how many macs I have.
Apparently you know the internal workings of MacOS X so well that you
know that it cannot be fixed? How? Do you have access to the source code
or developement documentation or something? I would just be interested
in knowing what is it that makes it impossible to fix.
(Ah, but now that I think about this conversation a bit, I think there's
a confusion. When I said "Didn't they fix it?" I meant "Didn't Apple fix
MacOS X so that the newer versions are not as slow as the older ones?".
I think you thought I meant "can't POV-Ray for Mac be fixed to work
faster?")
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> I would just be interested
> in knowing what is it that makes it impossible to fix.
Apple has plenty of mailing lists discussing this topic ad infinitum. Their
archives are available online, Google will tell you where on the Apple
website to find them. This group is not the place to discuss it.
Thorsten
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
One way to confirm this is to compile the unix version on Mac OS X. Then
compare the rendering time against the Mac OS X version that's provided on
the download page.
-John
Warp <war### [at] tagpovrayorg> wrote:
>
> Beats me how I could test for myself if such slowdown can be fixed or
> not, regardless of how many macs I have.
>
> Apparently you know the internal workings of MacOS X so well that you
> know that it cannot be fixed? How? Do you have access to the source code
> or developement documentation or something? I would just be interested
> in knowing what is it that makes it impossible to fix.
>
> (Ah, but now that I think about this conversation a bit, I think there's
> a confusion. When I said "Didn't they fix it?" I meant "Didn't Apple fix
> MacOS X so that the newer versions are not as slow as the older ones?".
> I think you thought I meant "can't POV-Ray for Mac be fixed to work
> faster?")
>
> --
> - Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
jhu wrote:
> One way to confirm this is to compile the unix version on Mac OS X. Then
> compare the rendering time against the Mac OS X version that's provided on
> the download page.
Which will give you a result meaning exactly nothing: You would be using an
inferior compiler and library, and also not have some Mac specific
optimizations like the function JIT compiler.
Thorsten
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
I wouldn't say that for all cases. Here are the results for my PPC 750
machine running Mac OS X 10.4.8:
Official Mac PPC binary:
Parse Time: 0 hours 0 minutes 13 seconds (13 seconds)
Photon Time: 0 hours 4 minutes 30 seconds (270 seconds)
Render Time: 4 hours 31 minutes 10 seconds (16270 seconds)
Total Time: 4 hours 35 minutes 53 seconds (16553 seconds)
Custom compile with GCC 4.0.1 - compiler flags: -pipe -Wno-multichar -O3
-mpowerpc -mcpu=750 -mtune=750 -mmultiple -mstring -mfused-madd
Parse Time: 0 hours 0 minutes 11 seconds (11 seconds)
Photon Time: 0 hours 4 minutes 50 seconds (290 seconds)
Render Time: 4 hours 19 minutes 57 seconds (15597 seconds)
Total Time: 4 hours 24 minutes 58 seconds (15898 seconds)
Thorsten Froehlich <tho### [at] trfde> wrote:
> jhu wrote:
> > One way to confirm this is to compile the unix version on Mac OS X. Then
> > compare the rendering time against the Mac OS X version that's provided on
> > the download page.
>
> Which will give you a result meaning exactly nothing: You would be using an
> inferior compiler and library, and also not have some Mac specific
> optimizations like the function JIT compiler.
>
> Thorsten
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
jhu wrote:
> I wouldn't say that for all cases. Here are the results for my PPC 750
> machine running Mac OS X 10.4.8:
> Total Time: 4 hours 35 minutes 53 seconds (16553 seconds)
> Total Time: 4 hours 24 minutes 58 seconds (15898 seconds)
You measured an incredible 4% difference with one scene, with an unknown
configuration of POV-Ray. So what?
Thorsten
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Your implication is that GCC is inferior to what I'm guessing is Code
Warrior, which is not always the case. While 4% is not a significant
improvement, I've run these several times in the past and have gotten
consistent results.
Also, the measurements were for the benchmark scene using the supplied .ini
files
-John
Thorsten Froehlich <tho### [at] trfde> wrote:
> jhu wrote:
> > I wouldn't say that for all cases. Here are the results for my PPC 750
> > machine running Mac OS X 10.4.8:
> > Total Time: 4 hours 35 minutes 53 seconds (16553 seconds)
> > Total Time: 4 hours 24 minutes 58 seconds (15898 seconds)
>
> You measured an incredible 4% difference with one scene, with an unknown
> configuration of POV-Ray. So what?
>
> Thorsten
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
jhu wrote:
> Your implication is that GCC is inferior to what I'm guessing is Code
> Warrior, which is not always the case.
What do you expect when you compare a multi-threaded GUI program to a
single-threaded terminal application? A terminal application compiled with
CodeWarrior will absolutely be faster, but after all, that was my point from
the beginning: The Mac OS X GUI eats away the processing power very
effectively. Naturally more so when you actually have a GUI application that
has to update status displays while rendering. The rendering for the GUI
application also has to run in a different thread. Of course, (by default)
both get the same time slice, just that the GUI version is burdened running
several GUI-related threads in the same time slice, while the terminal
application runs only one thread.
Thorsten
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
