If you thought BeOS was already a quick operating system, you were right. But in the Be way of thinking, you can never be too thin or too fast. The next version of BeOS (R4, due for public release in December) will receive some very significant performance improvements, which apply to both the operating system itself and to all applications running on it. There are too many variables to accurately quantify improvements to the system as a whole, but there are numbers in specific arenas that will make even the most dour skeptics take notice. Suffice to say, Be is "kicking ass and taking names."
So how does an already wicked-fast OS gain so much performance all at once? Two things: optimizations of core OS code, and a more efficient compiler. R4 performance improvements are due to both of these factors, working separately and together. But what do they mean, exactly? Let's look at them individually.
In R4, the operating system code that manages communication between the system's centralized application server (the app_server) and the applications themselves has been optimized. When a view in an application draws to the screen, it speaks to the app_server, which sends that data on to the video card. In R4, the speed of this transaction has been enhanced, and the OS is almost ten times more efficient at handling views as a result. A couple of days ago I paid a visit to Be headquarters and observed an intensive BView test application running on R3 and then on R4, on identical hardware. The test created a small window and filled it with 2,000 multi-colored views, most of them nested deeply within one another. The window was then "zoomed," or maximized. The number of seconds required to redraw all 2,000 views was the test result. Under R3, the demo took almost ten seconds to redraw; under R4, barely more than one second. While no real-world application draws 2,000 views in a single window, most applications draw multiple views, or single very complex views. This test provides a dramatic demonstration of improvements to operating system code that will have a net impact on overall responsiveness.
Significant changes have also been made to the code that manages calls to kernel functions, an improvement which manifests itself througout the system. For example, consider the ubiquitous semaphore. As you know, BeOS is a heavily multithreaded system. Semaphores are like tokens that let programmers synchronize their threads, and that provide locking and unlocking services. Locking semaphores is something that all applications are doing all the time -- it's like breathing for BeOS, and here we see 8 - 9% performance improvements due to OS code optimizations, with more gravy ladled on by the compiler switch, discussed below. Remember -- these performance enhancements are "free" -- developers don't have to change a single line of code. Simply running on BeOS R4 is all it takes to move your application into warp speed.
As of R4, Be and all Be developers creating applications for the x86 version of BeOS will be crunching their code with the GNU C compiler, or GCC. This means several things to the BeOS community. First off, GCC code is fully optimized for x86 chips, so both the operating system and all BeOS applications become faster, in almost every measurable respect. You can see a full breakdown of the benchmarks here, but most improvements are at least 20% faster than the same code compiled under Metrowerks, and much more in many instances. To be fair, there are also some areas where only a few percentage points are gained, and even a few areas where Metrowerks-compiled code is slightly faster than GCC's. These areas, however, are in the vast minority, and their margins are small. Check out these highlights:
The process of copying a piece of data into system memory (known to programmers as a memcopy), is three times faster for small chunks, and 547% faster for 1024-byte chunks! Applications don't spend all of their time sitting around doing memcopies, so that doesn't mean that applications are going to be 547% faster. You still have to consider physical limitations such as the amount of time it takes to scoop data off your hard disk, but this still represents an enormous performance improvement for many types of applications -- especially in the multimedia realm on which Be is focused. The GCC compiler also adds another 4% performance improvement to the semaphore locking operations described above.
But benchmarks can be misleading. They test very specific functions over and over again, while real applications do all kinds of things, in sequences no benchmark can predict. So how do these numbers translate in the real world? It's a little early to tell since R4 isn't yet finished, but there are already some very promising indications. For example, a new fractal-generation demonstration (separate from the one now shipping with BeOS) has been constructed to stress several areas of the system simultaneously: multithreading (four threads), disk access, video functions, rendering speed, and pure math. When this demo is run under BeOS R3.2, it requires 12.6 seconds to render its Mandelbrot (on our demo station). Under R4 with the old compiler, that time suddenly dropped to 3.4 seconds. Under R4 with the new compiler, a stunning 1.5 seconds. In other words, the exact same code running on the exact same hardware is 7.4 times faster in completing this particular test.
How these optimizations will affect your daily work on BeOS remains to be seen, but I think it's safe to say that pretty much everything you do is going to benefit. The prospects are exciting.
For developers, the switch means scanning existing code for a few gotchas (GCC is less tolerant of certain code structures which Metrowerks is liberal about), making the changes, and recompiling. Perhaps more significantly though, it means access to a good source-level debugger (which will probably be available for download shortly after R4's release), the lack of which has been a sore spot for many BeOS developers. Compilation time for ELF binaries will also be somewhat slower than comparable PE binaries, mostly because of all the optimizations taking place. For those interested in getting up-to-speed with BeOS development, the current distinction between the free-but-limited Metrowerks compiler and the unlimited version available at extra cost will disappear. The compiler and toolset provided with every copy of BeOS will be complete and unlimited, making every BeOS user into a potential developer. As Be's head of Developer Tech Support puts it, "Free tools, better tools."
Because GCC is widely used in the Linux world, the move also means that it may become easier for Linux developers to migrate to BeOS and continue working with familiar tools -- an already open door opens a little wider.
Keep an eye on BeView, a brand-new BeOS news and information meta-site scheduled to make its public debut next week. I've written a piece on using BeOS as a general-purpose operating system for their first issue.
What I'm getting at is this: some tastes in this world have to be acquired. We aren't born with the ability to tell the difference between a cheap wine and a fine Cabernet -- we need to spend time experiencing, sipping, and comparing wines before the crucial differences begin to emerge. Once you get hooked on San Francisco coffee, it's a hardship to travel the country getting your java from truckstops. Once you've lived with a great stereo for a while, you'll never be satisfied with Radio Shack again.
One of the most important things I've realized over the past year is that computing can be an aesthetic experience -- smooth, grief-free, and fun. The sensation of working with something really well-designed, with human users in mind, can be exhilarating. Your computer isn't just a tool -- it's an environment to be lived in, for many hours per day. As such, you need it to think like you do, not work against you. BeOS is elegant. Like a finely designed European car or, one of those amazing pocket tools with a million little gadgets that seem to keep popping out when you thought you had already seen them all, BeOS continues to amaze and impress me. How can they pack so much into such a little space, and still keep it feeling like a study in exceptional design? I've come to think of BeOS as a gourmet operating system. Call me a snob if you will, but I enjoy my machine time a lot more than I used to.
And I haven't even told you about the new features in R4 yet. We'll do that next month.
Many thanks to Be's Stephen Beaulieu for assistance in preparing this Journal entry.