...if it was encoding mp3's in the background, it's quite likely it was doing considerable HD accessing. This is not to say the thoughput was being swamped. This is just to say that frequent IDE HD operations tend to make everything choppy and inconsistent when combined with other tasks, no matter how multithreaded your apps are or PE-MT'd your OS is. It's just the nature of IDE, IMO. IDE places demands on the CPU, possibly high priority requests, due to the sensitive nature of error-free writing on a magnetic medium. That's just my theory, backed by consistent observations of similar, real-use situations. Possibly things may behave differently on a SCSI-based setup, but upon further recollection, I've seen this behavior there, too. Could have just been a "not high performance" SCSI controller, though.
A Windows machine will fall to this behavior just as well. Get 3 or 4 long HD operations going on at once, and you will see a lot of the "nominal" OS responsiveness get choppy.
I can't believe I'm the first one to say this -- the original poster isn't (just) a non-techy, he's also very likely a troll. His claims are highly dubious.
Window resizing latency will, on the other hand, continue to be bothersome.
An "illusion" of live resizing is better than what OSX gives.
Absolutely, and that's why I identified OS X's approach as a problem, and the illusion as a solution.
In the post you quoted, I was arguing against the claim that systems were powerful enough to instantaneously reflow documents, and so OS X was somehow deficient. Maybe it does need a little bit of work (the average 30%-40% speed increases reported in Panther had to come from somewhere) but Apple can "solve" the problem the same way MS did. It's a pretty clever hack.
But it's not truly live resizing, which is the issue I was responding to in my second post (the one you quoted).
I find this discussion fascinating. My G4 400mhz machine is quite fast and up til now the only lag I've noticed is because I've got a lot of system hacks installed. I never bothered to watch my cursor when I was using it to scroll since most times I either use the page up and down buttons or the scroll wheel on my mouse to do so. I'm also usually too busy watching what I'm scrolling past to bother checking if the mouse is keeping up. Perhaps what we have here is a case of the glass is half full or half empty. In my case I don't care much since while you all are fighting over whether it's half full or half empty I've picked the glass up and quenched my thirst.
As you said, you're not technical, and your assessment of the G5 shows it.
Comparing a couple isolated features in one OS to the same features in another OS is a ridiculous way to test performance. Software/hardware design is always about trade offs. If you move a window really fast in Windows, you'll actually be able to see the program redraw itself, while, on my G3, window movement is flawless. Using your logic, one would have to conclude Windows or x86 processors are slower than G3s.
In actuality, window resizing speed is a software issue caused by the double buffering of Windows in OS X. This is really not a flaw. This is actually a decision. Although this design decision hurts window resizing speed, it makes window movement extremely smooth, and makes many of the advanced graphic effects (tranlucency) even possible.
If you want to do a fairer test, install Linux on a G5 and a PC, and compare. It's hard to compare hardware when you're running different software.
Furthermore, the software compiler (builds the programs) is every bit as important as the processor to a machine's performance. A good compiler can improve performance by leaps and bounds, and usually takes years of hard work by many brilliant people to fine tune. For instance, even after years of optimization, x86 programs compiled with Intel's compiler are significantly faster than programs compiled with the Microsoft's or GCC's x86 compiler. The G5 is an extremely young system with a very immature compiler (builds the software). GCC probably still isn't very optimized for the G4 yet, much less the 64-bit G5.
Absolutely, and that's why I identified OS X's approach as a problem, and the illusion as a solution.
In the post you quoted, I was arguing against the claim that systems were powerful enough to instantaneously reflow documents, and so OS X was somehow deficient. Maybe it does need a little bit of work (the average 30%-40% speed increases reported in Panther had to come from somewhere) but Apple can "solve" the problem the same way MS did. It's a pretty clever hack.
But it's not truly live resizing, which is the issue I was responding to in my second post (the one you quoted).
Fair enough, sorry if I misconstrued. I don't have any doubt that the Macs (especially the G5's, of which I think highly) have equal capability to do "live" resizing to a PC. It's just frustrating that in many cases, Apple doesn't seem to have made GUI responsiveness a very high priority, and that's the very first thing any potential switcher will notice...
Why is resizing windows in the Finder so smooth, and in iTunes, it's so choppy?
I'd like to see a reasoned response from someone who knows about why some apps tend to resize better than others on the same machine. I've noticed this, too. The latest Eudora (6 B31) is just AWFUL when resizing or moving windows around, and it's a relatively small app, footprint-wise.
The smoothness appears to have something to do with the way individual apps are written as well as the OS.
My point was that 9 works the way an OS should work as far as responsiveness goes. X does not. It is as simple as that
OS X may never achieve the responsiveness of 9. The way 9 achieved that responsiveness was by putting ALL OTHER PROCESSES ON HOLD when you start to scroll things around and pull down menus. Explicitly not doing this was a design priority for OS X, and it means that time sensitive stuff can go on in the background, but it also increases overhead.
Frankly, I'd rather have OS X's multitasking than OS 9's super-snappy menu-dropping any day. It simply doesn't matter to me how smoothly my document scrolls, as long as I can sit there looking at the menus for a while while continuing to burn a CD in the background.
As for Windows, unless you turn all the XP widget stuff off and make it look like 2000, it's not that fast either, even on a top-end machine.
Actually, I think the "high-priority mouseclick" would have been a good thing to carry over from Classic Mac OS. When I click on something or click-drag, I want the computer to respond to me, not when it gets around to it. To be fair, it's not like everything grinds to a halt while the mouse button is depressed. Vital computer processes, modem activity, and CD burning would continue, for example. Everything else is/should be nonessential when you wish to give input to your computer, if you think about it.
That was one of the things that annoyed me frequently when I used to work on a W2k machine (a dual-processor setup, to boot). Much of the time, the CPU utilization was pegged, doing persistent tasks. Responsiveness to mouse-clicks would sometimes fall to crap. You never knew if the computer saw it or not until you got some sort of response later on. Click while maneuvering through menus was chaotic at times. You never knew if the computer's attention was going to drift away before you could get your mouse pointer to the desired selection. To add to the abuse, if the menu highlighting wasn't keeping up with your mouse pointer, you had to hover and wait over the selection to ensure the right menu item gets selected before you drop the 2nd mouseclick.
With that said, the high-priority mouseclick may seem arcane or "so 90's", but it certainly had a valid reason to exist. Making everything PE-MT'd isn't automatically better just because it is PE-MT'd.
Everything else is/should be nonessential when you wish to give input to your computer, if you think about it.
That's not the design principle behind a true, preemptive multitasking architecture, and as someone who lived with Mac OS multitasking from System 4.2/MultiFinder 6.0 onward, I can tell you that that "stop everything in the background" behavior was a continual headache, an irritation, a pain in the ass, and it drove everyone nuts for years. "Why can't you add preemptive multitasking?" everyone would ask. "No, it's not on the list," they told us when System 7 was rolled out at the 1990 Developer Conference, and everyone was up in arms.
It took ten more years to give people what they wanted, and I'm happy to give up 20 milliseconds of my time for that when I click on a menu.
However, I should point out that except under situations of extreme duress (and to be fair, OS 9 users must acknowledge that OS 9 was far from perfect as far as responsiveness goes - anyone else remember its behavior when the thrice-cursed Sherlock Indexing app popped up? Or when you tried to switch away from an app that was hammering the CPU?), the GUI really should be responsive. This is a human interface issue, and a valid complaint. In earlier builds of OS X, there would sometimes be a lag measured in seconds before a window responded to a mouse action, and that's poor UI.
Nobody's going to notice 20 milliseconds, but lots of people are going to notice 2 tenths of a second, or half a second, and speaking as a longtime fan of OS X who went 100% OS 9 free with 10.1, this has always been one of the worst aspects of OS X. It is application dependent to some extent; it is also system dependent to some extent (and the two are hard to separate in a Cocoa app, where so much of an applications functionality and even code structure are determined by the system) - as far as I can discern, double-buffering and SMP should only account for minor delays. (Most OS 9 windows were double-buffered, even though it had to be done explicitly by the programmer!). The kernel of any UNIX or UNIX-like is sophisticated enough to give the mouse vastly higher priority than the great bulk of other tasks without throwing out the preemptive model - and in fact, I don't think UNIX has had a straight round-robin scheduler (that is, one that assigns all tasks equal priority) since about 1971 - but I don't think even that's an issue.
OS X needs to be better threaded, more reentrant, more responsive - generally tightened up, and organized in such a way that the applications it runs can also be tightened up. Every iteration of the OS has in fact gotten faster, and it looks like Panther will be a leap forward - and if Apple adopts XLC in house (Darwin and CoreFoundation are C and C++ code, so this is possible) then that represents one way in which 10.4 could be even faster.
As of right now, there are several major areas of the OS that are either ugly (QT), unfinished (text support) or inefficient (GUI responsiveness). These all impact the perceived capability of the machine - which, in real terms, is the capability of the machine as far as a normal person is concerned. And so Apple is hard at work. But it is important to recognize that, although I don't think it's a bad problem in current builds (on my 450MHz G4), UI responsiveness is a real problem. I've seen people get confused and annoyed when they drag a resize corner and nothing happens. It conveys fragility and unreliability, which is not what Apple is shooting for right now.
That's not the design principle behind a true, preemptive multitasking architecture,...
By all means, my post was certainly not some impassioned yearning to return to a C-MT setup. PE-MT is certainly the logical way for the future. However, it should not be taken to mean that the future should be PE-MT-oriented in the strictest sense. The future should take "the good" and "the best" features offered by all systems that we have come to know from the past. It should not be a "PE-MT at all costs" proposition. That's about as silly as wishing that a single political party (whether it be the left or the right) will make your dreams come true.
Quote:
...and as someone who lived with Mac OS multitasking from System 4.2/MultiFinder 6.0 onward, I can tell you that that "stop everything in the background" behavior was a continual headache, an irritation, a pain in the ass, and it drove everyone nuts for years.
Well, I can't speak for "everybody", but I'll grant it certainly bothered you. As has been exposed in this discussion so far, it seems that going to the other extreme can be equally problematic. I think you should also give more credit to later Classic Mac OS versions where the refinement in multitasking and flexibility of "stop everything in the background" made improvement by leaps and bounds. By the time OS9 rolled around, these improvements where far and away better from where it was in 4.2.
Quote:
"Why can't you add preemptive multitasking?" everyone would ask. "No, it's not on the list," they told us when System 7 was rolled out at the 1990 Developer Conference, and everyone was up in arms.
Of course, we've waited a long time for what has been asked, so it should feel good that we have finally arrived. However, there is no need to dismiss and discredit all the good things we have come to know so far.
Quote:
It took ten more years to give people what they wanted, and I'm happy to give up 20 milliseconds of my time for that when I click on a menu.
It doesn't have to be either/or. It is hoped that we may enjoy the best of both cases in future versions of OSX...
You have to remember that all perception of speed is relative. Every person here will have a different perception of what matters to them. The reality is that no OS will do everything exactly the way that everybody wants it. There is always give and take.
Now, back on topic, I did go down to the CompUSA in Tacoma to check out the G5 1.6 demo machine they had. My experience with it was interesting. I have to agree that many finder actions, including resizing windows and even app startup are perception wise, slow, compared to what one might expect. However, it was fortunately a slow day there, due to the great weather, so I had plenty of time to play and compare it against my PowerMac 800 single.
iTunes seemed to perform well, but I did not have a chance to "burn a cd". iPhoto was not especially snappy, and a bit of a let down. Couldn't test iMovie as there were no "samples" available. I found however that the computer did have Graphic Converter on it. Since this is a program I am use a lot on my 800, and I had the forethought to bring an already tested jpg with me, I was able to run a few comparative tests. Essentially my experience was that some tasks currently benefit only from the faster CPU with about a 2x performance boost. Some tasks showed only minimal performance increase, less then the 2x you would expect. However there were a few filters that I tried that were nothing short of incredible, turning in numbers that were 4-5 times faster then my PowerMac 800. (probably due to the G5's superior floating point and bus speed)
Hence performace varied by task very dramatically. 10.2.7 is only a patch, that allows Jaguar to run on the G5. Nothing more then a stop-gap until Panther can be released. There are almost no applications (if any) that are currently optimized for the G5. Even the vaunted photoshop plug-in is only a temporary stop-gap until the next version of photoshop and addresses only a minimal number of performance issues.
When GCC 3.3 and the IBM compilers are ready for prime time, when Panther is released, then we will begin to see the true potential of the G5 start to be released. In the meantime, we have a system that is in transition. Any comparisions between the current G5 and the G4 or any other computer must be taken with extreme reserve. Give it a couple of months, and we will begin to see dramatic improvements. Within 6 months the G5 will be a true star.
Would I buy one now? Yes!! If I had the money I would buy one right now, because I have no doubt in my mind that it will get dramatically better in the near future. Of course if I had the money, I would already be on the waiting list for a dual G5 2.0 ghz.
Who knows, but maybe by the time the dual G5's start shipping in volume, Panther will be ready. Now that would be sweet!!
As of right now, there are several major areas of the OS that are either ugly (QT), unfinished (text support) or inefficient (GUI responsiveness). These all impact the perceived capability of the machine - which, in real terms, is the capability of the machine as far as a normal person is concerned. And so Apple is hard at work. But it is important to recognize that, although I don't think it's a bad problem in current builds (on my 450MHz G4), UI responsiveness is a real problem. I've seen people get confused and annoyed when they drag a resize corner and nothing happens. It conveys fragility and unreliability, which is not what Apple is shooting for right now.
I wish all the defensive types would take a cue from Amorh's comment above. (And his commentary in general.)
If the GUI feels less responsive to a novice, it is. It should be ok to notice this without being blasted for not appreciating the reasons. (Preemptive multi-tasking among them?) Reaction from normal people is as useful to Apple as that from pros. Personally, responsiveness has never been a problem to me since Jaguar. But when my kids jump on here from their PCs, they notice some lags.
It seems Amorph can bridge the experience from pros to novices objectively. I hope Apple can too. Arrogance regarding the OSX experience can not be helpful.
I just booted up my 15" PB in OS9 and had a play around. I dont see that it is faster than OSX - and window resizing is a JOKE!. I mean, it just resizes the border of the window and blanks everything else out - what is the point of that?
I just booted up my 15" PB in OS9 and had a play around. I dont see that it is faster than OSX - and window resizing is a JOKE!. I mean, it just resizes the border of the window and blanks everything else out - what is the point of that?
i use both os : os 9 at work and jaguar at home. And my answer is Jaguar is better, much better.
As Amorph mentionned, under classic, you may experience freeze, something that never occur under jaguar. This freeze especially happens under IE 5 : sometimes i wonder if my mac has crashed,or if it's just a freeze. Compared to that, the window resizing of os X is a joke.
I can wait to have my G5 and to leave behind me mac os 9;
Comments
...if it was encoding mp3's in the background, it's quite likely it was doing considerable HD accessing. This is not to say the thoughput was being swamped. This is just to say that frequent IDE HD operations tend to make everything choppy and inconsistent when combined with other tasks, no matter how multithreaded your apps are or PE-MT'd your OS is. It's just the nature of IDE, IMO. IDE places demands on the CPU, possibly high priority requests, due to the sensitive nature of error-free writing on a magnetic medium. That's just my theory, backed by consistent observations of similar, real-use situations. Possibly things may behave differently on a SCSI-based setup, but upon further recollection, I've seen this behavior there, too. Could have just been a "not high performance" SCSI controller, though.
A Windows machine will fall to this behavior just as well. Get 3 or 4 long HD operations going on at once, and you will see a lot of the "nominal" OS responsiveness get choppy.
These are sad days at Apple indeed if a $2500 G5 can't resize windows without lag.
Yup. How's resizing in iTunes?
Window resizing latency will, on the other hand, continue to be bothersome.
Originally posted by neilw
An "illusion" of live resizing is better than what OSX gives.
Absolutely, and that's why I identified OS X's approach as a problem, and the illusion as a solution.
In the post you quoted, I was arguing against the claim that systems were powerful enough to instantaneously reflow documents, and so OS X was somehow deficient. Maybe it does need a little bit of work (the average 30%-40% speed increases reported in Panther had to come from somewhere) but Apple can "solve" the problem the same way MS did. It's a pretty clever hack.
But it's not truly live resizing, which is the issue I was responding to in my second post (the one you quoted).
As you said, you're not technical, and your assessment of the G5 shows it.
Comparing a couple isolated features in one OS to the same features in another OS is a ridiculous way to test performance. Software/hardware design is always about trade offs. If you move a window really fast in Windows, you'll actually be able to see the program redraw itself, while, on my G3, window movement is flawless. Using your logic, one would have to conclude Windows or x86 processors are slower than G3s.
In actuality, window resizing speed is a software issue caused by the double buffering of Windows in OS X. This is really not a flaw. This is actually a decision. Although this design decision hurts window resizing speed, it makes window movement extremely smooth, and makes many of the advanced graphic effects (tranlucency) even possible.
If you want to do a fairer test, install Linux on a G5 and a PC, and compare. It's hard to compare hardware when you're running different software.
Furthermore, the software compiler (builds the programs) is every bit as important as the processor to a machine's performance. A good compiler can improve performance by leaps and bounds, and usually takes years of hard work by many brilliant people to fine tune. For instance, even after years of optimization, x86 programs compiled with Intel's compiler are significantly faster than programs compiled with the Microsoft's or GCC's x86 compiler. The G5 is an extremely young system with a very immature compiler (builds the software). GCC probably still isn't very optimized for the G4 yet, much less the 64-bit G5.
Originally posted by Amorph
Absolutely, and that's why I identified OS X's approach as a problem, and the illusion as a solution.
In the post you quoted, I was arguing against the claim that systems were powerful enough to instantaneously reflow documents, and so OS X was somehow deficient. Maybe it does need a little bit of work (the average 30%-40% speed increases reported in Panther had to come from somewhere) but Apple can "solve" the problem the same way MS did. It's a pretty clever hack.
But it's not truly live resizing, which is the issue I was responding to in my second post (the one you quoted).
Fair enough, sorry if I misconstrued. I don't have any doubt that the Macs (especially the G5's, of which I think highly) have equal capability to do "live" resizing to a PC. It's just frustrating that in many cases, Apple doesn't seem to have made GUI responsiveness a very high priority, and that's the very first thing any potential switcher will notice...
Originally posted by Placebo
Why is resizing windows in the Finder so smooth, and in iTunes, it's so choppy?
I'd like to see a reasoned response from someone who knows about why some apps tend to resize better than others on the same machine. I've noticed this, too. The latest Eudora (6 B31) is just AWFUL when resizing or moving windows around, and it's a relatively small app, footprint-wise.
The smoothness appears to have something to do with the way individual apps are written as well as the OS.
CV
Originally posted by Mac Voyer
My point was that 9 works the way an OS should work as far as responsiveness goes. X does not. It is as simple as that
OS X may never achieve the responsiveness of 9. The way 9 achieved that responsiveness was by putting ALL OTHER PROCESSES ON HOLD when you start to scroll things around and pull down menus. Explicitly not doing this was a design priority for OS X, and it means that time sensitive stuff can go on in the background, but it also increases overhead.
Frankly, I'd rather have OS X's multitasking than OS 9's super-snappy menu-dropping any day. It simply doesn't matter to me how smoothly my document scrolls, as long as I can sit there looking at the menus for a while while continuing to burn a CD in the background.
As for Windows, unless you turn all the XP widget stuff off and make it look like 2000, it's not that fast either, even on a top-end machine.
-- Mark
That was one of the things that annoyed me frequently when I used to work on a W2k machine (a dual-processor setup, to boot). Much of the time, the CPU utilization was pegged, doing persistent tasks. Responsiveness to mouse-clicks would sometimes fall to crap. You never knew if the computer saw it or not until you got some sort of response later on. Click while maneuvering through menus was chaotic at times. You never knew if the computer's attention was going to drift away before you could get your mouse pointer to the desired selection. To add to the abuse, if the menu highlighting wasn't keeping up with your mouse pointer, you had to hover and wait over the selection to ensure the right menu item gets selected before you drop the 2nd mouseclick.
With that said, the high-priority mouseclick may seem arcane or "so 90's", but it certainly had a valid reason to exist. Making everything PE-MT'd isn't automatically better just because it is PE-MT'd.
Originally posted by Randycat99
Everything else is/should be nonessential when you wish to give input to your computer, if you think about it.
That's not the design principle behind a true, preemptive multitasking architecture, and as someone who lived with Mac OS multitasking from System 4.2/MultiFinder 6.0 onward, I can tell you that that "stop everything in the background" behavior was a continual headache, an irritation, a pain in the ass, and it drove everyone nuts for years. "Why can't you add preemptive multitasking?" everyone would ask. "No, it's not on the list," they told us when System 7 was rolled out at the 1990 Developer Conference, and everyone was up in arms.
It took ten more years to give people what they wanted, and I'm happy to give up 20 milliseconds of my time for that when I click on a menu.
-- Mark
Nobody's going to notice 20 milliseconds, but lots of people are going to notice 2 tenths of a second, or half a second, and speaking as a longtime fan of OS X who went 100% OS 9 free with 10.1, this has always been one of the worst aspects of OS X. It is application dependent to some extent; it is also system dependent to some extent (and the two are hard to separate in a Cocoa app, where so much of an applications functionality and even code structure are determined by the system) - as far as I can discern, double-buffering and SMP should only account for minor delays. (Most OS 9 windows were double-buffered, even though it had to be done explicitly by the programmer!). The kernel of any UNIX or UNIX-like is sophisticated enough to give the mouse vastly higher priority than the great bulk of other tasks without throwing out the preemptive model - and in fact, I don't think UNIX has had a straight round-robin scheduler (that is, one that assigns all tasks equal priority) since about 1971 - but I don't think even that's an issue.
OS X needs to be better threaded, more reentrant, more responsive - generally tightened up, and organized in such a way that the applications it runs can also be tightened up. Every iteration of the OS has in fact gotten faster, and it looks like Panther will be a leap forward - and if Apple adopts XLC in house (Darwin and CoreFoundation are C and C++ code, so this is possible) then that represents one way in which 10.4 could be even faster.
As of right now, there are several major areas of the OS that are either ugly (QT), unfinished (text support) or inefficient (GUI responsiveness). These all impact the perceived capability of the machine - which, in real terms, is the capability of the machine as far as a normal person is concerned. And so Apple is hard at work. But it is important to recognize that, although I don't think it's a bad problem in current builds (on my 450MHz G4), UI responsiveness is a real problem. I've seen people get confused and annoyed when they drag a resize corner and nothing happens. It conveys fragility and unreliability, which is not what Apple is shooting for right now.
Originally posted by mark_wilkins
That's not the design principle behind a true, preemptive multitasking architecture,...
By all means, my post was certainly not some impassioned yearning to return to a C-MT setup. PE-MT is certainly the logical way for the future. However, it should not be taken to mean that the future should be PE-MT-oriented in the strictest sense. The future should take "the good" and "the best" features offered by all systems that we have come to know from the past. It should not be a "PE-MT at all costs" proposition. That's about as silly as wishing that a single political party (whether it be the left or the right) will make your dreams come true.
Quote:
...and as someone who lived with Mac OS multitasking from System 4.2/MultiFinder 6.0 onward, I can tell you that that "stop everything in the background" behavior was a continual headache, an irritation, a pain in the ass, and it drove everyone nuts for years.
Well, I can't speak for "everybody", but I'll grant it certainly bothered you. As has been exposed in this discussion so far, it seems that going to the other extreme can be equally problematic. I think you should also give more credit to later Classic Mac OS versions where the refinement in multitasking and flexibility of "stop everything in the background" made improvement by leaps and bounds. By the time OS9 rolled around, these improvements where far and away better from where it was in 4.2.
Quote:
"Why can't you add preemptive multitasking?" everyone would ask. "No, it's not on the list," they told us when System 7 was rolled out at the 1990 Developer Conference, and everyone was up in arms.
Of course, we've waited a long time for what has been asked, so it should feel good that we have finally arrived. However, there is no need to dismiss and discredit all the good things we have come to know so far.
Quote:
It took ten more years to give people what they wanted, and I'm happy to give up 20 milliseconds of my time for that when I click on a menu.
It doesn't have to be either/or. It is hoped that we may enjoy the best of both cases in future versions of OSX...
Originally posted by satchmo
This was often the said of the first release of OSX...Jaguar was supposed to make G4's fly. Now we have to wait for Panther to make the G5 fly.
I hope it's true. I think even many of the Apple faithful are beginning to grow tired of hearing this "excuse".
OK!
i just have to respond to this comment.
i am a mac os/x user.
i currently have a imac 350 which i run jaguar on.
in the past i had a B/W 300mhz tower for which i purchased the first version of os/X when it came out and it was slow.
i have jaguar 10.2 on my imac 350 mhz and it is very fast.
apple has done a great job of speeding up the O.S so the shot that you "satchmo" took at apple was a cheap one and not very accurate.
jaguar has to fly on your g4 if its flying on my imac g3.
Now, back on topic, I did go down to the CompUSA in Tacoma to check out the G5 1.6 demo machine they had. My experience with it was interesting. I have to agree that many finder actions, including resizing windows and even app startup are perception wise, slow, compared to what one might expect. However, it was fortunately a slow day there, due to the great weather, so I had plenty of time to play and compare it against my PowerMac 800 single.
iTunes seemed to perform well, but I did not have a chance to "burn a cd". iPhoto was not especially snappy, and a bit of a let down. Couldn't test iMovie as there were no "samples" available. I found however that the computer did have Graphic Converter on it. Since this is a program I am use a lot on my 800, and I had the forethought to bring an already tested jpg with me, I was able to run a few comparative tests. Essentially my experience was that some tasks currently benefit only from the faster CPU with about a 2x performance boost. Some tasks showed only minimal performance increase, less then the 2x you would expect. However there were a few filters that I tried that were nothing short of incredible, turning in numbers that were 4-5 times faster then my PowerMac 800. (probably due to the G5's superior floating point and bus speed)
Hence performace varied by task very dramatically. 10.2.7 is only a patch, that allows Jaguar to run on the G5. Nothing more then a stop-gap until Panther can be released. There are almost no applications (if any) that are currently optimized for the G5. Even the vaunted photoshop plug-in is only a temporary stop-gap until the next version of photoshop and addresses only a minimal number of performance issues.
When GCC 3.3 and the IBM compilers are ready for prime time, when Panther is released, then we will begin to see the true potential of the G5 start to be released. In the meantime, we have a system that is in transition. Any comparisions between the current G5 and the G4 or any other computer must be taken with extreme reserve. Give it a couple of months, and we will begin to see dramatic improvements. Within 6 months the G5 will be a true star.
Would I buy one now? Yes!! If I had the money I would buy one right now, because I have no doubt in my mind that it will get dramatically better in the near future. Of course if I had the money, I would already be on the waiting list for a dual G5 2.0 ghz.
Who knows, but maybe by the time the dual G5's start shipping in volume, Panther will be ready. Now that would be sweet!!
As of right now, there are several major areas of the OS that are either ugly (QT), unfinished (text support) or inefficient (GUI responsiveness). These all impact the perceived capability of the machine - which, in real terms, is the capability of the machine as far as a normal person is concerned. And so Apple is hard at work. But it is important to recognize that, although I don't think it's a bad problem in current builds (on my 450MHz G4), UI responsiveness is a real problem. I've seen people get confused and annoyed when they drag a resize corner and nothing happens. It conveys fragility and unreliability, which is not what Apple is shooting for right now.
I wish all the defensive types would take a cue from Amorh's comment above. (And his commentary in general.)
If the GUI feels less responsive to a novice, it is. It should be ok to notice this without being blasted for not appreciating the reasons. (Preemptive multi-tasking among them?) Reaction from normal people is as useful to Apple as that from pros. Personally, responsiveness has never been a problem to me since Jaguar. But when my kids jump on here from their PCs, they notice some lags.
It seems Amorph can bridge the experience from pros to novices objectively. I hope Apple can too. Arrogance regarding the OSX experience can not be helpful.
Originally posted by musicaltone
I just booted up my 15" PB in OS9 and had a play around. I dont see that it is faster than OSX - and window resizing is a JOKE!. I mean, it just resizes the border of the window and blanks everything else out - what is the point of that?
i use both os : os 9 at work and jaguar at home. And my answer is Jaguar is better, much better.
As Amorph mentionned, under classic, you may experience freeze, something that never occur under jaguar. This freeze especially happens under IE 5 : sometimes i wonder if my mac has crashed,or if it's just a freeze. Compared to that, the window resizing of os X is a joke.
I can wait to have my G5 and to leave behind me mac os 9;