Slashdot Mirror
Early Tiger Benchmarks Show Slight Speed-Ups
GatorMarc writes "Geek Patrol has published early speed benchmark tests on Tiger. Despite the fact that Tiger is still in development, the results are promising. Could we see a similar performance improvement as we did upgrading from Jaguar to Panther?"
Was it built with debugging symbols on?
This release was obviously pulled together for the conference -- a Herculean effort by the engineers at Apple to show what will be available in a year for now. A wonderful release for us third-party developers!
No one in their right mind is going to think that this release is fit for benchmarking. There may be some gains that are side effects of internal changes (new versions of gcc, etc.), but anyone with a clue will realize that minimal optimization has been done.
When they say DEVELOPER PREVIEW they mean it...
-ch
Don't most of the speed increases come closer towards the end of the development cycle? I know that is usually the case for games.
Yeah. And Tiger is to be released in the first half of 2005. Which gives them between 5-11 months to make these changes.
I think it's just too early to tell how fast the final release is going to be, since there's probably 3/4 of a year more development to be done.
WARNING: If accidentally read, induce vomiting.
-Sean
Quite. Some even consider premature/early optimization to be a bit of a curse, or at least not a very good idea. In software development in general, definately not just limited to games.
Working toward a usable PDA environment in the spirit of Newton OS: Dynapad
Keep in mind these tests were done on the G5's. Tiger is the only version of Mac OS X to have 64bit support. One has to wonder if it is really faster on non-64 bit operating systems.
The most common lament I hear on /. (about Mac)is that there's no port of a specific game. Make a Mac-only game with the same 12-year old boy appeal as Halo, and you might sell yourself some Macs.
Wait.. are you saying that more games should be ported to the Mac, or that there should be games developed *solely* for the Mac? If the first, that's already taken care of: anything written in OpenGL works on the Mac. For example: Halo.
If the latter... that's kinda silly. No one would want to limit their market appeal. As great as I think Macs are, I would never expect a software company to limit their product to a single platform, no matter which platform we're talking about.
You've run XP acceptably on 6 year old machines? Well, you are probably the only one in the world. Many PC-compatible 6 year old machines are limited in RAM to between 128 megs or so, which is not enough for XP. Basically, our three-year-old laptops (Dell business machiens, limited to 256 megs of RAM) are bad enough; I can't imagine what you'd do with a 400 mHz machine with 128 megs of RAM running XP. That's assuming it's still working; 2/3 of our three-year old (Dell) laptops have failed more than once in their third year of operation. Once the extended warrantee is up, they're getting pitched. On the other hand, all our Macs are doing just fine, except the laptop that got abused by an airline baggage handler. (Which I won't claim is anything other than luck... if you've got ten heavily used computers of any kind in a company and none of them have gone in for service in over three years, you're just plain lucky.)
As for apple locking things out of the BIOS, well, you're right that there are some six-year-old Macs that won't run Mac OS X without your using some little tricks to get them to work. However, MOST six-year-old Macs (the first generation of iMacs, the PowerBooks, the Blue & White PowerMac which was introduced in 1998) work fine with it, and all of them will take at least 512 mb of RAM, which is plenty. It's hard for me to blame Apple for not supporting the vintage 1997 (that would be seven years old, though some were sold in 1998) beige G3s, with their onboard SCSI, their ADB-connected keyboards and mice, and the (pathetic) Rage II+ graphics chips that many of them had. If you want them to work, you can get them to work, Apple just makes it clear that they're not supporting them.
Whereas if you buy a retail version of XP and install it on a 7-year-old PC and you call up Microsoft, they'll be happy to spend as many hours as you want on the phone with you to get it up and running. On your dime. Just remember that half your hardware is probably not supported by XP/2000 drivers, and that the tech support phone call is liable to cost you as much as one of those ultra-cheap PCs.
-fred
Sign #11 of Slashdot overdose: You see the phrase 'moderate Republican' and you wonder if that would be a +1 or a -1.
And the fact that it is equaling benchmarks of the non-debug-mode Panther should make it clear.
Debug code is always slower.
The most famous is: Never get involved in a land war in Asia. Only slightly less well know is this: Never go in against a Sicilian when death is on the line!
"Nobody owns the fucking words man." - James Dean
Although you do make good points about debug symbols mostly taking a space instead of slowing things down, one can't forget the compiler optimizations that are often enabled in release builds but not enabled in debug builds. Without those optimizations (particularly for C++ apps, as many commercial software products are still C++), some operations may be orders of magnitude slower.
Hence, not suprising that debug builds are often perceived as slower.