OSX amazes me - and other implications..

Posted:
in macOS edited January 2014
Just upgraded my Powermac G4 at work, from a single 867 to a Dual gig, and all I can say is, "WOW!" It feels twice as fast in all areas - startup, launch time, responsiveness.



Here's the kicker - I did the same upgrade for another dude in our company, who's been running OS9 (see my earlier rant). After messing with it, it felt exactly the same. No difference in speed.



The way OSX takes advantage of two processors is just amazing.



Now, I wonder what that means for Intel. To the best of my knowledge, Windows is not written to take advantage of two processors, and they're still on CISC ones at that. Seems like as their processors get faster, a)no one's going to notice, and b)their engineers are going to run out of headroom soon.
«1

Comments

  • Reply 1 of 23
    scottscott Posts: 7,431member
    I'd be the OS 9 one "feels" the same due to OS 9's excellent handling on user events. Something OS X is still lacking.



    So what you are demonstrating is in fact a failure of OS X. OS X needs two CPUs to have good UI responsiveness where as OS 9 has it on just one.



    [ 01-04-2003: Message edited by: Scott ]</p>
  • Reply 2 of 23
    defiantdefiant Posts: 4,876member
    oh no. here we go again...
  • Reply 3 of 23
    Well, point taken.



    I will agree with you, OSX is a tad slow on my iBook 600. But be patient. I've been doing back and forth between our new Dual Gig G4s, (one has OS9, the other OSX) and honestly, they both feel just as fast.



    All I can say is that our next batch of faster Dual G4s will go to our OSX users. OS9 people can keep their existing slow machines, due to the superiority of OS9's handling of user events.
  • Reply 4 of 23
    [quote]Originally posted by francisG3:

    <strong>OS9 people can keep their existing slow machines, due to the superiority of OS9's handling of user events.</strong><hr></blockquote>What Scott is forgetting to mention (or perhaps intentionally omitting?) is that the way OS9 handles many events completely halts other background tasks. This is one reason why OS9 sometimes initially feels more responsive. There are other issues like OSX's resource-gobbling window server, but this is the most prevalent reason.



    Ever notice how practically ALL tasks freeze up when you click a menu or drag a window outline in OS9? That is the price you pay for that responsiveness.



    "Excellent handling on user events" indeed. <img src="graemlins/bugeye.gif" border="0" alt="[Skeptical]" />
  • Reply 5 of 23
    jlljll Posts: 2,713member
    Is Scott the same as Scott_H?
  • Reply 6 of 23
    buonrottobuonrotto Posts: 6,368member
    Yes, but he is sort of right, at least in the case of a lot of Carbon apps. Many still do not use Carbon events correctly, and it hurts their responsiveness quite a bit. Ironically, it's because they're still trying to use older "Classic" input methods behind the scenes.



    brad is also right that since OS x was designed like any unix to share processing power, no single process will hog the CPU like OS 9 did. Right now, I'm scanning a 40 MB image that will export to TIFFany while playing a stream in iTunes and writing this at the same time in OmniWeb. Switching from app to app is definitely slower than in OS 9. Ironically, I think what slows things down is OW's page rendering, not the other processes.
  • Reply 7 of 23
    kickahakickaha Posts: 8,760member
    Welcome to cooperative vs preemptive tasking.



    Cooperative: each app decides how many CPU cycles it will give to other apps. If one decides to be a hog, the others are screwed. Example: MacOS Classic. Made *perfect* sense on an 8MHz 68000 with 129KB of RAM, to optimize the GUI speed.



    Preemptive: the OS decides how much each task gets of the CPU, and enforces it. If one app needs more cycles like NOW, unless the OS decides that it can do so equitably, that app can be starved. Example: MacOS X. Makes *much* more sense on anything more powerful than a MacIIsi.



    Bottom line: Preemptive multitasking is almost *ALWAYS* going to result in lesser performance for the frontmost app, in small timeslices... the kind that GUIs need to be smooth. But it kicks cooperative multitasking's buttocks when it comes to doing more than one thing at once.



    So... OS9 will be snappier in the short term for the GUI. OS X will be more robust for folks doing more than one thing at once... which consists of most folks.



    I'll take the latter, thanks.



    So... OS X can use multiple CPUs *EXCELLENTLY*. As more CPU cycles are available, any and all apps benefit, including the GUI speed across the board. OS 9... not so much. First app that wants GUI responsiveness will lock out every other cycle.



    But golly gee, that one app shore is speedy, ain't it Bubba?



    [ 01-04-2003: Message edited by: Kickaha ]</p>
  • Reply 8 of 23
    defiantdefiant Posts: 4,876member
    open PS, work, save, quit it, open PrintCenter, print, wait to finish, open iTunes, listen 1 hour, quit iTunes, open OW, browse AI, quit OW, open iTunes, listen to music, quit iTunes, open OW, post on AI, quit OW, open mail, read mail, quit mail, open iTunes, listen to another 5 minutes, quit iTunes, die.
  • Reply 9 of 23
    Giving I/O-bound tasks short timeslices and getting them out of the way first (if that's how OS X does it) should translate to shorter response times in dealing with keyboard and mouse events as well as more processing time for CPU-intensive apps (though not just the frontmost one as in OS 9), shouldn't it? What you're saying contradicts what I thought I knew, from way back in 1996. Preemptive multitasking was touted as the big reason why BeOS was 'so much more responsive' than Mac OS. And now it's the big reason why Mac OS X is 'so unresponsive'.



    I finally got the chance use on an Amelio-era Power Mac, and it seemed responsive no matter how many teapots were spinning. I came up with some ideas:



    1) The CPU monitor would spike whenever a GUI event occurred -- does Mac OS X try to avoid that inequity?



    2) Actually drawing the interface did get slower -- since OS X only lets you see the final product of any graphics operation, could it actually be responsive and just not look that way?



    Please feel free to shoot those down at your convenience.
  • Reply 10 of 23
    amorphamorph Posts: 7,112member
    First: Every UNIX I can remember gives the current foreground process a higher priority than every other user process. OS X is no exception here. Apple can diddle with how much higher that priority is - and I think they have over the various system releases - but it's always higher as a matter of common-sense design.



    That said, there are several factors contributing to responsiveness. First, there is responsiveness within an application. In OS 9, if the frontmost application is idle, any widget that application is responsible for (including menus) will respond instantly, because the entire machine is sitting there waiting for you to do something. In OS X, the system might be doing something else when you click on a widget, and depending on load it might take a few milliseconds to get around to reacting. This difference should not, however, result in a difference that a human operator will notice.



    Then there's responsiveness when the frontmost application is doing something. In OS 9, what happens if you set an application grinding away at a task and then try to pull down a menu? The menu might take a good while to come down, if it comes down at all before the task finishes, and then everything else grinds to a halt while the menu's down. In OS X, the menu comes down more or less as quickly as it always will, and other processing continues more or less as it had. (If the application stops working, that's a threading issue within the application, not a flaw in the multitasking model).



    Then there's responsiveness between applications. OS 9's pretty quick if the frontmost application isn't doing anything, and really slow if it is - because OS 9 can't switch tasks while the frontmost task is hogging the CPU. Once it can, it has to keep so much of the application in RAM that it switches pretty promptly. OS X can switch almost instantaneously, but it can appear to be slow if a substantial amount of the application being switched to has been swapped out to disk, and/or if a substantial amount of the application being switched from has to be swapped out to make room (this is one major reason why RAM Is Good in OS X).



    Then there is optimization. In OS X, the OS receives every event, and decides who should get it. The event then trickles back up to the appropriate responder. This enables a structure that can help responsiveness in some ways (more below), but if it's not written to be as fast as possible then there can be a perceivable lag as the event goes all the way down, then all the way back up again, before it's processed.



    There's also the issue of efficiency. In OS 9, event handling worked this way: The frontmost application used the GetNextEvent() function to ask the Event Manager for the next event, and got either the next event or a "no" if there weren't any. There was even a variant, WaitNextEvent(), which essentially stopped the application and polled the Event Manager until it did get an event. It's a leftover from the halcyon days before multitasking made everything complicated. This model sets up a constant dialog between the application and the OS: "Do I have an event?" "No." "How about now?" "No." "Now? "No." "Aw come on. There's gotta be one." "No." Every question is an interruption, and the OS has to go and figure out the answer. Additionally, if an application has ten events queued up, it has to ask the OS eleven times to get them all (the last one is to get the "no" event that tells it there are no more events in the queue).



    In OS X, the preferred model is that an application simply registers itself with the OS: "Here's a mailbox. When you have news for me, put it in there." When the OS receives an event for an application, it puts it in the application queue (mailbox) and goes about its business. When the application gets around to it, it checks its queue, and processes any events there on its own time. This should greatly increase responsiveness at the system level, although it leaves open the possibility that an individual application might be unresponsive (because it hasn't gotten around to checking its mailbox in a while). But OS X grandfathered in the old way for legacy compatibility, and while the "chatty" model was something of a burden under OS 9, it cripples OS X: The OS is no longer dormant until awakened to ask for an event: It now has to drop everything and spend time answering a constant barrage of questions. This is why early releases of iTunes and AppleWorks 6 slowed OS X down so much: In its initial incarnation, AW was polling OS X eight thousand times per second just to ask if there were any events!



    Finally, there's threading. BeOS was responsive in large part because the interface was heavily threaded. To get the difference, imagine two scenarios: First, there's your single-threaded application. This is a guy who does everything himself. If he's really busy on a project that has to be done yesterday, he might not check his mailbox for a while. Now, imagine that someone gets the guy a secretary. Whether or not he's incredibly busy, the secretary gets his mail quickly, and is able to respond (or react) to most of them independently. In BeOS, every application has at least one secretary managing the interface, so that interface response time is quick no matter how busy the application is. This is an imperfect metaphor that shouldn't be taken farther than I've taken it, but it illustrates the benefit.



    In OS X, it's up to the application to handle threading.



    Finally, there's the issue of dynamism. In OS 9, most everything was static and hard-wired, which made it fragile and inflexible, but also fast. In OS X, much more is dynamic and built on the fly, which is far more flexible at the cost of speed and/or memory. This is one area where I think many of OS X's speed gains have come from: Tightening up the dynamic parts of the OS.



    I hope that's all clear and correct.



    [ 01-05-2003: Message edited by: Amorph ]</p>
  • Reply 11 of 23
    reynardreynard Posts: 160member
    Kichaha, Brad, and especially, Amorph,

    I never will understand well things like operating systems nor processors. So would you all restate your posts in another way so they could be more accessible to me?



    Just kidding. Seriously, your statements have made me realize how my needs have changed over just one year. In OS9, I was basically doing one thing. But now I always have my browser going, iTunes, and I may be burning a CD. I am not a "power user" so I am probably a reflection of what is happening to average users. We are simply doing more things on our computers. I better understand the need for OSX.



    BTW, I've heard that OSX is not as "snappy" as Windows XP. And my kids computers(Wintel) do seem to bear that out. But even with our lagging processors, are our Macs relatively less slow in terms of multi-tasking? That is, is OSX more competitive in terms of tasks running in the background? If I'm not being clear perhaps an example will help: If I'm browsing the Internet and burning a CD, would OSX compete decently with XP? Better than navigating the interface my suggest?
  • Reply 12 of 23
    I have a rudimentary understanding of OS concepts, but I didn't know the degree to which they could influence the end user (like Classic vs. Carbon events). I should read up on that. Thanks, Amorph.
  • Reply 13 of 23
    zapchudzapchud Posts: 844member
    I think this huge (sorry ) picture is a pretty good example on multitasking in OS X:

    <a href="http://home.no/paroxysm/dl/full_load.jpg"; target="_blank">http://home.no/paroxysm/dl/full_load.jpg</a>;



    What's really happening?

    ?2 DivX encodes by ffmpeg in Terminal

    ?Radial blur @ best quality on a 25MB image

    ?2 DivX movies playing smoothly

    ?Mp3 playing

    ?All my regular Web-applications

    ?Top-command running in another Terminal

    ?Some apps idling



    And the best is that the GUI is still responsive and snappy as hell



    Try this in OS 9



    [gah! thumbnail it! - Brad]



    [ 01-06-2003: Message edited by: Brad ]</p>
  • Reply 14 of 23
    pyr3pyr3 Posts: 946member
    [quote]Originally posted by r-0X#Zapchud:

    <strong>I think this huge (sorry ) picture is a pretty good example on multitasking in OS X:



    What's really happening?

    ?2 DivX encodes by ffmpeg in Terminal

    ?Radial blur @ best quality on a 25MB image

    ?2 DivX movies playing smoothly

    ?Mp3 playing

    ?All my regular Web-applications

    ?Top-command running in another Terminal

    ?Some apps idling



    And the best is that the GUI is still responsive and snappy as hell



    Try this in OS 9 </strong><hr></blockquote>



    What is that IRC app that you are running? What is that chat looking app (with the 'hi' icon in the dock I assume)? I'm thinking it's some sort of Jabber client ?
  • Reply 15 of 23
    zapchudzapchud Posts: 844member
    bleh-double post.



    [ 01-06-2003: Message edited by: r-0X#Zapchud ]</p>
  • Reply 16 of 23
    zapchudzapchud Posts: 844member
    [quote]Originally posted by pyr3:

    <strong>



    What is that IRC app that you are running? What is that chat looking app (with the 'hi' icon in the dock I assume)? I'm thinking it's some sort of Jabber client ?</strong><hr></blockquote>



    The IRC-client is called "iRC", the other IM-app is Proteus "metallifized", which can be done with a little <a href="http://www.haxies.com/ape/"; target="_blank">haxie</a>.



    Both excellent apps IMO.
  • Reply 17 of 23
    pyr3pyr3 Posts: 946member
    [quote]Originally posted by r-0X#Zapchud:

    <strong>



    The IRC-client is called "iRC", the other IM-app is Proteus "metallifized", which can be done with a little <a href="http://www.haxies.com/ape/"; target="_blank">haxie</a>.



    Both excellent apps IMO.</strong><hr></blockquote>



    Bleh, proteus. Do you have a website for this 'iRC' client. I don't want to risk searching google for it since 'irc' will have more results than I care to sift through.



    [edit : Nevermind, I decided that this one time it was ok to use versiontracker.com ... I've vowed not to use it since I'm required to click a million and a half times* to get to any download or even to the 'develop web page'



    *your results may vary]



    [ 01-06-2003: Message edited by: pyr3 ]</p>
  • Reply 18 of 23
    [quote]Originally posted by pyr3:

    <strong>



    [edit : Nevermind, I decided that this one time it was ok to use versiontracker.com ... I've vowed not to use it since I'm required to click a million and a half times* to get to any download or even to the 'develop web page'</strong><hr></blockquote>



    <a href="http://www.macupdate.com"; target="_blank">www.macupdate.com</a>



    One-click download. Greatest invention of the 21st century. <img src="graemlins/lol.gif" border="0" alt="[Laughing]" />
  • Reply 19 of 23
    engpjpengpjp Posts: 124member
    [quote]Originally posted by Defiant:

    <strong>open PS, work, save, quit it, open PrintCenter, print, wait to finish, open iTunes, listen 1 hour, quit iTunes, open OW, browse AI, quit OW, open iTunes, listen to music, quit iTunes, open OW, post on AI, quit OW, open mail, read mail, quit mail, open iTunes, listen to another 5 minutes, quit iTunes, die. </strong><hr></blockquote>



    Invalid argument. These discussions nearly ALWAYS ignore the fact that near to all Mac applications behave according to rules, as far as cycle sharing goes. It's a cinch to use multiple applications concurrently - I do it all the time. However, I agree that the two multitasking strategies advantage two different work methods: those that work with few applications at the same time will prefer OS9; those having a number of automated tasks (ripping, compressing, downloading, replaying, rendering) running concurrently and demanding the same level of computation will opt for OSX and preemptiveness.



    engpjp
  • Reply 20 of 23
    defiantdefiant Posts: 4,876member
    I was making a cynical joke. I put it to the extreme.
Sign In or Register to comment.