Re: Java's poor performance? Not really - pick the right tool for the job!

At 09:25 PM 4/25/2004 -0400, Fred wrote:
>Hi all,
>
>I am completing a university project about Java in embedded systems.  I 
>have developed a realtime data acquisition system in Java (but I had to do 
>the deterministic scheduling using a native ISR).

TINI is not a good choice for realtime and deterministic performance. It 
doesn't claim to be. Why didn't you use a realtime capable system in the 
first place? I'll hazard a guess - TINI was attractive because of the 
price. But if you pay yourself even $50 per hour for the time you spent 
coding around the limits of that low price platform, could you have bought 
a more appropriate one? As a university student maybe that wasn't an 
option. The point is, you can't fairly blame your tools if you knowingly 
chose them for the wrong reasons (i.e. for cost alone, not whether they 
would do the job well).

>I am very curious to know why exactly Java takes so long to do even simple 
>things like assigning the values in an array.  I know it's only an 8-bit 
>microcontroller and this means that the bytecode translates into more 
>machine instructions than on a PC.  But this is the same with C!!!

It's not a Java issue. For what TINI or TStik costs you have to make your 
expectations reasonable. For the price, TINI is a remarkable value.

Java is inherently 32-bit so running it on an 8-bit machine means you take 
a hit right there. If the 80C400 was a 32-bit machine and otherwise the 
same it would be 4-5X faster than it is.

It's only "the same as C" if you compare it to a C interpreter which runs 
on dozens of hardware platforms, and includes a broad array of tested and 
robust, standards-based libraries. There is no such C beast. Remember - C 
has *no I/O* in its spec!! Every C TCP/IP and serial I/O library is 
different and unique. This is the yucky part of C.

>The difference in execution times is huge.   The interpreter overhead 
>shouldn't be as much as it seems to be.  I would have thought an 
>interpreter simply needs to translate the bytecode into machine code at 
>run-time.

Yes, one code at a time, looking them up in a table. TINI is not a JIT 
compiler. It's an interpreter.

>Why is Java so slow?

Don't confuse "TINI interpreter" with "Java". They are NOT the same. Java 
with JIT and Hotspot is very close to C performance, with all the benefits 
of Java to boot. Native execution Java is also very fast.

TINI's performance is also very quick when it's executing within a native 
library. There it is every bit as good as C, or even better, since Dallas 
has man-years of assy code tuning invested.

>Is it because Java interpreters are very inefficient and hence translate 
>the bytecode into many machine instructions?

In TINI, when you are in the Java domain, execution is much slower than in 
native due to the interpreter overhead.

>...or is is because of the garbage collector which keeps interrupting?

You can do some benchmarking yourself and see if that is the case with your 
code, for example:
http://www.practicalembeddedjava.com/benchmark/HeapTest/HeapTest.html

>...or is it because there are many instances of the interpreter sharing 
>the cpu?

No, interpreters are generally not re-entrant.

You should always pick the tools to fit the job and then pay what you have 
to, not the other way round. A used Toyota will cost a lot less than a 
Ferrari or a pickup truck, but it won't do the job of either. TINI is a 
great machine for "basic transportation". It's not an embedded PC, nor does 
it have the same performance as systems costing several times the price. 
Here are some comparative benchmarks:
http://www.practicalembeddedjava.com/benchmark/11a/benchmark_11a.html

Regards

Bruce




_______________________________________________
TINI mailing list
TINI-6tN4nzCoH/[email protected]
To UNSUBSCRIBE, edit your profile, or see list archives:
http://lists.dalsemi.com/mailman/listinfo/tini