Does PPC suck or has Apple crippled Cocoa ?
-
First: I half suspect I am doing something very wrong in the application or
in the profiling. If I am totally screwed up, I will happily post a
retraction. I will be so glad to have my problem solved that I won't mind
egg on my face.
Does PPC suck or has Apple crippled Cocoa ?
I have a large Openstep application that generates frames of graphical
animation at a reliable 20 Hz on a 266 Mhz Pentium II machine running
Openstep 4.2 with 64Mb and a 5 year old graphics card. The same application
when ported to a 450 Mhz G4 cube running with 384Mb OS X can not reliably
maintain 10 Hz. The application does not touch the disk while rendering so
disk I/O is not a factor.
I assumed something in the display routines needed different optimization
given the changes needed to port to Quartz. I disabled all drawing to find
out if the application could maintain 20 Hz even if it was drawing nothing.
Much to my horror, the application only picked up about 2 Hz.
I have profiled the code to a limited extent. (The tools don't work right
on OS-X) Most of the application code in the OS X version uses about half
the percentage time that it used under Openstep. For example,
if -evaluateScalarExpression: used 8% of the time on Openstep, it used 4% on
OS X. The Foundation Kit classes use 3-4 times the percentage that they
used under Openstep. In other words, if objectAtIndex: was consuming 4% of
the time in Openstep, it is consuming 12-16% under Mac OS X. (I know the
figures don't add up. That is what I mean when I say the tools don't work
right.)
Using percentage of run-time tells us the Apple Foundation code is much less
efficient than it was under Openstep.
The even worse news is that the new code is slower in absolute time also.
According to propaganda, the PPC at 450 Mhz should be 3-4 times faster than
a 266 Mhz Pentium II. In fact, most of the application code (Not Apple's
code)
executes in approximately the same number of milliseconds on both machines.
The machines are apparently comparable in hardware performance. The OS X
Foundation libraries are much slower than the Openstep versions. OS X may
me adding overhead that Openstep did not add. All together, I would say
Apple has made a huge step backward.
So, is the problem PPC ? Is it OS X ? Is it both ?
Also, all tests were performed with as few processes running as possible and
no classic environment on the OS X machine.
P.S. I don't trust the profiling on OS X and I would not believe its numbers
if the stopwatch did not basically corroborate them. We have some timer
code in our application. At various interesting stages in the animation
process, time stamps are written into a data structure in RAM. At the end
of a render session, the data structure is analyzed and a report is
generated to indicate how many milliseconds where used cumulatively in each
phase of render. On the Openstep 4.2 version, all phases combined use about
41 ms/frame leaving a bit of slack to keep the 20 Hz requirement. On OS-X,
the phase that moves lots of data around in memory takes 40ms/frame all by
itself! Does memcpy() suck on OS-X ? -
On Thursday, July 12, 2001, at 08:36 PM, Erik M. Buck wrote:
> I assumed something in the display routines needed different
> optimization
> given the changes needed to port to Quartz. I disabled all drawing to
> find
> out if the application could maintain 20 Hz even if it was drawing
> nothing.
> Much to my horror, the application only picked up about 2 Hz.
>
> I have profiled the code to a limited extent. (The tools don't work
> right
> on OS-X)
What do you mean? If you aren't using the supplied tools, how are you
profiling?
> Using percentage of run-time tells us the Apple Foundation code is much
> less
> efficient than it was under Openstep.
Are you sure your profiling method is accurate?
> P.S. I don't trust the profiling on OS X and I would not believe its
> numbers
> if the stopwatch did not basically corroborate them.
Profiling has nothing to do with wall clock time. It's measuring time
spent on the CPU on behalf of the process. If you have a test case that
shows profiling to be broken, I'd like to see it.
> On OS-X,
> the phase that moves lots of data around in memory takes 40ms/frame all
> by
> itself! Does memcpy() suck on OS-X ?
I think not. memcpy() is a highly tuned assembly routine which, on large
operands, is memory-bus-speed bound.
Why not whip up a little memcpy() test and see for yourself?
matt. -
No, you're not nuts, you are right: OS X does suck. Even with the
fantastic processing power of the G4, the promises we have been
hearing for years about how fast an all-native PPC OS would be have
turned out to be lies. Actually that's not quite true - the G4 is an
impressive processor - it's just that the 12-year old "modern"
NeXT-technology behind OS X is so inefficient that even the G4 cannot
overcome it. Classic MacOS is much faster, even with all that
emulated 68K code running! Steve has sold Apple and the world a bill
of goods and you are just one of the few who has woken up and
realized it - the masses have not - yet.
-m
-------------------------------------------------
At 10:36 PM -0500 7/12/01, Erik M. Buck wrote:
> First: I half suspect I am doing something very wrong in the application or
> in the profiling. If I am totally screwed up, I will happily post a
> retraction. I will be so glad to have my problem solved that I won't mind
> egg on my face.
>
>
> Does PPC suck or has Apple crippled Cocoa ?
>
> I have a large Openstep application that generates frames of graphical
> animation at a reliable 20 Hz on a 266 Mhz Pentium II machine running
> Openstep 4.2 with 64Mb and a 5 year old graphics card. The same application
> when ported to a 450 Mhz G4 cube running with 384Mb OS X can not reliably
> maintain 10 Hz. The application does not touch the disk while rendering so
> disk I/O is not a factor.
>
> I assumed something in the display routines needed different optimization
> given the changes needed to port to Quartz. I disabled all drawing to find
> out if the application could maintain 20 Hz even if it was drawing nothing.
> Much to my horror, the application only picked up about 2 Hz.
>
> I have profiled the code to a limited extent. (The tools don't work right
> on OS-X) Most of the application code in the OS X version uses about half
> the percentage time that it used under Openstep. For example,
> if -evaluateScalarExpression: used 8% of the time on Openstep, it used 4% on
> OS X. The Foundation Kit classes use 3-4 times the percentage that they
> used under Openstep. In other words, if objectAtIndex: was consuming 4% of
> the time in Openstep, it is consuming 12-16% under Mac OS X. (I know the
> figures don't add up. That is what I mean when I say the tools don't work
> right.)
>
> Using percentage of run-time tells us the Apple Foundation code is much less
> efficient than it was under Openstep.
>
> The even worse news is that the new code is slower in absolute time also.
> According to propaganda, the PPC at 450 Mhz should be 3-4 times faster than
> a 266 Mhz Pentium II. In fact, most of the application code (Not Apple's
> code)
> executes in approximately the same number of milliseconds on both machines.
> The machines are apparently comparable in hardware performance. The OS X
> Foundation libraries are much slower than the Openstep versions. OS X may
> me adding overhead that Openstep did not add. All together, I would say
> Apple has made a huge step backward.
>
> So, is the problem PPC ? Is it OS X ? Is it both ?
>
> Also, all tests were performed with as few processes running as possible and
> no classic environment on the OS X machine.
>
> P.S. I don't trust the profiling on OS X and I would not believe its numbers
> if the stopwatch did not basically corroborate them. We have some timer
> code in our application. At various interesting stages in the animation
> process, time stamps are written into a data structure in RAM. At the end
> of a render session, the data structure is analyzed and a report is
> generated to indicate how many milliseconds where used cumulatively in each
> phase of render. On the Openstep 4.2 version, all phases combined use about
> 41 ms/frame leaving a bit of slack to keep the 20 Hz requirement. On OS-X,
> the phase that moves lots of data around in memory takes 40ms/frame all by
> itself! Does memcpy() suck on OS-X ?
>
>
>
>
> _______________________________________________
> MacOSX-dev mailing list
> <MacOSX-dev...>
> http://www.omnigroup.com/mailman/listinfo/macosx-dev
-
That's a troll ;-)
Le Friday 13 July 2001, à 08:15, Mike a écrit :
> No, you're not nuts, you are right: OS X does suck. Even with the
> fantastic processing power of the G4, the promises we have been hearing
> for years about how fast an all-native PPC OS would be have turned out
> to be lies. Actually that's not quite true - the G4 is an impressive
> processor - it's just that the 12-year old "modern" NeXT-technology
> behind OS X is so inefficient that even the G4 cannot overcome it.
> Classic MacOS is much faster, even with all that emulated 68K code
> running! Steve has sold Apple and the world a bill of goods and you are
> just one of the few who has woken up and realized it - the masses have
> not - yet.
Gerard -
> That's a troll ;-)
...absolute flamebait...
What's the big deal? It's not any slower than OS 9 on my iMac DV 400/128MB
RAM...
Anyhow.
How about colour? There was something posted by...I think it was one of
the Omni Group folks...about colour modes. XRGB and RGBX and other things.
One was significantly faster, or something...is there any chance of a
repost/web page with that info?
-- Rob
[email appendRandomWittySig]; -
I was wondering the same thing. I just heard that XRGB is a valid
format.
Given that, it's pretty clear that CoreGraphics has to have chosen one
or the other for the "native" format and has to do a rotate left 8 (or
24 depending...) on every pixel to convert from the other...
Is there a way to tell NSBitmapImageRep that your data is in XRGB?
There's references in CGImage.h to this, but I'm not sure how to get
from a CGImage to an NSImage...
On Friday, July 13, 2001, at 12:15 AM, Rob Rix wrote:
> How about colour? There was something posted by...I think it was one of
> the Omni Group folks...about colour modes. XRGB and RGBX and other
> things.
> One was significantly faster, or something...is there any chance of a
> repost/web page with that info?
>
> -- Rob
-
On vendredi, juillet 13, 2001, at 10:37 AM, Tom Waters wrote:
> I was wondering the same thing. I just heard that XRGB is a valid
> format.
>
> Given that, it's pretty clear that CoreGraphics has to have chosen one
> or the other for the "native" format and has to do a rotate left 8 (or
> 24 depending...) on every pixel to convert from the other...
>
> Is there a way to tell NSBitmapImageRep that your data is in XRGB?
>
> There's references in CGImage.h to this, but I'm not sure how to get
> from a CGImage to an NSImage...
It's a semi Urban Legend:
- NSBitmapImageRep default setting in RGB + Alpha is as fast as the best
CGImage set.
- the kCGImageAlphaNoneSkipFirst is the fastest format according to Tim
Wood.
--------------------------
imageRep_ = [[NSBitmapImageRep alloc] initWithBitmapDataPlanes:NULL
pixelsWide:
realWidth_
pixelsHigh:
imageRect_.size.height
bitsPerSample:8
samplesPerPixel:4
hasAlpha:YES
isPlanar:NO
colorSpaceName:NSDeviceRGBColorSpace
bytesPerRow:0
bitsPerPixel:0
];
is as faus as:
imageRef_ = CGImageCreate(realWidth_,
tRect.size.height,
8,
32,
realWidth_*4,
colorSpaceRef_,
kCGImageAlphaNoneSkipFirst,
dataProviderRef_,
NULL,
false,
kCGRenderingIntentDefault);
More over the problem is not with Graphics as he said.
The problem can come from the slow Math lib for instance. Any news on
this topic ? -
Am Freitag, 13. Juli 2001 um 09:15 schrieb Rob Rix:
>> That's a troll ;-)
>
> ...absolute flamebait...
>
> What's the big deal? It's not any slower than OS 9 on my iMac DV
> 400/128MB RAM...
It seems, you're in luck.
On my 7600, Graphics are very slow and memory consuming. Currently,
observations with "top" show, that a blinking default button eats about
30% of the processor cycles. Even when considering the slow 132MHz CPU,
this is far more than needed. A similar animated GIF on OS 9 performs
lots better.
But it gets better from release to release. In Public Beta, such a
button used more than 50% performance. Lately, the 10.0.4 update brought
noticeable enhancement.
Some years ago I gave OS X Server 1.0.2 a try on this box. This one was
really nearly as fast as OS 8.1. So I'd guess Display PDF is one of the
main culprits as it was developed in a short time frame. It's probably
just not yet finished from a performance point of view.
Let's see what the next update gives. But even now OS X is so much more
powerful in functionality that I can live quite well with it's currently
poor graphics performance.
Cheers,
Markus
- - - - - - - - - - - - - - - - - - -
Dipl. Ing. Markus Hitter
http://www.jump-ing.de/ -
This does not change more than 10% if the processor speed is
increased. On my G4/450, a throbbing button in my application boosts
its cpu usage from .6% to 17%.
I STRONGLY urge developers to disable controls when the windows are
in the background, especially the throbbing buttons, because of this
CPU suckage.
I am aware most developers do this, but some Carbon developers do not.
Ack, at 7/13/01, Markus Hitter said:
> On my 7600, Graphics are very slow and memory consuming. Currently,--
> observations with "top" show, that a blinking default button eats
> about 30% of the processor cycles.
Sincerely,
Rosyna Keller
Technical Support/Holy Knight/Always needs a hug
Unsanity: Unsane Tools for Insane People -
> On my 7600, Graphics are very slow and memory consuming. Currently,
> observations with "top" show, that a blinking default button eats about
> 30% of the processor cycles. Even when considering the slow 132MHz CPU,
> this is far more than needed. A similar animated GIF on OS 9 performs
> lots better.
The processor cycles eaten by the default button aside, the first three
words are your answer; the lowest spec'ed machine Apple intends this to be
run on is a 233 Mhz G3 iMac/PowerBook. A 604e at 132 Mhz is _considerably_
lower-end.
Anyhow, it'll all get worked out sooner or later (hopefully sooner, for
everybody who's been having problems).
-- Rob
Murphy strikes again! -
For me it seems to be really slow starting up applications, Im not sure
but seems like Disk i/o is really slow, or perhaps the size of these
applications or the memory they are taking up is really large.
Also, what seems really slow is when you switch between running
apps. If I have say OmniWeb running and the mail program, and
perhaps one other application running (especially a Classic App).
It becomes very slow switching between applications. Im running
a Ruby iMac (whatever speed CPU that is) with 256 or so megs of
ram. Also I have found swithing between say OmniWeb and opening
a folder from the finder to be slow. The switch takes 3-4 whole
seconds to just open the folder and show the contents.
I remember running OpenStep on a 100mhz Intel box and it seemed
from a users point of view as fast as this, or perhaps faster.
So OS X has certainly gotten even more bloated from its OpenStep days.
To be honest,I do remember OpenStep not having the most robust multitasking.
I remember graphics slowing down, and stuttering when more than
one application was running. Compared to OS/2 on the same machine, for
example, the
multitasking in OpenStep seemed really "jumpy". This may have to do
with the amount of memory in that old Pentium box (only 32 megs of ram),
and OpenStep needing far more memory than OS/2 (hard to believe after
OS/2 was accused of being a memory pig for so long).
Now, as far as running applications in the background OS X seems OK. I
can compile in the background (even using Classic Metrowerks),and
say surf the web at the same time and all seems reasonable. It just
gets REALLY slow when I try to switch away from the web browser
back to Metrowerks... Perhaps the problem lies in the Task Manager
for OS X?
One last thing, I downloaded the Stella emulator (Atari 2600) its
a "Carbon" application, if I run it in OS 9, the frame rate
is 2 or more times as fast as runnning it in OS X. It seems
like the blitting is REALLY slow under OS X (not that its that
fast in OS 9. I mean the application displays 320x200 (or so) size
window and it can not get over 28 or so fps under OS X, while
in Mac OS 9 its up around 60 or more. Of note, if the Stella emulator
is run under Windows 2000, the damn thing is well over 100fps on a
450 mhz Pentium Celeron. Anyway, I really hope Apple is taking the
speed problems seriously, it certainly is discouraging to buy
a brand new iMac (G3) and have it not able to run OS X better.
I for one have my fingers crossed for some major speed increase
with 10.1 in the graphics department and perhaps better task switching
as well.
-Adam
-----Original Message-----
From: Rob Rix [mailto:<zarkingfardwarks...>]
Sent: Friday, July 13, 2001 1:22 PM
To: Markus Hitter
Cc: <macosx-dev...>
Subject: Re: Does PPC suck or has Apple crippled Cocoa ?
> On my 7600, Graphics are very slow and memory consuming. Currently,
> observations with "top" show, that a blinking default button eats about
> 30% of the processor cycles. Even when considering the slow 132MHz CPU,
> this is far more than needed. A similar animated GIF on OS 9 performs
> lots better.
The processor cycles eaten by the default button aside, the first three
words are your answer; the lowest spec'ed machine Apple intends this to be
run on is a 233 Mhz G3 iMac/PowerBook. A 604e at 132 Mhz is _considerably_
lower-end.
Anyhow, it'll all get worked out sooner or later (hopefully sooner, for
everybody who's been having problems).
-- Rob
Murphy strikes again!
_______________________________________________
MacOSX-dev mailing list
<MacOSX-dev...>
http://www.omnigroup.com/mailman/listinfo/macosx-dev -
On Friday, July 13, 2001, at 07:52 , Adam Hall wrote:
> For me it seems to be really slow starting up applications, Im not sure
> but seems like Disk i/o is really slow, or perhaps the size of these
> applications or the memory they are taking up is really large.
I don't know how this long startup time is caused, but I think loading
AppKit, Foundation, Carbon (AppKit uses Carbon), Core* and so on take
their time. I/O is not really the problem, since the disk isn't working
hard during applaunch.
> Also, what seems really slow is when you switch between running
> apps. If I have say OmniWeb running and the mail program, and
> perhaps one other application running (especially a Classic App).
> It becomes very slow switching between applications. Im running
> a Ruby iMac (whatever speed CPU that is) with 256 or so megs of
> ram. Also I have found swithing between say OmniWeb and opening
> a folder from the finder to be slow. The switch takes 3-4 whole
> seconds to just open the folder and show the contents.
This time span has shortened here when I added 256 megs of RAM, so task
switching is very RAM intensive (for whatever reason).
> I remember running OpenStep on a 100mhz Intel box and it seemed
> from a users point of view as fast as this, or perhaps faster.
> So OS X has certainly gotten even more bloated from its OpenStep days.
Sure. OpenStep didn't use translucent menus, jumping icons and crunched
windows.
> Now, as far as running applications in the background OS X seems OK. I
> can compile in the background (even using Classic Metrowerks),and
> say surf the web at the same time and all seems reasonable. It just
> gets REALLY slow when I try to switch away from the web browser
> back to Metrowerks... Perhaps the problem lies in the Task Manager
> for OS X?
I experience the same problem with Project Builder, compiling from the
Terminal (XFree for example) and when Apple Mail goes crazy with indexing
the macosx-dev folder (14339 mails here).
> One last thing, I downloaded the Stella emulator (Atari 2600) its
> a "Carbon" application, if I run it in OS 9, the frame rate
> is 2 or more times as fast as runnning it in OS X. It seems
> like the blitting is REALLY slow under OS X (not that its that
> fast in OS 9. I mean the application displays 320x200 (or so) size
> window and it can not get over 28 or so fps under OS X, while
> in Mac OS 9 its up around 60 or more. Of note, if the Stella emulator
> is run under Windows 2000, the damn thing is well over 100fps on a
> 450 mhz Pentium Celeron. Anyway, I really hope Apple is taking the
> speed problems seriously, it certainly is discouraging to buy
> a brand new iMac (G3) and have it not able to run OS X better.
> I for one have my fingers crossed for some major speed increase
> with 10.1 in the graphics department and perhaps better task switching
> as well.
Double-buffering is the problem. You can compare double-buffered to
non-buffered in iTunes' visualizer (fullscreen/window mode). All games
should be fullscreen, for example Quake 3 is faster in X than in 9.
andy
--
"He was addicted to life. But we cured him" -
Hello!
Around Thu, 12 Jul 2001, Erik M. Buck thusly wrote:
> Does PPC suck or has Apple crippled Cocoa ?
I think we need to be specific and separate the OS from the GUI.
As far as the OS, OSX on a 500MHz iMac is _very_ close to a 440MHz Sun
Ultra 10 box. This is running a compute intensive VLSI CAD analysis tool in
batch mode (no GUI, a good mix of integer and floating point stuff). In
fact, they are neck-in-neck and I can't label one machine faster than the
other.
Can't say much about the OSX GUI, but I do notice that OpenStep on a
120MHz Pentium (no, not Pro, PII or PIII, just P) feels much snappier than
a 500MHz iMac. I think it has to do with the fact that OpenStep had a few
years to optimize the speed of the Display PostScript engine and OSX has
had much less time to optimize the PDF engine. Oh, how I miss DPS... :-(
Cheers!
---
Alvin Jee
mailto:<alvinj...>
NeXTmail gleefully accepted!
Sending bits through the Internet since 1984. -
Good catch Gérard!
On Friday, July 13, 2001, at 01:47 AM, Gerard Iglesias wrote:
> That's a troll ;-)
>
> Le Friday 13 July 2001, à 08:15, Mike a écrit :
>
>> No, you're not nuts, you are right: OS X does suck. Even with the
>> fantastic processing power of the G4, the promises we have been hearing
>> for years about how fast an all-native PPC OS would be have turned out
>> to be lies. Actually that's not quite true - the G4 is an impressive
>> processor - it's just that the 12-year old "modern" NeXT-technology
>> behind OS X is so inefficient that even the G4 cannot overcome it.
>> Classic MacOS is much faster, even with all that emulated 68K code
>> running! Steve has sold Apple and the world a bill of goods and you are
>> just one of the few who has woken up and realized it - the masses have
>> not - yet.
>
> Gerard
------
Fabien Roy
33 Lost Meadow Trail
Lakeway TX 78738
512-608-0060 Home
512-796-9854 Cell
<froy...>
<fabienlroy...> -
Am Freitag, 13. Juli 2001 um 19:22 schrieb Rob Rix:
>> On my 7600, Graphics are very slow and memory consuming. Currently,
>> observations with "top" show, that a blinking default button eats
>> about 30% of the processor cycles. Even when considering the slow
>> 132MHz CPU, this is far more than needed. A similar animated GIF on OS
>> 9 performs lots better.
>
> The processor cycles eaten by the default button aside,
This was my point, nothing else ;-)
I can tell you meaningful numbers for the machine _I_ use, only. But
usually the point is the same on higher end machines. As it is in this
case, if you refer to Rosnya's answer.
Have a nice weekend,
Markus
- - - - - - - - - - - - - - - - - - -
Dipl. Ing. Markus Hitter
http://www.jump-ing.de/ -
Yes, but isint AppKit, Foundation, Carbon , Core etc...
shared resources? Shouldnt it just be slow the first time
you run it, not every time you start an app. Even relativley
small programs seem to take a while to load.
-----Original Message-----
From: Andreas Monitzer [mailto:<am...>]
Sent: Friday, July 13, 2001 2:25 PM
To: Adam Hall
Cc: <macosx-dev...>
Subject: Re: Does PPC suck or has Apple crippled Cocoa ?
On Friday, July 13, 2001, at 07:52 , Adam Hall wrote:
> For me it seems to be really slow starting up applications, Im not sure
> but seems like Disk i/o is really slow, or perhaps the size of these
> applications or the memory they are taking up is really large.
I don't know how this long startup time is caused, but I think loading
AppKit, Foundation, Carbon (AppKit uses Carbon), Core* and so on take
their time. I/O is not really the problem, since the disk isn't working
hard during applaunch. -
Andreas Monitzer wrote:
> On Friday, July 13, 2001, at 07:52 , Adam Hall wrote:
>
>> Also, what seems really slow is when you switch between running
>> apps...
>
> This time span has shortened here when I added 256 megs of RAM, so task
> switching is very RAM intensive (for whatever reason).
It's not that switching is RAM-intensive, but that switching working sets
is RAM-intensive. When you switch to a new app, you switch to using a
whole new set of memory pages. If those pages have been swapped out, they
have to be brought back in. Adding RAM helps solve the problem by
allowing the working set of background applications to stay in memory.
Some of the people who are complaining haven't described their hardware
setups. I'm currently running OSX on two machines, a 266MHz beige G3 (320
MB) and a 400MHz G3 PowerBook (384 MB). The beige G3 is noticeably
snappier when switching applications, once I have a lot of them running.
The difference is the disc speed, which is significantly greater on the
G3. Even with 384MB, swapping is still necessary, so the faster disc is a
big performance win.
Of course, why is it necessary to do so much swapping even with 384MB of
main memory? I suppose that, given that memory is now under $150/GB, the
"bang for your buck" is significantly better than in the $40/MB days when
virtual memory was first made available on MacOS. It's just kinda galling
that we can't do 1,000 times more stuff even though we have 1,000 times
more memory and 1,000 times more MIPS.
-- Bruce
--------------------------------------------------------------------------
Bruce Toback Tel: (602) 996-8601| My candle burns at both ends;
OPT, Inc. (800) 858-4507| It will not last the night;
11801 N. Tatum Blvd. Ste. 142 | But ah, my foes, and oh, my friends -
Phoenix AZ 85028 | It gives a lovely light.
<btoback...> | -- Edna St. Vincent Millay -
Am Freitag, 13. Juli 2001 um 15:02 schrieb Markus Hitter:
> Some years ago I gave OS X Server 1.0.2 a try on this box. This
> one was really nearly as fast as OS 8.1. So I'd guess Display
> PDF is one of the main culprits as it was developed in a short
> time frame. It's probably just not yet finished from a
> performance point of view.
This may be, but as far as I know a pre-version of something
like Quartz with PDF was also integrated in OS-X Server and it
seems that the interface also used this system. One evidence for
this may be the old OS-X Server graphics somewhere in the system.
-- Greetings, Thilo / Amitiés, Thilo / Gruß, Thilo
.______________________________________________________________________________.
| Thilo Ettelt
<thilo...> |
| ICQ: 73662940
http://www.itoast.de |
'
' -
That's the real question!
The working set of most of the apps I use is enormous. And I don't want
to show my age by talking about how I used to have all the same
functionality with less swapping 10 years ago on 1% of the memory and
CPU that I have in my G4, but it is tempting!
I know from experience that big complicated merged multi-API systems
tend to thrash working set, and that working set code cleanup is usually
left till after the initial releases. E.g. make it work FIRST, then
optimize it. So, I am hopeful that there's a team at Apple dedicated to
analysing the multitude of factors that are leading up to bloated
working sets.
It pains me to use my WinNT P2-200 with 192Meg of ram and see email, web
browsing and a big development environment run with snap and never cause
paging, when I can't run Omni, Mail.app and PB at the same time without
frequently listening to my disk for up to 30 seconds when I switch apps.
I would bet that delays due to paging are going to be the #1 cause of
perceived slowness of the whole system.
On Friday, July 13, 2001, at 02:31 PM, Bruce Toback wrote:
>
> Of course, why is it necessary to do so much swapping even with 384MB of
> main memory? I suppose that, given that memory is now under $150/GB, the
> "bang for your buck" is significantly better than in the $40/MB days
> when
> virtual memory was first made available on MacOS. It's just kinda
> galling
> that we can't do 1,000 times more stuff even though we have 1,000 times
> more memory and 1,000 times more MIPS.
-
--On Friday, July 13, 2001 2:43 PM -0700 Tom Waters <tom_waters...>
wrote:
> I would bet that delays due to paging are going to be the #1 cause of
> perceived slowness of the whole system.
>
My unsupported 9600 with 296mhz G3 and 192mb RAM feels much faster now that
I put a Sonnet IDE/UDMA controller in it and a fast IBM udma drive compared
to the slow SCSI drive I was using before. I figured BANG for the BUCK was
highest in upgrading the drive. I think I was right. Unfortunately, RAM
for such a machine is not cheap.
Chad
Pengar Enterprises, Inc. and Shire.Net LLC
Web and Macintosh Consulting -- full service web hosting
Chad Leigh
<chad...> <chad...> -
>
> Double-buffering is the problem. You can compare double-buffered to
> non-buffered in iTunes' visualizer (fullscreen/window mode). All games
> should be fullscreen, for example Quake 3 is faster in X than in 9.
>
I wish it were. In reality you can't play Urban Terror (a Quake III mod)
on X, and I have to reboot into 9 to play.
Nat! (aka mORALISt) -
At 5:48 PM -0400 7/13/01, Chad Leigh, Pengar Enterprises, Inc &
Shire.Net LLC wrote:
> My unsupported 9600 with 296mhz G3 and 192mb RAM feels much faster
> now that I put a Sonnet IDE/UDMA controller in it and a fast IBM
> udma drive compared to the slow SCSI drive I was using before. I
> figured BANG for the BUCK was highest in upgrading the drive. I
> think I was right. Unfortunately, RAM for such a machine is not
> cheap.
Actually (assuming it takes the same as my 7300) there is one place
that offers at a comparatively low rate, Other World Computing
(otherworldcomputing.com).
Upgrading my 7300 from 128MB to 384MB has made a world of difference.
It was practically unusable before.
On the other hand, upgrading my iBook from 160MB to 288MB has not
made much of a difference at all, so YMMV.
-Chad -
Am Freitag, 13. Juli 2001 um 23:48 schrieb Chad Leigh, Pengar
Enterprises, Inc & Shire.Net LLC:
> Unfortunately, RAM for such a machine is not cheap.
Some things, which reduced swapping on my box a lot:
- move unused startup items from /System/Library/StartupItems to another
folder. Sendmail, apache etc. comes into mind.
- do the same with unused Extensions. PPP for example wires down memory
without doing any useful. Doesn't apply if you actually need PPP, of
course. In summary I could reduce wired memory from ~18.5Meg. to
~16.1Meg. Thats a 15% win.
- Deinstall WebObjects if you don't need it. WO installs an OpenBase
server which runs all time by default.
- Turn off AppleTalk. It still seems to chew about 10% performance as it
was in OS 7/8/9. And it needs swapped-in memory, of course.
- run a "update_prebinding -root /" after installing software without
using the installer.
Some of them might be useless, some might be not applicable for others,
but all of them are for free and can easily be switched back. If you
can't boot after removing an extension you need, you're fine with moving
the thing back from within OS 9.
Cheers,
Markus
- - - - - - - - - - - - - - - - - - -
Dipl. Ing. Markus Hitter
http://www.jump-ing.de/ -
On Friday, July 13, 2001, at 05:19 PM, Markus Hitter wrote:
> Some things, which reduced swapping on my box a lot:
>
> - move unused startup items from /System/Library/StartupItems to
> another folder. Sendmail, apache etc. comes into mind.
Why not just set the appropriate values to "NO" in /etc/hostconfig?
It's easier... and it's supported.
-Kevin -
On Thursday, July 12, 2001, at 08:36 PM, Erik M. Buck wrote:
> I have a large Openstep application that generates frames of graphical
> animation at a reliable 20 Hz on a 266 Mhz Pentium II machine running
> Openstep 4.2 with 64Mb and a 5 year old graphics card. The same
> application
> when ported to a 450 Mhz G4 cube running with 384Mb OS X can not
> reliably
> maintain 10 Hz.
Have you performed any graphics optimizations? At WWDC, they
demonstrated huge performance gains by some simple coding techniques,
for example, adding:
- (BOOL)isOpaque
{
return YES;
}
to a view can significantly improve framerates. It may be that the
legacy code you have can be tweaked to deliver much better performance
than you're seeing.
<fergy/> -
Hi,
On Friday, July 13, 2001, at 05:41 PM, Thilo Ettelt wrote:
> Am Freitag, 13. Juli 2001 um 15:02 schrieb Markus Hitter:
>> Some years ago I gave OS X Server 1.0.2 a try on this box. This one
>> was really nearly as fast as OS 8.1. So I'd guess Display PDF is one
>> of the main culprits as it was developed in a short time frame. It's
>> probably just not yet finished from a performance point of view.
> This may be, but as far as I know a pre-version of something like
> Quartz with PDF was also integrated in OS-X Server and it seems that
> the interface also used this system. One evidence for this may be the
> old OS-X Server graphics somewhere in the system.
a) OSX Server ran with Display PostScript and was for the most part a
port of OpenStep with a new UI and a Workspace.app that had taken a
serious beating. The images you may have found are probably left overs
in the AppKit framework. You may still find old black and white NeXT
logos; they were there under OSX Server.
b) Launch times, swap intervals and XRGB have nothing to do with the
speed problems reported. (although they are performance concerns) It
seems that either Eric is misusing Sampler.app or that Foundation got
slow. His app sounds very math intensive so the math libraries could be
to blame.
Eric: I don't really know what kind of imaging you're doing but you
may try speeding up the inner loops by using AltiVec instructions that
can operate on a few RGBA pixels at once if its appropriate. It kind of
sucks to turn to fancy SIMD assembly language when your PPro worked fine
but you may see a dramatic performance boost.
Take it easy,
Guy -
>> I have a large Openstep application that generates frames of graphical
>> animation at a reliable 20 Hz on a 266 Mhz Pentium II machine running
>> Openstep 4.2 with 64Mb and a 5 year old graphics card. The same
>> application
>> when ported to a 450 Mhz G4 cube running with 384Mb OS X can not
>> reliably
>> maintain 10 Hz.
I'll toss in my two cents.
Have you tried blitting through Quicktime instead of Cocoa? Quicktime has
been closely tied to graphics accelerators for quite a while now. In
particular you might want to look at FDeCompress, if you haven't already.
I don't know if this will be compatible with your RGB model or not.
