BeBox History
Be Newsletter Issue 52
December 4, 1996
CoffeeBean
By Jean-Louis Gassée
I just flew back from Maui by way of Pittsburgh, Pennsylvania. Using this
itinerary to raise questions about my sanity is fruitless -- I'm engaged in
work on an alternative personal computer platform to begin with. But,
seriously, I had a good reason. After taking my family of French pilgrims to
celebrate the ultimate American holiday in a locale more fitting our (vastly
exaggerated) hedonistic roots, I flew to Carnegie Mellon for the reading of
Paul Clip's thesis, CoffeeBean, a Java virtual machine implemented on the BeOS
under the tutelage of Professor Adam Beguelin.
It was good and useful fun. Developing applications for a platform still in its
infancy isn't for everyone. Writing system-level code is living even more
dangerously, especially at a time when the system is still changing at a fast
pace from one revision to another. So, Paul Clip's project wasn't only a test
of his intellect and manhood, but also a way to push our product in areas that
aren't necessarily probed in other developments. Overall, Paul was generous in
his comments, so much so I won't repeat the most enthusiastic ones. His work
pointed out to several weaknesses (in California, "areas for improvement").
Some have to do with differences with Sun's views of the world. For instance,
Java expects 64-bit signed integers, which are unavailable in the current
version of the C++ compiler on our system. There's also a difference between
the systems used by the two worlds for priorities and synchronization. An
opportunity for us to roadtest our kernel in subtle scheduling situations.
Paul's work also fingered a problem other Be developers have discovered, this
one related to hardware. Not all multithreading situations are dealt with
equally well by our system. When we moved from the AT&T Hobbit processor to the
PowerPC, the 604 was unavailable and projected to be prohibitively expensive
(for us at least). The 601 was clearly an ephemeral product. Only the 603 had
the future and the price we liked. There was one glitch, however: Motorola
stated that multiprocessor systems couldn't be implemented with the 603. On
closer examination, this techno-marketing statement was based on the absence of
cache-coherency hardware on the 603. Loosely speaking, cache coherency is a
function by which one processor can advise others of the "pollution" of data
contained in its cache, thus preventing its colleagues from reliance on
now-invalid copies of the same data in their own caches. We decided we could
work around that problem, mostly in software, and we produced working 603-based
dual-processor hardware. In most cases, the workaround we designed imposes an
invisible performance penalty. Now, imagine a situation where two threads, one
to each processor, work on the same data. This can give rise to sizable
overhead when the caches have to be constantly updated. One can construct cases
when two processors perform more slowly than when one BeBox CPU is turned off.
Fortunately, in real life, the system performs loosely coupled tasks most of
the time, and the 603 penalty isn't a factor. The 604 is now available, without
much of the earlier price penalty exacted on our small company with its limited
purchase power; it features cache-coherency hardware and thus does away with
the limitations of the 603 in MP applications. If not all, most PowerMac
licensees have 604 dual-processor hardware but not much system software to take
advantage of it, a situation we intend to deal with promptly.
Back to Carnegie-Mellon, we're grateful for Prof. Beguelin's hospitality, we
thank Paul Clip for his dissecting dissertation of our system, and we've
already incorporated several of his suggestions into the next release of our
system.
|
