R4 Gains Altitude

GCC, OS Tweaks Enliven System

by Scot Hacker
Friday, Oct. 2, 1998

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.

OS Optimizations

The migration of BeOS to the Intel/x86 architecture in R3 was a major undertaking. While BeOS for x86 has been enthusiastically received by thousands of OS gourmets, all software needs time in the field -- and much laying-on of hands -- to show its true colors. In many areas, R3/Intel shone like a diamond. Application launch speed and multimedia throughput, for example, were untouchably fast. On the other hand, there were also specific areas where things didn't scoot like they should (although, being accustomed to other operating systems, most end-users didn't even know it). For example, the drawing of large numbers of views left room for improvement (a "view" is a visible "section" of an application that hosts objects, such as a bitmap, a text field, an oscilloscope readout, a slider control, or just about anything else; a single window can potentially host thousands of views).

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.

Compiler Switch

The application development environment and code compiler for BeOS has for years been provided by Metrowerks, a company with a lifetime of experience working in the PowerPC space. While the Metrowerks compiler is fully optimized for PowerPC (i.e. for BeBoxen and PowerMacs) and provides great performance on those chips, the company has less experience working with the x86 architecture. As a result, x86 BeOS code created by the Metrowerks compiler has not been as fast it could be. When Be discovered that the same application code compiled with more evolved x86 compilers ran faster under BeOS, the choice became clear: it was time to contemplate a fork() in the road.

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.

Side Effects

Beyond performance, the move to the GCC compiler means several things to BeOS users and developers. First of all, GCC creates code in a different binary format than that created by Metrowerks (in programmer's terms, it creates ELF binaries, rather than PE binaries). And that means that programs compiled under R3 will not run under R4 -- BeOS users will need to re-install all of their applications when they upgrade this December. In addition, application launch time may be slightly slower than it was under R4. Not unreasonably slower, but possibly noticeable. In exchange for greater performance in practically everything an application does, most will agree that this is a small price to pay. Are these unfortunate hardships to impose on the user community? Perhaps, but I doubt Be will get many complaints from users, who tend to be OS connoisseurs. There's little question in anyone's mind that it's going to be worth it, and now is definitely the right time since R3 is the last of the "geek" releases, and it's much easier to spring this kind of thing on geeks than on the general population.

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.

Gourmet Operating System

A year ago I was complaining in this space that BeOS didn't do certain things the way I was accustomed to doing them in Windows. But that was before I got religion. Once you get used to doing things the Be way, there's no going back. The more time I spend with BeOS, the more it becomes apparent to me that this company is doing things right. Even though the system is presented and marketed (rightfully so) as "The MediaOS," I'm finding more in it all the time that makes it well-suited for use as a general-purpose operating system as well. While it's true that you can't run Microsoft Office on BeOS, there are plenty of productivity apps available for the system that let me get my daily word-processing, spreadsheet, and database work done just fine. But beyond the applications question, BeOS itself has so many features that contribute to daily productivity that I've come to loathe having to boot into Windows. Wanna know how I really feel? See Paul Somerson's "Windows Is a Grief-Causing Kludge."

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.

Other News

My work on the BeOS Bible is rounding the corner into the final stretch. Even though it won't be available for purchase until late January, 1999, you can pre-order it from amazon.com now.

More Information