OS X performance: iTunes too slow on a G4 450???
-
Hi,
I installed the OS X version of iTunes on my G4/450 Cube yesterday
and was kind of shocked to see that the visualization effects don't
run smoothly as soon as the window isn't very small (they run
perfectly smoothly even in full screen mode on my TiBook G4/400
with OS 9.1). It looks as if roughly twice as much speed would be
needed. A (not even existing yet) G4/900 is needed to run iTunes
acceptably fast?
Given that iTunes is a new program probably already written with
Carbon in mind, I doubt that iTunes/OS X is much less optimized
than iTunes/OS 9.1.
Does that mean that graphics speed on OS X is really that much
worse than on OS 9.x (it's hardly the visualization algorithm
itself)? Is this a Carbon only thing, or is Cocoa affected as well?
Anybody knows anything about this really dismal iTunes performance?
Bye
Uli
________________________________________________________
Uli Zappe <uli...>
Lorscher Straße 5 http://www.ritual.org
D-60489 Frankfurt Fon: +49-700-ULIZAPPE
Germany Fax: +49-700-ZAPPEFAX
________________________________________________________ -
On Thursday, April 26, 2001, at 01:23 AM, Uli Zappe wrote:
> Does that mean that graphics speed on OS X is really that much worseJust a guess, but it could be that CoreGraphics' double buffering is
> than on OS 9.x (it's hardly the visualization algorithm itself)? Is
> this a Carbon only thing, or is Cocoa affected as well? Anybody knows
> anything about this really dismal iTunes performance?
causing each frame to be rendered twice, once into the window's buffer
and then again to the screen at the next interrupt. Unfortunately there
really isn't a way to turn off CoreGraphics double buffering for just
part of a window. You can use retained mode for the entire window, which
turns off double buffering if the window is not obscured partially or
totally by other windows, but this would cause the entire window to not
be double buffered, making for slower than average window refreshes.
That's probably why it's so fast in full screen mode—they can use
retained mode at full screen since they're guaranteed that no other
window will be on top of the visualizer then. Even better, I believe the
QuickTime function BeginFullScreen() turns off double buffering entirely.
Ryan McGann
<mcgann...>
DOS Computers manufactured by companies such as IBM, Compaq, Tandy, and
millions of others are by far the most popular, with about 70 million
machines in use wordwide. Macintosh fans, on the other hand, may note
that cockroaches are far more numerous than humans, and that numbers
alone do not denote a higher life form.
New York Times, November 26, 1991 -
It probably is because of non-full screen. Try running the same size on
the two machines. You will find that they are similar when not in
fullscreen. This is because of many annoying little graphics bits that
are too complex to really delve into right now.
Daniel
On Wednesday, April 25, 2001, at 11:23 PM, Uli Zappe wrote:
> Hi,
>
> I installed the OS X version of iTunes on my G4/450 Cube yesterday and
> was kind of shocked to see that the visualization effects don't run
> smoothly as soon as the window isn't very small (they run perfectly
> smoothly even in full screen mode on my TiBook G4/400 with OS 9.1). It
> looks as if roughly twice as much speed would be needed. A (not even
> existing yet) G4/900 is needed to run iTunes acceptably fast?
>
> Given that iTunes is a new program probably already written with Carbon
> in mind, I doubt that iTunes/OS X is much less optimized than iTunes/OS
> 9.1.
>
> Does that mean that graphics speed on OS X is really that much worse
> than on OS 9.x (it's hardly the visualization algorithm itself)? Is
> this a Carbon only thing, or is Cocoa affected as well? Anybody knows
> anything about this really dismal iTunes performance?
>
> Bye
> Uli
> ________________________________________________________
>
> Uli Zappe <uli...>
> Lorscher Straße 5 http://www.ritual.org
> D-60489 Frankfurt Fon: +49-700-ULIZAPPE
> Germany Fax: +49-700-ZAPPEFAX
> ________________________________________________________
> _______________________________________________
> MacOSX-dev mailing list
> <MacOSX-dev...>
> http://www.omnigroup.com/mailman/listinfo/macosx-dev
>
Daniel Staudigel -
It's the lame preemptive multitasking.
Try this:
Run iTunes or ANY app for OS X and 9.1 on 9.1 in the foreground
Run that app on OS X in the foreground.
Which is faster? 9.1 of course.
On OS X EVERYTHING has the same exact priority. this explains
somewhat for the slow typing and the slow launch times. I WANT MY
COOPERATIVE MULTITASKING BACK!
Ack, at 4/26/01, Uli Zappe said:
> I installed the OS X version of iTunes on my G4/450 Cube yesterday
> and was kind of shocked to see that the visualization effects don't
> run smoothly as soon as the window isn't very small (they run
> perfectly smoothly even in full screen mode on my TiBook G4/400 with
> OS 9.1). It looks as if roughly twice as much speed would be needed.
> A (not even existing yet) G4/900 is needed to run iTunes acceptably
> fast?
>
> Given that iTunes is a new program probably already written with
> Carbon in mind, I doubt that iTunes/OS X is much less optimized than
> iTunes/OS 9.1.
>
> Does that mean that graphics speed on OS X is really that much worse
> than on OS 9.x (it's hardly the visualization algorithm itself)? Is
> this a Carbon only thing, or is Cocoa affected as well? Anybody
> knows anything about this really dismal iTunes performance?
--
Sincerely,
Rosyna Keller
Technical Support/Holy Knight/Always needs a hug
Unsanity: Unsane Tools for Insane People -
On Wednesday, April 25, 2001, at 11:23 PM, Uli Zappe wrote:
> Hi,
>
> I installed the OS X version of iTunes on my G4/450 Cube yesterday and
> was kind of shocked to see that the visualization effects don't run
> smoothly as soon as the window isn't very small (they run perfectly
> smoothly even in full screen mode on my TiBook G4/400 with OS 9.1). It
> looks as if roughly twice as much speed would be needed. A (not even
> existing yet) G4/900 is needed to run iTunes acceptably fast?
>
> Given that iTunes is a new program probably already written with Carbon
> in mind, I doubt that iTunes/OS X is much less optimized than iTunes/OS
> 9.1.
Nah, iTunes is based on SoundJam, I can't say that authoritatively, of
course, but I'm pretty sure it's true. Given that SoundJam has been
around for a while, Carbonizing iTunes was probably a big deal. Remember
that it wasn't finished by the time OS X went GM, but they did manage to
finish it by the actual release date.
> Does that mean that graphics speed on OS X is really that much worse
> than on OS 9.x (it's hardly the visualization algorithm itself)? Is
> this a Carbon only thing, or is Cocoa affected as well? Anybody knows
> anything about this really dismal iTunes performance?
I don't think iTunes is a very good benchmark for graphics performance.
It was probably heavily optimized under OS 9, and since the runtime
environment in X is so different (preemtive multitasking) those
optimizations won't be effective under X.
Of course, this is all speculation. If fact, I'm sure that graphics
performance under X isn't as fast as under 9, simply because
CoreGraphics is so new. But that's not what you're seeing in iTunes.
colin
--------------------------------------
Colin Putney
Whistler.com -
At 12:17 Uhr -0700 28.04.2001, Rosyna wrote:
> It's the lame preemptive multitasking.
>
> Try this:
>
> Run iTunes or ANY app for OS X and 9.1 on 9.1 in the foreground
>
> Run that app on OS X in the foreground.
>
> Which is faster? 9.1 of course.
>
> On OS X EVERYTHING has the same exact priority. this explains
> somewhat for the slow typing and the slow launch times. I WANT MY
> COOPERATIVE MULTITASKING BACK!
OK, please read everything I wrote before you flame me ;)
IMHO that what you wrote is not quite an intelligent thing to say,
sorry. First of, anybody who says preemptive OR cooperative
multitasking is "better" is not thinking it through. Both have
advantages. Both have disadvantages. But in general, people tend to
prefer preemptive. I belong to that bunch, for some reasons. And I
think on total, the drawbacks of cooperative outweight its advantages
(unless you live in a perfect world, where every programer makes no
mistakes, and hence writes perfect apps that never crash. hahhahaha)
With cooperative multitasking, if I run a lot of apps, any MP3 player
I have used so far at some point stops to play continually.
With a preemptive multitasking, you can gurantee time to the MP3
player, so it can run smoothly all the time.
Now, you'll tell me that this is apparantly not the case on OS X, and
I'd agree. The problem simply is that one would have to set
"pritorites" for tasks.
It is wrong to say that every app has exact the same priority! On any
preemptive OS I know about (I don't count OS X in here though, as I
don´t know its internals well enough so far), the foreground tasks
gets a higher priority.
One thing we really could need is a (GUI) way to specify a priority
for apps, preferably even one that is stored. So I could assign a
higher priortiy to my MP3 player so it can run smoothly, and a lower
on to my text editor. The text edior's *input* thread still would
want a high priority of course, but only if it was the foremost app...
And I do fully agree that OS X is much too slow, but I doubt that you
can blame this all on the preemptive multitasking. I for myself see
the many advantages it (pre. mult.) has, one being that a single app
can't freeze my machine, like IE used to do under OS 9.
Max
--
-----------------------------------------------
Max Horn
C++/ObjC/Java Developer
email: <mailto:<max...>
phone: (+49) 6151-494890 -
Ack, at 4/29/01, Max Horn said:
> And I think on total, the drawbacks of cooperative outweight its
> advantages (unless you live in a perfect world, where every
> programer makes no mistakes, and hence writes perfect apps that
> never crash. hahhahaha)
That is protected memory, not multitasking.
>
> With cooperative multitasking, if I run a lot of apps, any MP3
> player I have used so far at some point stops to play continually.
Not the ones I use ;)
> With a preemptive multitasking, you can gurantee time to the MP3
> player, so it can run smoothly all the time.
Yes, but with TRUE preemptive multitasking, it gets the same time as
all other processes. This could actually cause it to skip more.
> It is wrong to say that every app has exact the same priority! On
> any preemptive OS I know about (I don't count OS X in here though,
> as I don´t know its internals well enough so far), the foreground
> tasks gets a higher priority.
On OS X, this definitely isn't the case. All apps have the same
priority by default. This is sort of the opposite of preemptive.
> One thing we really could need is a (GUI) way to specify a priority
> for apps, preferably even one that is stored. So I could assign a
> higher priortiy to my MP3 player so it can run smoothly, and a lower
> on to my text editor. The text edior's *input* thread still would
> want a high priority of course, but only if it was the foremost
> app...
Yes, there should be NO reason a background app needs text input.
> And I do fully agree that OS X is much too slow, but I doubt that
> you can blame this all on the preemptive multitasking. I for myself
> see the many advantages it (pre. mult.) has, one being that a single
> app can't freeze my machine, like IE used to do under OS 9.
In OS X, IE can still freeze the machine (crash the window manager)
--
Sincerely,
Rosyna Keller
Technical Support/Holy Knight/Always needs a hug
Unsanity: Unsane Tools for Insane People -
Am Samstag, 28. April 2001 um 21:17 schrieb Rosyna:
> It's the lame preemptive multitasking.
Most certainly not. NEXTSTEP never had this problem. And I just
wrote a C program that does expensive mathematical calculations,
and it runs extremely fast, even with a QuickTime movie playing in
the background.
I'm sure this has much more to do with OS X' graphics system in
contrast to OS 9's.
Bye
Uli
________________________________________________________
Uli Zappe <uli...>
Lorscher Straße 5 http://www.ritual.org
D-60489 Frankfurt Fon: +49-700-ULIZAPPE
Germany Fax: +49-700-ZAPPEFAX
________________________________________________________ -
Le dimanche 29 avril 2001, à 04:14, Rosyna <rosyna...> a écrit :
> On OS X EVERYTHING has the same exact priority. this explains
> somewhat for the slow typing and the slow launch times. I WANT MY
> COOPERATIVE MULTITASKING BACK!
Do you write such crazy things just to give sense to the name of your
company?
That's pure nonsense. For ME, iTunes is not slow on X, but I use it to
listen music! And it never sleep (except when I wake up the Cube, but I
believe it due to the external speakers), THANKS TO PREEMPTIVE
MULTITASKING!!!!
I don't mind at all these visual effects, that's pure side-feature for me
(and most people probably). I DO mind the fact it cannot correctly connect
to CDDB (though the 9.1 does), which is much more important. Besides that
iTunes is really amazing (creates mp3 really fast), and it's free!!
You people who are constantly complaining about the changes from 9 to X,
did you spent some time working on common software --- you know, that big
piece of crap named *** Office (there is M, S, a lot of money and even
more dishonesty in the name) which crashes the whole Mac every five
minutes or so, and that many people are FORCED to use because it is
"standard".
If you did, then you WILL LOVE Mac OS X, just for this only reason...
PREEMPTIVE MULTITASKING!
Thomas Lachand-Robert
********************** <tlr...>
<< Et le chemin est long du projet à la chose. >> Molière, Tartuffe. -
On Sunday, April 29, 2001, at 05:58 , Uli Zappe wrote:
> Am Samstag, 28. April 2001 um 21:17 schrieb Rosyna:
>
>> It's the lame preemptive multitasking.
>
> Most certainly not. NEXTSTEP never had this problem. And I just wrote a C
> program that does expensive mathematical calculations, and it runs
> extremely fast, even with a QuickTime movie playing in the background.
>
> I'm sure this has much more to do with OS X' graphics system in contrast
> to OS 9's.
A window resize always redraws the whole window, that shows how optimized
it is...
(and that's why resizing is so slow - I don't know how Steve demonstrated
it, it was way too smooth for any existing processor)
andy
--
Description forthcoming. -
Ack, at 4/29/01, <tlr...> said:
> And it never sleep (except when I wake up the Cube, but I believe it
> due to the external speakers), THANKS TO PREEMPTIVE MULTITASKING!!!!
All audio objectts skip when waking from even monitor sleep.
> You people who are constantly complaining about the changes from 9
> to X, did you spent some time working on common software --- you
> know, that big piece of crap named *** Office (there is M, S, a lot
> of money and even more dishonesty in the name) which crashes the
> whole Mac every five minutes or so, and that many people are FORCED
> to use because it is "standard".
> If you did, then you WILL LOVE Mac OS X, just for this only
> reason... PREEMPTIVE MULTITASKING!
Isn't this protected memory again?
--
Sincerely,
Rosyna Keller
Technical Support/Holy Knight/Always needs a hug
Unsanity: Unsane Tools for Insane People -
Am Sonntag, 29. April 2001 um 18:15 schrieb Rosyna:
> Ack, at 4/29/01, <tlr...> said:[...]
>
>> you know, that big piece of crap named *** Office [...] which crashes
>> the whole Mac every five minutes or so
>> you WILL LOVE Mac OS X, just for this only reason... PREEMPTIVE
>> MULTITASKING!
>
> Isn't this protected memory again?
Not necessarily - one of the ways Classic applications could hang up the
whole system was by getting into an infinite loop and never returning
control to another application (or the Finder) again.
That's something that should be a thing of the past with preemptive
multitasking.
----------------------------------
Jens Baumeister, Bullex GmbH, Cologne
programming: v. An activity similar to banging one's head against a wall,
but with fewer opportunities for reward. -
Sadly, it isn't a thing of the past. I have had MANY apps go into an
infinite loop (rainbow cursor of death) which requires a force quit.
This is the same outcome that would have been necessary in 9.1, only
this time you can switch to other apps while in the loop.
Ack, at 4/29/01, Jens Baumeister said:
> Not necessarily - one of the ways Classic applications could hang up
> the whole system was by getting into an infinite loop and never
> returning control to another application (or the Finder) again.
>
> That's something that should be a thing of the past with preemptive
> multitasking.
--
Sincerely,
Rosyna Keller
Technical Support/Holy Knight/Always needs a hug
Unsanity: Unsane Tools for Insane People -
On Sun, 29 Apr 2001, Rosyna wrote:
> Sadly, it isn't a thing of the past. I have had MANY apps go into an
> infinite loop (rainbow cursor of death) which requires a force quit.
> This is the same outcome that would have been necessary in 9.1, only
> this time you can switch to other apps while in the loop.
You're missing the point:
Consider an application Foo, which happens to go into an infinite loop.
Under a cooperative multitasking system, once Foo enters its infinite
loop, no other applications nor the OS itself will ever regain control
(remember, Foo has to _cooperate_ with the other processes by
relinquishing control - hence the name 'cooperative multitasking'), so in
order to do anything besides let Foo run its infinite loop, the system
hhas to be rebooted.
Under a preemptive multitasking system, the application will hog the CPU
durin its assigned time slices, but every now and then the OS will take
control away from Foo (thus pre-empting Foo - which is where the phrase
'pre-emptive multitasking' comes from), and allow itself and/or other
applications that mmight be ready to do something, the chance to run. So
the user can switch to another application, try to kill the errant Foo
process, etc, all without having to interrupt the operation of the system
as a whole.
This is the main defining difference between cooperative and preemptive
multitasking.
So the point that a runaway application in Mac OS 9 can hang the entire
syste, wherear in Mac OS X it can not do so, is precisely the result of
going from cooperative to preemptive multitasking.
[ As an aside, I have heard that in certain telephone switches there is a
sort of enforced cooperative multitasking system - i.e., the basis of the
system iis cooperative, but there is also a timer that gets reset whenever
a process yeilds control. And if ever the timer fires, this indicates that
the ccurrent process has _not_ yielded in far too long and is thus
_un_cooperative, at which point the process does get preempted (through
the interrupt fired by the timer) and the OS will summarily kill the
uncooperativve process. Sort of 'cooperate - or else!' . I actually find
that approach quite appealing in a poetivc sense :) ]
> Sincerely,
> Rosyna Keller
// Christian Brunschen -
Le dimanche 29 avril 2001, à 06:31, Rosyna a écrit :
> Sadly, it isn't a thing of the past. I have had MANY apps go into an
> infinite loop (rainbow cursor of death) which requires a force quit. This
> is the same outcome that would have been necessary in 9.1, only this time
> you can switch to other apps while in the loop.
>
No the point is that now you can really force-quit. Most of the time on OS
9, force quitting is not possible, or crash the whole system.
Another important point is protected memory also. Some programs like M$ W?
?d 98 are able to put the system in such a bad state that everything will
crash even AFTER you quit them! So my basic advice to every user was: "if
you have to use them, then do. After that, just RESTART immediatly".
You can see the tradeoff: "well, on my Win??? machine, i don't have to do
that... the Mac doesn't work..." HERE is the whole point at the end,
obviously. Because it is here that some OS are chosen (or not) by lambda
user.
All of us we MUST remember: without Lambda User, we wouldn't even have
Macs, since power users are only 1% of the market or so, and that's just
to small for a company building hardware+OS+(some of) soft. So please
everyone, stop whining about features of Mac OS 9 not existing on Mac OS X
(BTW, if you check at www.macosxhints.com, you will see A LOT of very cool
features in X not existing in 9).
Go to work to build GREAT soft on Mac OS X, fill bug reports if necessary
(and possible), ask new features when it does make sense for most users
(power users always have there own way, don't they?).
Mac OS 9 is dead, long life to Mac OS X!
Thomas Lachand-Robert
********************** <tlr...>
<< Et le chemin est long du projet à la chose. >> Molière, Tartuffe. -
Am Sonntag, 29. April 2001 um 17:36 schrieb Rosyna:
> Ack, at 4/29/01, Max Horn said:
>> And I think on total, the drawbacks of cooperative outweight its
>> advantages (unless you live in a perfect world, where every programer
>> makes no mistakes, and hence writes perfect apps that never crash.
>> hahhahaha)
> That is protected memory, not multitasking.
Not really. Protected memory protects the memory (of course...),
preemptive multitasking protects the CPU. Without preemption,
every program can freeze the OS with an "x: goto x;" program.
>> With a preemptive multitasking, you can gurantee time to the MP3
>> player, so it can run smoothly all the time.
> Yes, but with TRUE preemptive multitasking, it gets the same time as
> all other processes. This could actually cause it to skip more.
That's a question of the scheduling algorithm, it has nothing
to do with preemption. Preemptive multitasking just means the
OS is controlling which process can spend time in the CPU,
cooperative multitasking means the programs do it themselves.
>> It is wrong to say that every app has exact the same priority! On any
>> preemptive OS I know about (I don't count OS X in here though, as I
>> don´t know its internals well enough so far), the foreground tasks
>> gets a higher priority.
> On OS X, this definitely isn't the case. All apps have the same
> priority by default.
That's correct, but this is just a bug. Mach and BSD 4.4 both support
priorities but in Mac OS X the Mach function resetpriority() is
currently disabled. So there are priorities but the function to change
them is disconnected. This will be repaired in the future.
> In OS X, IE can still freeze the machine (crash the window manager)
Crashing the window manager cannot freeze the machine. The loginwindow
process will immediately restart the window manager if there's a
problem.
Marcel
--
Dr. Marcel Bresink, Ringstr. 21, 56630 Kretz, Germany
Fon: +49-2632-953150 Fax: -953151 http://www.bresink.de/ -
Actually, I'm not sure that you are seeing infinite loops. I'm curious
to know if anyone else is experiencing the same thing I am and this may
explain why you see the rainbow.
You go to do something (say save a doc in Project Builder). Up comes the
cursor (wait, where'd that come from?). Then a few seconds stretches on
into more than a minute (sometimes many). Other applications "refuse" to
launch (though you can still quit applications). Any of this sound
familiar to anyone?
The reason this is relevant is that this isn't actually a crash,
infinite loop or other permanent hang-up. I don't know the reason why it
is occurring (I can only imagine it is blocked io somewhere), but the
system eventually kicks back in and things return to normal. This
usually takes a minute or two to "fix" itself. So maybe what you are
seeing is this behavior and not infinite loops.
In any event, anyone else have this happpen?
Chris
On Sunday, April 29, 2001, at 12:31 PM, Rosyna wrote:
> Sadly, it isn't a thing of the past. I have had MANY apps go into an
> infinite loop (rainbow cursor of death) which requires a force quit.
> This is the same outcome that would have been necessary in 9.1, only
> this time you can switch to other apps while in the loop.
>
> Ack, at 4/29/01, Jens Baumeister said:
>
>> Not necessarily - one of the ways Classic applications could hang up
>> the whole system was by getting into an infinite loop and never
>> returning control to another application (or the Finder) again.
>>
>> That's something that should be a thing of the past with preemptive
>> multitasking.
>
> -- Sincerely,
> Rosyna Keller
> Technical Support/Holy Knight/Always needs a hug
>
> Unsanity: Unsane Tools for Insane People
> _______________________________________________
> MacOSX-dev mailing list
> <MacOSX-dev...>
> http://www.omnigroup.com/mailman/listinfo/macosx-dev
>
>
-
<massive sarcasm>
Really? Wow, I must have been stoned the five+ times it happened to me.
</massive sarcasm>
Seriously, the window manager doesn't auto relaunch itself if
crashed. You must manually kill it. which means remotely logging in
and killing it.
Ack, at 4/29/01, Marcel Bresink said:
> Crashing the window manager cannot freeze the machine. The loginwindow
> process will immediately restart the window manager if there's a
> problem.
--
Sincerely,
Rosyna Keller
Technical Support/Holy Knight/Always needs a hug
Unsanity: Unsane Tools for Insane People -
On Sunday, April 29, 2001, at 12:34 PM, Chris Behm wrote:
> Actually, I'm not sure that you are seeing infinite loops. I'm curiousYES! This has happened a couple of times with Project Builder and
> to know if anyone else is experiencing the same thing I am and this may
> explain why you see the rainbow.
>
> You go to do something (say save a doc in Project Builder). Up comes
> the cursor (wait, where'd that come from?). Then a few seconds
> stretches on into more than a minute (sometimes many). Other
> applications "refuse" to launch (though you can still quit
> applications). Any of this sound familiar to anyone?
Interface Builder (not meaning they are the only culprits, but they're
really the only major apps I use as of late). I'll be working, suddenly
things start grinding to a halt. Rainbow cursor. So I try to launch
Terminal to kill it, and Terminal's icon starts bouncing...and
bouncing....and bouncing. After like two minutes it stops bouncing, but
no Terminal window (I think the Dock just gives up on it and assumes
it's really loaded). I can switch to another program and continue using
them (sorta, as VM is paging constantly) but can't launch anything else.
There is also another bug that I can't seem to reproduce easily but it's
definitely there (been bitten three our four times now). After using
Interface Builder for a while, it slows down dramatically with
complicated nib's. But this one is a particular instance of this
problem: After selecting multiple objects (seems to happen with popup
menus more often), doing something like moving them and then undoing the
move, the objects become a jumbled mess at the bottom of the window or
view. I try to click on them to move them and virtual memory starts
paging like madness. Rainbow cursor, and more virtual memory thrashing.
Seconds turns into minutes and I swear the chipmunks turning my hard
drive are having a stroke, so I try to kill it. I see the Force Quit
window start to come up SCANLINE by SCANLINE. It's painful to see
something so Unix like brought to its knees. Even more painful to click
on an item once the Force Quit window is up, wait two minutes before
it's hilighted (again scanline by scanline, watching CG paint the
hilight color and all) and then clicking on the Force Quit button (which
CG is fruitlessly trying to animate still).
BTW, this is on a computer with 256MB and nothing but IB/PB running, so
it's not like I'm trying to run Photoshop in Classic or something.
Problem is, I can't reproduce it reliably—it seems to just happen
sometimes but not others—so reporting it to Apple is pointless. Can
anybody else verify?
Ryan McGann
<mcgann...>
Windows Definitions:
Multitasking: It is possible for several programs crash at the same time
Microsoft Network: Talk to other people about your Windows 98 crash
experiences
Multimedia: System crashes with a lot of graphics, sound & animations
Compatiblity: It can crash old Windows 3.11 programs. -
Le dimanche 29 avril 2001, à 08:20, Ryan McGann a écrit :
>> Actually, I'm not sure that you are seeing infinite loops. I'm curious
>> to know if anyone else is experiencing the same thing I am and this may
>> explain why you see the rainbow.
>>
>> You go to do something (say save a doc in Project Builder). Up comes the
>> cursor (wait, where'd that come from?). Then a few seconds stretches on
>> into more than a minute (sometimes many). Other applications "refuse" to
>> launch (though you can still quit applications). Any of this sound
>> familiar to anyone?
> YES! This has happened a couple of times with Project Builder and
> Interface Builder (not meaning they are the only culprits, but they're
> really the only major apps I use as of late). I'll be working, suddenly
> things start grinding to a halt. Rainbow cursor. So I try to launch
> Terminal to kill it, and Terminal's icon starts bouncing...and
> bouncing....and bouncing. After like two minutes it stops bouncing, but
> no Terminal window (I think the Dock just gives up on it and assumes it's
> really loaded). I can switch to another program and continue using them
> (sorta, as VM is paging constantly) but can't launch anything else.
>
Yes I did have that also, not necessarily with PB/IB, also with iTunes,
browsers, etc. Also if you succeed to force-quit the "offending" apps, you
will regret: after quitting everything, you can get stick with an
unresponsive Finder. Twice I tried to log out at this time. The strange
thing is that you can't: evrything on screen become blue, then the Finder
launches again! And that continues if you log out again. If I remember
well, restarting did work.
My guess is there is a bug in the "loginwindow" process (don't remember
the exact name: the thing that launches the Finder as you log in). It is
very difficult to specify/reproduce, so I didn't file a bug report at the
moment.
Thomas Lachand-Robert
********************** <tlr...>
<< Et le chemin est long du projet à la chose. >> Molière, Tartuffe. -
On Sunday, April 29, 2001, at 06:45 , Christian Brunschen wrote:
> [ As an aside, I have heard that in certain telephone switches there is a
> sort of enforced cooperative multitasking system - i.e., the basis of the
> system iis cooperative, but there is also a timer that gets reset whenever
> a process yeilds control. And if ever the timer fires, this indicates that
> the ccurrent process has _not_ yielded in far too long and is thus
> _un_cooperative, at which point the process does get preempted (through
> the interrupt fired by the timer) and the OS will summarily kill the
> uncooperativve process. Sort of 'cooperate - or else!' . I actually find
> that approach quite appealing in a poetivc sense :) ]
That's called 'watchdog' and is quite common on mission critical UNIX
servers (satellites for example - who would press the reset button up
there?). Some Linux
distros even ship with a software solution preinstalled.
andy
--
Discussion forthcoming. -
On 29/4/01 19:20, "Ryan McGann" <mcgann...> wrote:
> YES! This has happened a couple of times with Project Builder and
> Interface Builder (not meaning they are the only culprits, but they're
> really the only major apps I use as of late). I'll be working, suddenly
> things start grinding to a halt. Rainbow cursor. So I try to launch
> Terminal to kill it, and Terminal's icon starts bouncing...and
> bouncing....and bouncing. After like two minutes it stops bouncing, but
> no Terminal window (I think the Dock just gives up on it and assumes
> it's really loaded). I can switch to another program and continue using
> them (sorta, as VM is paging constantly) but can't launch anything else.
Just think carefully about what you say you're doing there, Ryan: an
application is in trouble, so you then try to launch another application
whilst the first is still in trouble. That new application needs to insert
itself in the task list to get processor cycles, is asking for a fair chunk
of virtual memory, and trying to get menus, windows, etc., drawn and brought
to the front, let alone wanting the Dock to bounce its icon up and down.
When things are going well that can take time - when they're going badly,
this doesn't seem a wise way to proceed.
Instead, when you presume the busy cursor means the bye-bye cursor, try
Command, Option and Escape, and force quit the app. Under Mac OS 9 and
before, although this sometimes worked, it more often than not precipitated
a complete freeze or bomb. Under Mac OS X, it stands a fair chance of
working as advertised. Why, on many occasions I have even been able to
restart the Finder (if required) and carry on as normal. I may as well have
cut notches on my computer case for the number of times I have been able to
get away with that pre-X!
I'm also mystified by those harking back to co-operative rather than
pre-emptive multitasking - I'll listen for the groan from Cupertino tomorrow
when the OS X team read those comments. For years Apple has been barraged by
developers and advanced users demanding pre-emptive multitasking and memory
protection. Now they have actually delivered it to us, to recant is more
than a little fickle! Sure there are some warts at the moment, but we're
still on release number 1.0.1 for goodness sake. Restart in Mac OS 9 and try
running iTunes or any other player when a foreground app seizes the
processor altogether, if you want to remind yourself how co-operative
multitasking can fall apart in release number 9.1.
Summary: OS X is streets ahead of OS 9 and before, but it does need further
maturing.
Howard.
Dr Howard Oakley * M1BWR: QRV on 2, 4 & 6 m SSB
EHN & DIJ Oakley * Internet <howard...>
Brooklands Lodge * CompuServe 70734,120
Park View Close * http://www.quercus.demon.co.uk
Wroxall, Ventnor * voice +44 1983 853605
Isle of Wight, PO38 3EQ, UK * fax +44 1983 853253 -
> Anybody knows anything about this really dismal iTunes performance?
Many Carbon apps seem to be wasting CPU cycles. It looks like the apps that
are "quick and dirty" ports (which likely still do their own poll-for-event
loops) suffer more than the ones that have had more OS X-targeted
fine-tuning (and likely use native run loop services). But that's just a
guess on my part.
--
Rick Roe
icons.cx / The Omni Group -
On Monday, April 30, 2001, at 02:56 AM, Marcel Bresink wrote:
>>> It is wrong to say that every app has exact the same priority! On any
>>> preemptive OS I know about (I don't count OS X in here though, as I
>>> don´t know its internals well enough so far), the foreground tasks
>>> gets a higher priority.
>> On OS X, this definitely isn't the case. All apps have the same
>> priority by default.
>
> That's correct, but this is just a bug. Mach and BSD 4.4 both support
> priorities but in Mac OS X the Mach function resetpriority() is
> currently disabled. So there are priorities but the function to change
> them is disconnected. This will be repaired in the future.
It was repaired last week, in fact. Apple's Umesh Vaishampayan announced
that it was fixed and would appear in the Darwin source tree shortly
(probably is there by now).
Then there's the ability of BSD to guarantee cycles to "realtime"
processes eg. media players that you don't want to skip, critical
daemons etc. -
The problems described below have to do with lookup and netinfod. The
lookups don't work because your local netinfo server died/lost-its-mind
and the whole system grinds to a halt. After about a minute things start
working again.
I don't know about experiences of other people but I have ended up
writing a crontab that restarts lookupd every 15 minutes, and disable
the caching on DNS lookups. This way I can sort of guarantee that my
internet connection is working... *sigh*
Sometimes I really want to go back to OpenStep or even MacOS9.
Annard
On Sunday, April 29, 2001, at 11:20 , Ryan McGann wrote:
> On Sunday, April 29, 2001, at 12:34 PM, Chris Behm wrote:
> You go to do something (say save a doc in Project Builder). Up comes
> the cursor (wait, where'd that come from?). Then a few seconds
> stretches on into more than a minute (sometimes many). Other
> applications "refuse" to launch (though you can still quit
> applications). Any of this sound familiar to anyone?
> YES! This has happened a couple of times with Project Builder and
> Interface Builder (not meaning they are the only culprits, but they're
> really the only major apps I use as of late). I'll be working, suddenly
> things start grinding to a halt. Rainbow cursor. So I try to launch
> Terminal to kill it, and Terminal's icon starts bouncing...and
> bouncing....and bouncing. After like two minutes it stops bouncing, but
> no Terminal window (I think the Dock just gives up on it and assumes
> it's really loaded). I can switch to another program and continue using
> them (sorta, as VM is paging constantly) but can't launch anything else.
-
On Sunday, April 29, 2001, at 06:34 , Chris Behm wrote:
> Actually, I'm not sure that you are seeing infinite loops. I'm curious
> to know if anyone else is experiencing the same thing I am and this may
> explain why you see the rainbow.
>
> You go to do something (say save a doc in Project Builder). Up comes
> the cursor (wait, where'd that come from?). Then a few seconds
> stretches on into more than a minute (sometimes many). Other
> applications "refuse" to launch (though you can still quit
> applications). Any of this sound familiar to anyone?
>
I mailed the projectbuilder list about this back in March and got the
hopeful sounding reply of
> I've seen this several times, both on my machine and others. I've spent
> some time investigating it, and the current theory is that Project
> Builder is hanging due to a kernel bug triggered by trying to swap in a
> VM page. I think a fix is in the works, but I'm not sure how it will be
> delivered.
>
> Anders
from Anders Bertelrud <anders...> but I've seen similar posts and
no other 'official' Apple responses since then.
It's a difficult bug to file as it's almost always possible to sample
the process as it seems to be waiting for a lock to come free. Any other
process that might touch it (like ps) also hangs.
I wonder whether it really has been fixed?
-- Gideon -
> Seriously, the window manager doesn't auto relaunch itself if crashed.
> You must manually kill it. which means remotely logging in and killing
> it.
This means it was still running and by definition this isn't
a crash. And in a cooperative multitasking system you wouldn't
have been able to log in.
Marcel
--
Dr. Marcel Bresink, Ringstr. 21, 56630 Kretz, Germany
Fon: +49-2632-953150 Fax: -953151 http://www.bresink.de/ -
This is hardly a good comparison. Either the whole system halts (OS
9.x) or just one app halts (OS X). And let's not call it the "rainbow
cursor of death" just because some apps have errors and this is the
default "progress" cursor. At least the whole screen doesn't turn blue
and display 4 or 5 lines of cryptic messages. Besides, force quitting
on OS X is so much more elegant that OS 9 (or any previous Mac OS) I
sometimes force quit apps for fun! ;-)
-- Ryan
On Sunday, April 29, 2001, at 09:31 AM, <rosyna...> wrote:
> Sadly, it isn't a thing of the past. I have had MANY apps go into an
> infinite loop (rainbow cursor of death) which requires a force quit.
> This is the same outcome that would have been necessary in 9.1, only
> this time you can switch to other apps while in the loop.
>
> Ack, at 4/29/01, Jens Baumeister said:
>
>>> Not necessarily - one of the ways Classic applications could hang up
>>> the whole system was by getting into an infinite loop and never
>>> returning control to another application (or the Finder) again.
>>>
>>> That's something that should be a thing of the past with preemptive
>>> multitasking.
>
> --
> Sincerely,
> Rosyna Keller
> Technical Support/Holy Knight/Always needs a hug
>
> Unsanity: Unsane Tools for Insane People
> _______________________________________________
> MacOSX-dev mailing list
> <MacOSX-dev...>
> http://www.omnigroup.com/mailman/listinfo/macosx-dev
>
-
It IS the rainbow cursor of death if you have one comp connected to a
network or have a dynamic ip. It is the rainbow cursor o death if you
are unable to force quit an app or have to do it MANY times before it
works.
Force quitting apps is bad mojo. Remember, unix oses don't flash
cache to disk all the time (OS X does it every 30 secs luckily)
Ack, at 4/30/01, Ryan Dary said:
> This is hardly a good comparison. Either the whole system halts (OS
> 9.x) or just one app halts (OS X). And let's not call it the
> "rainbow cursor of death" just because some apps have errors and
> this is the default "progress" cursor. At least the whole screen
> doesn't turn blue and display 4 or 5 lines of cryptic messages.
> Besides, force quitting on OS X is so much more elegant that OS 9
> (or any previous Mac OS) I sometimes force quit apps for fun! ;-)
--
Sincerely,
Rosyna Keller
Technical Support/Holy Knight/Always needs a hug
Unsanity: Unsane Tools for Insane People -
On måndag, april 30, 2001, at 08:19 , Ryan Dary wrote:
> This is hardly a good comparison. Either the whole system halts (OS
> 9.x) or just one app halts (OS X). And let's not call it the "rainbow
> cursor of death" just because some apps have errors and this is the
> default "progress" cursor. At least the whole screen doesn't turn blue
> and display 4 or 5 lines of cryptic messages.
No, we have kernel panics for that purpose. Perhaps we should name them
kernel panics of death to give them better media coverage...
At least they are more subtle then the M$ BSOD - I usually have time to
quickly divert any onlookers attention and reboot... It is all about
saving face!
;)
j o a r -
On Sunday, April 29, 2001, at 07:50 PM, Rick Roe wrote:
>> Anybody knows anything about this really dismal iTunes performance?I have absolutely no Carbon apps open right now except the Finder (which
>
> Many Carbon apps seem to be wasting CPU cycles. It looks like the apps
> that
> are "quick and dirty" ports (which likely still do their own
> poll-for-event
> loops) suffer more than the ones that have had more OS X-targeted
> fine-tuning (and likely use native run loop services). But that's just a
> guess on my part.
I imagine is hardly a quick & dirty port) and iTunes skips quite often,
usually during times when there's bound to be lots of VM swapping (such
as compiling a program in PB) or using a CPU-heavy Aqua animation (like
trying to use the genie effect on a full-sized window).
More than anything, I think OS X in its current incarnation is too much
of a resource piggy. I have 256MB of RAM and OS X still pages quite a
bit without Classic open; I could open up Photoshop in OS 9 and have it
page hardly at all. Once Apple gets the size of the frameworks down,
people start fine-tuning their code and all the memory leaks get
plugged, things will get better. Actually, they can only get better....
Ryan
Ryan McGann
<mcgann...>
You have moved your mouse. Windows will now crash. -
On Sunday, April 29, 2001, at 06:34 , Chris Behm wrote:
> Actually, I'm not sure that you are seeing infinite loops. I'm curious
> to know if anyone else is experiencing the same thing I am and this may
> explain why you see the rainbow.
>
> You go to do something (say save a doc in Project Builder). Up comes
> the cursor (wait, where'd that come from?). Then a few seconds
> stretches on into more than a minute (sometimes many). Other
> applications "refuse" to launch (though you can still quit
> applications). Any of this sound familiar to anyone?
>
I mailed the projectbuilder list about this back in March and got the
hopeful sounding reply of
> I've seen this several times, both on my machine and others. I've spent
> some time investigating it, and the current theory is that Project
> Builder is hanging due to a kernel bug triggered by trying to swap in a
> VM page. I think a fix is in the works, but I'm not sure how it will be
> delivered.
>
> Anders
from Anders Bertelrud <anders...> but I've seen similar posts and
no other 'official' Apple responses since then.
It's a difficult bug to file as it's almost always possible to sample
the process as it seems to be waiting for a lock to come free. Any other
process that might touch it (like ps) also hangs.
I wonder whether it really has been fixed?
-- Gideon -
At 20:51 Uhr -0500 30.04.2001, Ryan McGann wrote:
> More than anything, I think OS X in its current incarnation is too
> much of a resource piggy. I have 256MB of RAM and OS X still pages
> quite a bit without Classic open; I could open up Photoshop in OS 9
> and have it page hardly at all. Once Apple gets the size of the
> frameworks down, people start fine-tuning their code and all the
> memory leaks get plugged, things will get better. Actually, they can
> only get better....
I wish that was true. But if it really happened this way, it would be
the first time in Computer history for such a thing to occur, I
believe. :( But I hope your dream comes true anyway.
<sarcasm>
Prepare for the possibility that things don´t get better at all...
unless of course you buy a new G4/1000 with 1 GB ram. Then it might
run at good speed, with few disk trashing (did I mention the RAID
array?).
</sarcasm>
Max
--
-----------------------------------------------
Max Horn
C++/ObjC/Java Developer
email: <mailto:<max...>
phone: (+49) 6151-494890 -
Am Samstag, 28. April 2001 um 17:37 schrieb Daniel Staudigel:
> It probably is because of non-full screen.
You were probably right. The new iTunes update allows full screen
display, and is considerably faster in this mode.
Bye
Uli
________________________________________________________
Uli Zappe <uli...>
Lorscher Straße 5 http://www.ritual.org
D-60489 Frankfurt Fon: +49-700-ULIZAPPE
Germany Fax: +49-700-ZAPPEFAX
________________________________________________________ -
Note: I'm a kernel weenie. I've been studying schedulers and VM
systems for a long time, for fun. This makes me a very uninteresting
person, and as a result, I resort to going to the gym four to five times
a week to make up for the fact that conversations with me can curdle the
milk in your tea.
On Sunday, April 29, 2001, at 04:36 , Rosyna wrote:
>> And I think on total, the drawbacks of cooperative outweight its
>> advantages (unless you live in a perfect world, where every programer
>> makes no mistakes, and hence writes perfect apps that never crash.
>> hahhahaha)
> That is protected memory, not multitasking.
While it's true that the use of MMU functionality to provide protected
memory is not necessarily linked to a preemptive scheduler, show me an
implementation. :)
>> With cooperative multitasking, if I run a lot of apps, any MP3 player
>> I have used so far at some point stops to play continually.
>
> Not the ones I use ;)
The point being that you cannot guarantee, in a cooperative multitasking
environment, that you will be granted the resources you demand.
Preemptive multitasking makes it easier to write time-critical systems
by allowing the user or application to inform the scheduler of their
needs.
Ideally, the only difference between a cooperative scheduler and a
preemptive one is that a preemptive one has a finer granularity. That's
*it*. Any behavioral differences noted by the end user which cannot be
explained by the behavior of the applications can be considered as a
flaw in the system; this is true on both sides.
In a cooperative environment, applications which fail to yield are at
fault. In a preemptive environment, applications which schedule
themselves improperly are at fault. The difference is that a preemptive
environment SHOULD allow easier rectification of the situation and does
not necessarily require an application change to change the scheduling
environment.
The fact that you're having an end-user experience issue does not
necessarily point at the choice of preemptive scheduling being a
mistake. 99% of humanity will happily disagree with that assessment,
and with good arguments and reasons.
> Yes, but with TRUE preemptive multitasking, it gets the same time as
> all other processes. This could actually cause it to skip more.
This is not true. Preemptive multitasking does not mean equivalent
timeslices. There are many, many ways of providing these features:
process/task prioritization is the most common one that end-users see,
but one of the most important activities that take place behind the
scenes is the process of priority inversion and other forms of handling
I/O and blocking calls.
The advantages go deeper than the skin you're looking at. Good
throughput to device layers is one of the holy grails of good preemptive
kernels. In a *single-tasking* environment, achieving that is simple.
In a co-op, it's not as simple. Preemptive brings the problem to a more
manageable space.
> On OS X, this definitely isn't the case. All apps have the same
> priority by default. This is sort of the opposite of preemptive.
This is a flaw in the kernel; one which has already been rectified. The
ability to set priorities will inevitably allow someone, maybe even
Apple, to write a tool which allows you to set scheduling priority on
your applications, or even to allow the "frontmost application" to get a
priority bump. Or, more importantly, to *really* put that huge render
into the background.
> Yes, there should be NO reason a background app needs text input.
Drop the idea of "foreground" versus "background" - that only works on a
limited set of real-world applications. And replace "text input" for
any input stream, whether from a device or a network port, because
they're essentially the same problem.
> In OS X, IE can still freeze the machine (crash the window manager)
And once Carbon reaches 99% stability and parity with Cocoa, I would
expect that freezing like that will become difficult, if not impossible,
to reproduce. I think we can all clearly point this out as a flaw in an
application and its core APIs rather than being something which is the
result of a choice for preemptive multitasking.
In short, and IMO: Preemptive multitasking is a better solution to 99%
of any everyday user's real-world usage problems, whether that be your
grandmother, your professional programmer, your stock trader, or your
daughter. The problem is that 90% of that 90% isn't visible to the
end-user unless he/she looks more carefully.
:plur,
Greg -
On Sunday, April 29, 2001, at 05:15 , Rosyna wrote:
> Ack, at 4/29/01, <tlr...> said:
>
>> And it never sleep (except when I wake up the Cube, but I believe it
>> due to the external speakers), THANKS TO PREEMPTIVE MULTITASKING!!!!
>
> All audio objectts skip when waking from even monitor sleep.
Neither of which have anything to do with preemptive multitasking, quite
frankly, and everything to do with a young kernel.
> Isn't this protected memory again?
One's ability to switch to another application and function normally
when an application refuses to respond is the preemptive core; protected
memory prevents an application from trashing someone else's memory, but
does not prevent the kernel from being fed crap and crashing. Two less
problems than you used to have under OS9. -
I don't think it has anything to do with carbon. i use a lot of
carbon apps, they all crash sometime or another, but NONE take the
comp with it other than IE. And project builder, a cocoa app, has
taken the window manager a few times.
Ack, at 4/30/01, Gregory Block said:
> And once Carbon reaches 99% stability and parity with Cocoa, I would
> expect that freezing like that will become difficult, if not
> impossible, to reproduce. I think we can all clearly point this out
> as a flaw in an application and its core APIs rather than being
> something which is the result of a choice for preemptive
> multitasking.
--
Sincerely,
Rosyna Keller
Technical Support/Holy Knight/Always needs a hug
Unsanity: Unsane Tools for Insane People -
And the bad news is...it still happens in 1.0.2 (happened to me last night)
:-(
Gideon King
> Actually, I'm not sure that you are seeing infinite loops. I'm curious
> to know if anyone else is experiencing the same thing I am and this may
> explain why you see the rainbow.
>
> You go to do something (say save a doc in Project Builder). Up comes
> the cursor (wait, where'd that come from?). Then a few seconds
> stretches on into more than a minute (sometimes many). Other
> applications "refuse" to launch (though you can still quit
> applications). Any of this sound familiar to anyone?
>
-----------------------------------------------
FREE! The World's Best Email Address @email.com
Reserve your name now at http://www.email.com -
On Wednesday, May 2, 2001, at 06:59 , Rosyna wrote:
> I don't think it has anything to do with carbon. i use a lot of carbonAh, but parts of Cocoa are now built on top of carbon for instance Cocoa
> apps, they all crash sometime or another, but NONE take the comp with
> it other than IE. And project builder, a cocoa app, has taken the
> window manager a few times.
>
menus go through Carbon's Menu manager. Carbon is independent of Cocoa
but Cocoa is not independent of Carbon. So the behavior could certainly
be caused by Carbon especially given its relative immaturity.
Dave
--
Chaos Assembly Werks
"Imagination is more important than knowledge."
- Albert Einstein -
Firstly, excellent description of the benfits of preemptive memory
management. Having just completed Operating Systems 101 it's nice to be
able to understand all of it too. :)
>> On OS X, this definitely isn't the case. All apps have the same
>> priority by default. This is sort of the opposite of preemptive.
>
> This is a flaw in the kernel; one which has already been rectified.
I didn't think that this had been implemented in Darwin yet. I haven't
payed much attention to darwin-dev of late though. Are you certain this
has been implemented? I would be quite interested in this capability
and there are already some UNIX based tools to utilize it available
(nice which comes with OSX GM).
> Greg
Adrian Sutton
**************************************************************
Email: <z1419539...> Ph: 3714 4635
Don't go around saying the world owes you a living.
The world owe's you nothing - it was here first.
-- Mark Twain.
************************************************************** -
On Monday, April 30, 2001, at 07:05 PM, Gregory Block wrote:
> On Sunday, April 29, 2001, at 04:36 , Rosyna wrote:
>>> And I think on total, the drawbacks of cooperative outweight its
>>> advantages (unless you live in a perfect world, where every programer
>>> makes no mistakes, and hence writes perfect apps that never crash.
>>> hahhahaha)
>> That is protected memory, not multitasking.
>
> While it's true that the use of MMU functionality to provide protected
> memory is not necessarily linked to a preemptive scheduler, show me an
> implementation. :)
Of a preemptitive scheduler without protected or virtual memory? The
Amiga OS, of course.
Very predictable, round-robin time slicing algorithm with fixed
priorities. Coupled with a message driven user interface it was
extremely responsive, even on slow machines. IIRC, "Intuition" ran at a
high priority and doled out messages (very cheap to implement when there
is no memory protection) to the tasks. This meant that even under heavy
load, user action would be handled immediately. The simple scheduler and
minimal process states also meant that slices could be kept short,
further decreasing latency.
The obvious downsides where that you pretty much had to manually manage
priorities for big jobs, and the crashes that plague all systems without
resource protection.
> In short, and IMO: Preemptive multitasking is a better solution to 99%
> of any everyday user's real-world usage problems, whether that be your
> grandmother, your professional programmer, your stock trader, or your
> daughter. The problem is that 90% of that 90% isn't visible to the
> end-user unless he/she looks more carefully.
Note though, that the lack of priority management functionality in Mac
OS X is a huge handicap. Having a lower priority on non-interactive
tasks can make a huge difference in responsiveness. The scheduler tries
to manage that automatically, but it seems like it could need some help.
Regards,
John Hornkvist -
>That least acrounding to the Apple Developers it has been fixed in 128 of the kernel (124 is in Mac OS X 10.0.2).
> Firstly, excellent description of the benfits of preemptive memory
> management. Having just completed Operating Systems 101 it's nice to be
> able to understand all of it too. :)
>
>>> On OS X, this definitely isn't the case. All apps have the same
>>> priority by default. This is sort of the opposite of preemptive.
>>
>> This is a flaw in the kernel; one which has already been rectified.
>
> I didn't think that this had been implemented in Darwin yet. I haven't
> payed much attention to darwin-dev of late though. Are you certain this
> has been implemented? I would be quite interested in this capability
> and there are already some UNIX based tools to utilize it available
> (nice which comes with OSX GM).
Thanks,
Andrew Pinski
>
>> Greg
>
> Adrian Sutton
>
> **************************************************************
> Email: <z1419539...> Ph: 3714 4635
> Don't go around saying the world owes you a living.
> The world owe's you nothing - it was here first.
> -- Mark Twain.
> **************************************************************
> _______________________________________________
> MacOSX-dev mailing list
> <MacOSX-dev...>
> http://www.omnigroup.com/mailman/listinfo/macosx-dev
>
>
-
I am somewhat fearful of app designers being able to define or request
priority in the scheduler. What about those boneheads that might make
their app appear to be so important that the rest of the computer is
sluggish. Of course someone could say, quit using that app, but I don't
think that is my point.
Isn't there some way or some algorithm to determine the needs of the
application? That would be ideal right? I don't know, I just hate to
see what could happen to our preemptive multitasking environment if
abused.
-- Ryan
On Monday, April 30, 2001, at 10:05 AM, <gblock...> wrote:
>>> On OS X, this definitely isn't the case. All apps have the same
>>> priority by default. This is sort of the opposite of preemptive.
>
> This is a flaw in the kernel; one which has already been rectified. The
> ability to set priorities will inevitably allow someone, maybe even
> Apple, to write a tool which allows you to set scheduling priority on
> your applications, or even to allow the "frontmost application" to get a
> priority bump. Or, more importantly, to *really* put that huge render
> into the background.
-
Am Freitag, 4. Mai 2001 um 17:41 schrieb Ryan Dary:
> I am somewhat fearful of app designers being able to define or request
> priority in the scheduler. What about those boneheads that might make
> their app appear to be so important that the rest of the computer is
> sluggish.
This cannot happen. Only software in "privileged mode" is allowed
to increase process priorities. This means only the administrator
or the operating system itself can request more CPU resources.
As a "normal" user you can only decrease the priorities of your
programs.
> Isn't there some way or some algorithm to determine the needs of the
> application?
This is impossible in advance. But some operating systems
monitor all applications at runtime and then decide to
dynamically increase or decrease priorities. However, it's
controversial if that's really a big advantage. In practice,
simple schedulers are often as effective as the ones with
complex optimization strategies.
Marcel
--
Dr. Marcel Bresink, Ringstr. 21, 56630 Kretz, Germany
Fon: +49-2632-953150 Fax: -953151 http://www.bresink.de/ -
I am confused how they would both be about the same in speed. Do you
mean that the process of trying to discover the priorities (at run-time)
for the processes actually decreases performance to the point where it
is comparable to a scheduler without the optimization process?
That is quite interesting.
So, what are some examples of applications which would be beneficial to
decrease their own priority? And would this be something discussed
(future versions) in the Aqua Interface guidelines so that developers
can adjust this in their apps?
Of course you can't speak for what will or won't be put into the HIG,
however I simply mean to ask if you (or anyone) believes that this would
be published so that developers could take this into consideration when
building their applications.
-- Ryan
On Friday, May 4, 2001, at 10:04 AM, <marcel...> wrote:
>>> Isn't there some way or some algorithm to determine the needs of the
>>> application?
>
> This is impossible in advance. But some operating systems
> monitor all applications at runtime and then decide to
> dynamically increase or decrease priorities. However, it's
> controversial if that's really a big advantage. In practice,
> simple schedulers are often as effective as the ones with
> complex optimization strategies.
>
> Marcel
-
On Friday, May 4, 2001, at 05:41 , Ryan Dary wrote:
> I am somewhat fearful of app designers being able to define or request
> priority in the scheduler. What about those boneheads that might make
> their app appear to be so important that the rest of the computer is
> sluggish. Of course someone could say, quit using that app, but I don't
> think that is my point.
>
> Isn't there some way or some algorithm to determine the needs of the
> application? That would be ideal right? I don't know, I just hate to
> see what could happen to our preemptive multitasking environment if
> abused.
It's the same like in Mac OS 9. Some applications (like an old IE version
and Langenscheidt's PC-Bibliothek) slow the whole system down a lot. The
result? Users complain and don't use it, or modify it to use less CPU
(there's a tool for Mac OS 9 that does this). It's just that simple.
andy
--
Description forthcoming. -
On Tuesday, May 1, 2001, at 03:27 AM, Max Horn wrote:
> At 20:51 Uhr -0500 30.04.2001, Ryan McGann wrote:
>> More than anything, I think OS X in its current incarnation is too
>> much of a resource piggy. I have 256MB of RAM and OS X still pages
>> quite a bit without Classic open; I could open up Photoshop in OS 9
>> and have it page hardly at all. Once Apple gets the size of the
>> frameworks down, people start fine-tuning their code and all the
>> memory leaks get plugged, things will get better. Actually, they can
>> only get better....
>
> I wish that was true. But if it really happened this way, it would be
> the first time in Computer history for such a thing to occur, I
> believe. :( But I hope your dream comes true anyway.
>
> <sarcasm>
> Prepare for the possibility that things don´t get better at all...
> unless of course you buy a new G4/1000 with 1 GB ram. Then it might run
> at good speed, with few disk trashing (did I mention the RAID array?).
> </sarcasm>
Actually, if memory is really a concern or swapping a problem. Go check
out memory prices. Just a quick look at www.pricescan.com, and you can
get 256 M DIMMs for as little as $60. A short time ago, I tripled my
memory to 768M for just $200. I haven't swapped since. Memory is cheap,
so it really isn't the stumbling block. -
> I am confused how they would both be about the same in speed. Do you
> mean that the process of trying to discover the priorities (at
> run-time) for the processes actually decreases performance to the point
> where it is comparable to a scheduler without the optimization process?
No, that's not the reason. Note that there a different
"speeds" involved here. If you change priorities, there
always will be processes that have an advantage at the
expense of others. On an interactive workstation like the
Mac, a simple strategy of dynamically changing priorities
is sufficient: The OS should prioritize the foreground process
and the processes doing a lot of I/O operations. What really
counts here is how the user perceives speed, which could be
expressed as the average response time of the foreground
application.
A special case are processes that have real-time demands
like burning a CD or playing a movie or MP3. Here, you can
"guess" in advance that a higher priority might be helpful.
But this comes back to your original question: How should
the OS detect a multimedia application and how can we prevent
abuse of the detection mechanism?
> So, what are some examples of applications which would be beneficial to
> decrease their own priority?
There is no need to change priorities for a general-purpose
application. Decreasing priorities makes sense for jobs that
put a load of 100 percent on the CPU(s) but are not important
for user interaction. Examples are screen savers, offline
compression of QuickTime movies, <SETI...>, RC5 contest,
creating frames for a computer animation, etc. Jobs that
don't need user intervention and can run in the background
for a long time.
Marcel
--
Dr. Marcel Bresink, Ringstr. 21, 56630 Kretz, Germany
Fon: +49-2632-953150 Fax: -953151 http://www.bresink.de/ -
On Friday, May 4, 2001, at 04:41 , Ryan Dary wrote:
> I am somewhat fearful of app designers being able to define or request
> priority in the scheduler. What about those
Of course, if I were writing SETI, and *didn't* set it up as a
lowest-priority task in the scheduler, my users would rip my head off
and pee on what's left. Or if I'm writing a multithreaded application
where I know I want certain operations to take place at a lower priority
than the user's own actions, I can do so easily. There are good reasons
to use it.
> boneheads that might make their app appear to be so important that the
> rest of the computer is sluggish. Of course someone could say, quit
> using that app, but I don't think that is my point.
>
> Isn't there some way or some algorithm to determine the needs of the
> application? That would be ideal right? I don't know, I just hate to
> see what could happen to our preemptive multitasking environment if
> abused.
If abused, at absolute worst, the kernel would still be given back the
CPU long enough to allow someone to do something about that runaway
process. Schedulers often assure that every task gets some CPU,
regardless of its priority to ensure that stuff like this is solvable.
So no matter what happens, it may be sluggish, but in theory, you can
regain control. The best thing about preemptive multitasking isn't the
preempting on friendly tasks, it's the preempting on the unfriendly ones.
Yes, someone probably should try to figure out what Apple's goals are,
as far as the kernel's scheduling behavior, and write up some tests that
tell us all how far off the mark we currently are - but in all honesty,
even a bad preemptive scheduler is going to be thousands of times better
than a coop system if it allows basic prioritization and priority
inversion on I/O.
It's a good thing. It may be scary and appear, for now, to be hideously
techie, but it's a good thing. Believe that first. Given a good
foundation, you can make something easy to use. Let's get that
foundation, shall we?
:plur,
Greg -
On Friday, May 4, 2001, at 06:16 , Ryan Dary wrote:
> I am confused how they would both be about the same in speed. Do you
> mean that the process of trying to discover the priorities (at
> run-time) for the processes actually decreases performance to the point
> where it is comparable to a scheduler without the optimization process?
Scheduling happens often. Really often. Complex schedulers build
tables every now and then to keep track of how much it should skew
what's going on; but those calculations are often expensive enough that
you've wasted valuable CPU time that could have been given to another
task.
> So, what are some examples of applications which would be beneficial to
> decrease their own priority? And would this be something discussed
> (future versions) in the Aqua Interface guidelines so that developers
> can adjust this in their apps?
Really, any non-UI task should be lowered in comparison to the UI task
if it's not I/O bound. Things that are disk-bound, for example, are
going to get priority inverted around and played with by the long seek
times regardless, so they're not likely to do the user irreparable
damage. Spawning a thread to load a file is probably a waste.
Spawning a thread to put a watermark on that image is a good idea,
however. Spawning a thread to raytrace. Or to render some PostScript.
Anything that uses lots of CPU that might cause the user's experience to
be reduced, where the action being taken is reversible or non-modal. It
insures that "interactive" tasks have priority over "non-interactive" or
"batch" tasks.
Lowest priority goes to batch scheduling, screensavers, your SETI
clients. Highest priorities go to UI handling and application main
loops.
> Of course you can't speak for what will or won't be put into the HIG,
> however I simply mean to ask if you (or anyone) believes that this
> would be published so that developers could take this into
> consideration when building their applications.
Most of it's common sense, and well documented, so I imagine that the
HIG will be very clear on how this should work. There's obviously some
gray area around the exact figures, but the principle at least can be
explained in depth.
:plur,
Greg -
On fredag, maj 4, 2001, at 03:23 , Andrew Pinski wrote:
>>>> On OS X, this definitely isn't the case. All apps have the same
>>>> priority by default. This is sort of the opposite of preemptive.
>>> This is a flaw in the kernel; one which has already been rectified.
>> I didn't think that this had been implemented in Darwin yet. I haven't
>> payed much attention to darwin-dev of late though. Are you certain
>> this
>> has been implemented? I would be quite interested in this capability
>> and there are already some UNIX based tools to utilize it available
>> (nice which comes with OSX GM).
> That least acrounding to the Apple Developers it has been fixed in 128
> of the kernel (124 is in Mac OS X 10.0.2).
Scott, you'll compile and package a replacement kernel of this version
for download on Stepwise, right? ;)
j o a r -
On Friday, May 4, 2001, at 11:31 , Adrian Sutton wrote:
> I didn't think that this had been implemented in Darwin yet. I haven't
> payed much attention to darwin-dev of late though. Are you certain
> this has been implemented? I would be quite interested in this
> capability and there are already some UNIX based tools to utilize it
> available (nice which comes with OSX GM).
Just because we can't see it doesn't mean it isn't fixed. :) Xnu-128.
Once something like that has been finished, Space.dock, for example,
could be modified to lower the priority of offscreen applications by 1;
or to do that to 'background' applications. Mind you, I'd *never* use
such functionality, but it's there for others if they felt compelled to
do so. Well designed applications should not be running CPU-intensive
operations on main threads at standard priority.
Space.dock probably makes a good playground for this modification, as
well.
:plur,
Greg -
Can you set the priorities of tasks, if so how, from within the thread
or externally only? there was no such documentation on NSThread.
Daniel Staudigel
---------------
How to fly: Find a nice big cliff, jump off, and miss the ground! Easy
enough!
