Performance in the Pipeline

BeOS gaming, networking performance about to get major boosts

Until recently, two critical technologies in BeOS have not shone with the same brilliance as the rest of the system. While the net_server -- which manages system-wide network activity -- has been perfectly functional, no one could call it a great performer, which is why few users have deployed BeOS as a serious server platform. Nor has BeOS lived up to its potential as a great gaming OS, in part due to a lackluster OpenGL implementation. All of that is about to change, in a big way.

As you read this, both the OpenGL and networking implementations in BeOS are being ripped out and replaced with modern, high-performance equivalents worthy of the Be name. Both are currently undergoing closed beta testing, and both are showing extremely promising early benchmarks. Assuming that both components are integrated into the next BeOS upgrade, there are going to be a lot of very happy gamers and webmasters floating around out there, and users of other OSes will have more incentive than ever to give BeOS a shot.

The fact that Be has put so much energy into these re-writes should also help to dispel fears that Be is focused solely on their Internet Appliance strategy, without regard to desktop BeOS users.

Meanwhile, developers are already starting to look at creative ways to harness Be's powerful new networking stack -- we'll take a look at LCS' amazing distributed networking system " MUSCLE" at the end of this article.

Smokin' 3D Graphics

In early June, Be provided a beta version of the OpenGL re-write to BeNews, along with optimized versions of Quake II and GLQuake. BeNews performed fairly exhaustive benchmark tests, comparing BeOS 5 with the replacement OpenGL package to Linux, Windows, and BeOS 4.5.

While the tests were conducted mostly by a single journalist and only on a handful of cards, BeNews found that the OpenGL replacement package outclasses OpenGL performance on both Windows and Linux in margins ranging from slim to huge. In a gaming world where frames-per-second are like life-blood, this kind of advantage will not go unnoticed. These are the kinds of numbers that make both game companies and players sit up and take notice.

The BeNews benchmarks were later contested by the Linux community on the grounds that the windowing system used was XF86 3.3 rather than XF86 4 with DRI, which would have improved the dismal ranking Linux received in the test. However, other sites have conducted tests pitting the latest X server against Windows, and Linux still came out behind. Since BeOS also beat Windows in the BeNews tests, one can conclude that BeOS still would have posted better scores than Linux with an updated X server.

Even in beta, Be's new OpenGL implementation is promising to do huge things for the gaming side of the platform. It's not enough for Be to excel in some areas; to really turn heads in the increasingly heated OS market, you need to excel everywhere. With numbers like these, and with BeOS being free and painless to install, I'll be surprised if the CEOs of major gaming companies can keep saying no to BeOS ports. The userbase will demand it.

Throw Me a BONE Here

The BeOS Networking Environment, a.k.a. BONE, is BeOS networking done right. Written largely from scratch to be faster and more compatible with the powerful network environments found in Linux and BSD, BONE represents a huge leap forward for the viability of BeOS as a server. Until recently, Be has been optimizing the system primarily for high-bandwidth media handling. Users who wanted a world-class server were encouraged to "use the right tool for the job," i.e. to look to another OS.

With BONE in place, Be's networking performance increases by a factor of twenty, according to early reports from Be's network engineers, bringing it inline with Linux / BSD server performance. No, BONE doesn't surpass the TCP stack in those operating systems, but it comes pretty close -- certainly close enough to meet the needs of the vast majority of sites handling anything but the highest levels of traffic. In addition, the old net_server did not support "sockets as file descriptors," an API incompatibility that made it difficult if not impossible to port certain kinds of network applications from other POSIX operating systems. BONE does, though, and that means we're on the brink of seeing a whole slew of new network tools and utilities, covering everything from traceroute and tcpdump to mail and DNS servers.

While there are already several quality web servers for BeOS, the port of Apache 2.0 to BeOS is coming along nicely, and is showing some very promising early numbers. The multithreadedness of Apache 2.0 makes a great complement to the inherent multithreadedness of BeOS. I personally moved my own BeOS-hosted web site to BONE several weeks ago, and have been conducting public stress tests with mostly great results (the performance has been superb, but there have been some crashing bugs to iron out -- not unusual for beta software).

Much of the improved efficiency in BONE can be attributed to the fact that networking has moved out of user space (memory space used by applications) and into the kernel itself. While it does mean a slightly bulkier kernel, it also means that memory addressing and system calls are much faster than they were before (Linux and Windows NT also do networking in the kernel).

It also means that a bug in the network stack has the potential to bring down the system with a kernel crash, as protected memory doesn't protect processes running in kernel space. That means Be must get it right. So far, they appear to be on the right track, and kernel crashes in the beta have been infrequent. Oh, and by the way: BONE includes a compatibility library which will keep all of our old network applications humming along transparently, while new network apps will benefit from the improved efficiency.

Putting MUSCLE on the BONE

BONE isn't even available to the public yet, but already there's a fascinating piece of software for it. Level Control Systems' Multi User Server Client Linking Environment (MUSCLE) is a sort of über-architecture for all kinds of distributed computing, message-passing, and coordinated peer-to-peer networking tasks. A single MUSCLE daemon can negotiate communications between any number of users "out there" running MUSCLE-enabled applications. At first glance, MUSCLE looks like a bit of a dry project, far afield from the scintillating media stuff BeOS is known for. To understand why I think MUSCLE has the potential to make an impact on the face of BeOS computing, you need to understand what it does that similar projects for other platforms don't do, or don't do as well.

I've written here before about the power of the BMessage -- one of the most essential components of the BeOS API. The BMessage is responsible for everything from inter-application messaging and scripting to drag-and-drop or copy/paste operations. Every BeOS system is always managing a flurry of BMessages behind the scenes. The problem with the BMessage in network operations is that TCP/IP uses fairly unstructured packets, while the BMessage is highly structured. MUSCLE implements a network-savvy replacement class for the BMessage, so that this power can be extended across any TCP/IP network, and so that it can work across various platforms. The MUSCLE daemon lets client apps communicate peer-to-peer in a flexible and coordinated manner.

Because MUSCLE is open source, it can be customized into infinite permutations. Client-side MUSCLE implementations are likewise as varied as developers' imaginations. For example, LCS currently uses a MUSCLE server with their CueConsole audio station in the stage production The Education of Randy Newman in Costa Mesa, Ca. Rather than a single mixing board handling all the audio required to run the show, the theater deploys lots of modular control boxes connected via serial cables to a terminal server box, which converts the serial data into TCP packets. MUSCLE connects these ports and communicates with the control modules to let the sound engineer control the show in unusual ways.

Back on earth, a MUSCLE client application for BeOS called BeShare lets BeOS users around the world chat and share files Napster-style, but with a difference: Because MUSCLE and BeShare are attribute-savvy, users can see and (soon) query on filesystem attributes, just as if they were sorting files and running database-like queries on their own systems. Unsurprisingly, users are treating BeShare mostly as an MP3 trading system for now, but it's equally well suited to run virtual offices for employees spread around the globe, or any other kind of file-sharing and communication.

BeShare and the CueConsole system are just two examples of the power of MUSCLE. Future implementations may include distributed graphics or video rendering farms, code cracking projects, automatic software update systems, live distributed video feeds (although video typically uses UDP rather than TCP), or anything else that could benefit from a combination of client/server and peer-to-peer networking with native messaging intelligence.

To learn more about developing MUSCLE-enabled apps, visit the MUSCLE homepage or read this BeNews tutorial.

Between the first reports of Be's new OpenGL performance, increasingly aggressive BONE testing, and the appearance of MUSCLE and the ultra-cool BeShare, it's been an exciting couple of weeks for BeOS users. It's going to be even more amazing to see these components emerge from beta and start being used on a daily basis by gamers and webmasters. No date has been set for the next BeOS release, but by the looks of things, these critical performance boosts aren't too far off.

BeView Content Archives