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?
From the article: "Looking at the results, it appears that Tiger is as fast (if not faster) than Panther in all areas except for UI performance." His numbers show Tiger barely edging out Panther, using Xbench (a purely synthetic benchmark) as the test basis.
I've tried Tiger out on my G4 powerbook, and have actually noticed a *decrease* in Xbench ratings, despite an overall "snappier" feel. Maybe the increase isn't really going to happen for those without 64 bit machines. Then again, its a pre-relase, so there is plenty of room for change.
built with the new version of gcc that Apple is releasing with Tiger. The compiled code(on both G4 and G5, moreso on the G5 which they used) is supposed to be much more efficient for certain operations than the previous version of GCC. Wonder if they used this?
more info here
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
-Sean
These two benchmarks seem to be continuously confused by slashdotters over the years. Of course it is debatable which is really more important. I think OS X has definitely concentrated on perceived speed, which is good because that is what the user "feels" and sees as he interacts with the computer. This does in no way mean the whole OS is faster; it just feels faster.
OS X has definitely not improved dramatically in throughput and raw horsepower over the last few releases. In fact I'm sure it has decreased slightly. Sacrificing a little of that throughput for smoother rendering yields a significant percieved speedup that the users really like. I would say that every release of OS X has gotten a little heavier and is a little bit slower. A sacrifice I'm willing to make for my pretty Panther desktop, though.
Windows has gotten slower on both counts over the years.
Linux's throughput has actually increased fairly dramatically in the last year or two. Unfortunately as the weight of the desktop comes to bear, and due to current weaknesses in X11 and the toolkits (most notably the lack synchronized redraw which make resizing appear really slow), the perceived speed of linux has seemed to decrease with recent distros. The 2.6 kernel provided some speedup in this area (the interactive scheduler), but there is still much work to be done.
The experimental X server from www.freedesktop.org implements a lot of features that will lead to a perceived speedup. For example the damage and composite extension reduce redraws when windows are uncovered. Work is also being done to allow windows to resize smoothly (synchronizing the widget drawing and compressing events). Even with the vesa driver and no acceleration, it feels faster than normal accelerated X.org. Again perceived speed vs throughput. Give it a try. It's cool.
Fortunately I think Linux will deliver on both benchmarks. Expect exciting things over the next year from linux desktops.
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.
I always find it funny, Microsoft can be the most successful software vendor on the planet, but a company with what maybe 5% of their value (if that) can come up and best them time and time again. With that much cash shouldn't they be able to buy all the developers possible?
"What is it about debugging code? It's almost mythical the level of speed upds people think they'll gain once all this debug code has gone."
People are ignorant...
Okay, for you non-developer folks playing along at home, here's what you need to know:
1. "Debugging Symbols" are extra information stored (typically) in the program's executable file, that make it easier to run that code under a source-level debugger and see the right names for variables, functions, and other program entities.
In general, any software that's released to customers (yes, INCLUDING beta versions) will have the debugging symbols "stripped" from the programs, because they're not useful for the customer, and also because many companies fear (for no apparent good reason) that they represent a leak of confidential information. There is a slight performance penalty on some platforms for running a binary with symbols, but it's only going to effect load time, and only by a tiny fraction.
2. "Debugging Code" is not as well defined of a term, but sometimes, early development builds of software will include extra checks on the integrity of key data structures, or extra error-recovery code. Again, in general, these sorts of builds would never be distributed to a customer.
3. So why do programs generally improve in performance towards the end of the development cycle? It's for the rather self-evident reason that the software has to be working correctly before it's worth the effort to try to make it run faster. In fact, optimizing performance before the feature set has been frozen is one of the classic blunders of software development!
-Mark
Put another way, what do the newer cards have that I don't? Core Image looks to me like the best new feature in Tiger, if I can actually use it. Quartz Extreme gave me a pretty good speed increase when it came out, and I would expect CoreImage to allow most graphics programs to work snappier, but that's all irrelevant if my card isn't up to snuff.
Si la vida me da palo, yo la voy a soportar Si la vida me da palo, yo la voy a espabilar
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.
It's clear Apple is out to lunch on games. However this isn't that bad. What they need to do is cause a paradigm shift on games! Back to the console using the computer. What they REALLY should start doing is, since both the PS3 and GameCube are going to be PPC based (I doubt M$ would play along) find out some way to work with the GameCube and PS3 for a sweet gaming experience on the Mac. If the DS has some standard wireless tech it should be able to work with any Mac. Heck think about it, we already have some great emulators available. How about the iGames ROM Store? Have everything from classic SNES games, to N64, to GameCube, to whatever revolution will be called. Get SEGA on board, who knows maybe even Sony could be convinced to play along with PS1 tittles. Apple could move on games, but to compete with Microsoft, they would need to do it in an entirely different way.
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.
Just to clarify, Core Image requires least a Radeon 9500 or GeForceFX 5200 to use all the features, although the library does scale. These cards support floating point vertex and fragment shaders.
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.