Sept. 15, 1997

Technical and business requirements on embedded systems

The story

In light of last week's story on non-tangible computing, the following article excerpts from Electronic Engineeering Times (August) seem particularly relevant.

MOUNTAIN VIEW, Calif. -- Sun Microsystem's bid to reshape its Java programming language into a mainstay of the embedded-computing world is raising technical concerns among developers of real-time applications. [...]

The real-time community is already buzzing with talk that EmbeddedJava will fall short in addressing several crucial real-time performance issues. Leading that list are purported deficiencies in the way the language performs garbage collection -- the freeing up of memory locations no longer needed by an application program [...]

Anecdotal reports indicate that Java applications are from two to 40 times slower than equivalent programs written in C++. The drag comes largely because Java isn't compiled -- that is, converted before run-time directly from source code into machine code. Rather, Java is translated into an intermediate form, called byte codes, which then must be interpreted before execution on a target microprocessor.

On the plus side, the use of byte codes gives Java its vaunted platform independence, because the codes can run on any CPU equipped with a software-based Java Virtual Machine. But the negative is the drag in performance -- something that's made worse by Java's extensive reliance on bloated "packages," or software libraries that enable the language to implement graphics, printing and input/output features.

"The performance of Java is an issue," said Peter Schleider, embedded-systems market analyst at investment bankers Wessels, Arnold & Henderson, in Minneapolis. "A handheld device with lots of RAM will be an easy call for using Java." But Schleider thinks it'll be years before Java is the language of choice for deeply embedded apps such as microwave ovens or automotive controllers [...]

On the business side of the equation, Sun's hefty Java licensing fees are clearly a consideration for some vendors. An EmbeddedJava license reportedly costs $250,000 up front, with an additional $300,000 annually for maintenance. There's also a per-project tools charge of $50,000. Finally, RTOS vendors must pay royalties of $1 to $2 for each sale, depending on volume. (Sun declined to comment on its licensing fees.)

"That's high, and there's no room for negotiation," said an executive at one RTOS vendor who requested anonymity. "Also, it doesn't leave me much wiggle room for adding value. I can't recover my costs by charging more to my customer, because the royalty is already too high [...]

[A] consensus of sorts seems to be emerging. Namely, Java will be great for many so-called "soft" real-time applications -- those where timing constraints are less critical. However, for those applications requiring ultra-fast, known response times, languages such as C and assembler will still rule.

Read the complete article for more details.

Our comment

The technical side

The performance problems of Java are unlikely to go away any time soon. The absence of genericity means that accesses to simple container structures -- say a list -- can be extremely costly; yet what embedded application can do without containers? And the prospect of integrating a bytecode interpreter in an embedded application is rightly scary to any developer -- the penalty can be an order of magnitude or more.

ISE Eiffel and in particular Embedded Eiffel circumvent these problems. During development, the "Melting Ice Technology" (TM) uses a machine-independent bytecode; but final code generation produces C code, ensuring easy compatibility with existing legacy code, and optimal performance similar to that of applications written in plain C -- sometimes in fact better thanks to the extensive optimizations performed by the Eiffel compiler.

So with ISE Eiffel there is no need to include an interpreter in the execution environment. The execution environment executes machine code; users in search of performance won't settle for anything less.

Also unique is the performance of ISE's garbage collector, which is designed to work in a multi-threaded environment, enabling a thread to engage in garbage collection without disturbing other threads. Users of Embedded Eiffel have found this an essential requirement, not matched by other embedded tools.

The business side

The huge run-time fees associated with Java usage should make anyone think twice before committing to such a technology, especially with the technical problems described in detail in the article.

It is clear from the user reactions cited in the article that (as the Smalltalk experience shows) the market will not go for costly run-time solutions. With Embedded Eiffel there are no hidden costs. Adding to all the technical superiority, this is one more reason making Eiffel the choice of companies that want to build quality embedded products and profit from them.

Reference

Alexander Wolfe, Sun's EmbeddedJava stirs real-time doubt in Electronic Engineering Times, no. 966, August 11, 1997.

To other "news stories of the week".