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
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.