Puneet Kishor iwaku > The bottomline is -- whatever the fancy architecture behind these > machines, whatever the Macworld demos by Mr. Jobs might demo, Macs are > generally slower [...]
Okay, one more time around -- (1) The compiler optimizations are tuned to the iNTEL architecture. There's no way getting around this, unless you have money to re-educate and feed the guys who own GCC while they get up to full speed on PPC. Had the same problems with the 68K. A lot of tricks to optimize x86 code work backwards on a decently architected CPU, incidentally. In a loose estimate, that accounts for about 10% to 300% of the speed difference, depending on the application. (2) The Mac OSses have always done more for us than the MS OSses. (That explains the "subjective" difference in usability, OK?) The time for that has to come from somewhere, and that is in my mind the singular most significant benefit of dual CPUs. One CPU can be minding your mouse while the other crunches. Among the topics I'm waving my hands at here is the fact that making the interrupt architecture more responsive and more flexible for general processes will slow down specific individual tasks on a given CPU (algorithmic flaws aside). As a rough guess, this kind of stuff will account for another 30% to 150% of the speed difference. (Again, depending on what you're doing.) (3) The legacy stuff from Classic, because it did so much more than DOS ever could, provides a significant amount of drag on the system. Just having it available will slow the system down 3% to 10% from what it could be getting, and having the Classic system actually running will slow the system down 10% to 50% or more, again, as a rough estimate. (4) We have stray reports from the various attempts to port Mac OS to the iNTEL architecture that it runs faster "over there". It should. In addition to the compiler writer training effects I mentioned above, re-implementations should generally be more efficient than original implementations. You can push some of the efficiency back to the original implementation, but you have to test any changes you bring back pretty thoroughly. Ports are expected to have stupid errors, so the testing requirements are significantly lower on the new implementation. Incidentally, a lot of the speed gain going from 68K to PPC were re-implementation effects. A 68060 running 66 MHz and and a PPC running 66 MHz were not that much different in raw speed over a good mix of reasonably optimized code. (Most of the really fancy instructions in the 68020+ were not useful, however.) Is that enough, or should I continue? If you really want speed, you don't go to another general purpose OS, you use dedicated systems, and you choose a CPU you know how to generate optimal code for. (What I keep waiting for Apple to do is put out a machine with one relatively cheap processor dedicated to the user interface, another relatively cheap processor for the file system, and a real hot-dog processor to crunch numbers. But I don't think technology is quite up to it yet, from the production and maintenance costs point of view.) > That said, I still prefer 'em over any other platform, but certainly > not for their speed. In spite of them being noticeably slow, they > enable me to work faster. This is the bottom line for me. I don't care how fast a machine crunches numbers if it doesn't help me get my job done. I strongly suspect I'd be more productive on on old PowerPC 7100 running 8.6 than on this 900+ MHz MSW2k box with a gigabyte of RAM. Sure, I can use a Q&D Java program with less than 50 lines to compute all the factorials from 0 to 5000 in under a second on this box, and my 300 MHz Mac OS X iBook with 192K RAM takes around 5 seconds on the same program. On a 7100, who knows? several minutes? But how often would I do that in a day? On MSW2k, I have Active State's Perl doing some repetitive tasks for me. On Mac OS, I can control the mouse and the system well enough that I just do lots of these things by hand. Saves me the time to write the script. I'm preaching to the choir, I'm sure. I'll shut up. -- Joel Rees <[EMAIL PROTECTED]>
