[Date Prev][Date Next][Thread Prev][Thread Next] - [Date Index][Thread Index][Author Index]

Last response in off-topic language holy war [was: MARS rise & settimes]



This list isn't the place for a languages holy war, so here's my last 
response in this thread:

Anthony Monteiro wrote:

> Having taken a quick look at the source, it is clear that these
> benchmarks do not measure C++ versus Java language performance. The
> results reflect the performance of specific functions of
> certain library routines. The libraries are of course compiler
> dependent and they do not even have to be written in Java or C++
> to work.

Take a longer look at the source. All the "libraries" that are called 
directly by the Java version are written in Java. Only the JVM, Hotspot 
itself, and the interfaces to the bare OS are written in C, just as only 
tiny pieces of a modern OS are written in the target platform's 
assembler, the bulk being written in C.

The current standard Java runtime libraries contain an astonishing 
amount of high-level functionality, everything from math functions and 
arbitrary-precision arithmetic to XML parsing, object serialization, 
image handling, protocol-level networking support, DBMS interface, 
internationalization and localization...the list goes on, and only in 
the most very primitive places is any C code involved at all. Native 
code is held to an absolute minimum. All the rest of the runtime 
libraries are Java code, and the source is provided with the Developers 
Kit in most cases.

> Speed was never the reason for Java and the reality is that the
> Java language is much slower than C++. It is easy to understand
> why since they have similar syntax but Java is interpreted
> (even "compiled" Java.) Phil gets the cigar on this one!

Before you boys go handing out cigars to each other, read up on 
just-in-time optimization technology and the Hotspot compiler (yes, it's 
a "real" compiler, with native code as the target) used in modern Java 
runtimes.

The "it must be slower because it's interpreted" argument is simplistic 
and outdated; optimizations are possible at runtime that are out of 
reach of even the smartest static compiler...including decisions about 
which codepaths it's even worthwhile to bother to optimize.

> C/C++ is fast enough to run on a DSP and has been used in
> commercial DSP products but I cannot even imagine running
> Java on a DSP.

We weren't talking about a specialized DSP chip application here, we 
were talking about Mars24. That said, the main reason you program a DSP 
in C is because (1) programming it in assembler is too tedious and 
error-prone, and (2) there are no other options.

"Too tedious and error-prone" are exactly why at the application level 
Java shines over C. C is not much more than a (mostly) CPU 
architecture-independent assembler (which is what it was designed to be) 
not an applications language. And one performance measure where I 
gauantee a win for Java *every* time is development time of anything 
bigger than a breadbox (especially if a penalty is assesed for coding 
defects).

> Additionally, the non-deterministic run-time behavior of Java
> makes it problematic if response time is a critical factor.

If *deterministic* response time is a critical factor--which it is only 
in tightly speed-constrained embedded applications running at the edge 
of hardware capabilites. Again, not the usual application environment, 
and certainly not the situation in something like Mars24.

It's also possible to take manual control of the garbage-collection 
services to make response time much more consistant, when that is 
important.

> Don't get me wrong, I am not anti-Java and I have used it in
> several commercial products over the years where it's strengths
> made it appropriate but it is not in any way "faster" than C++.

"Not in any way 'faster'"..."remarkably inefficient"...you guys need to 
rein in your hyperboles. :-) The cited benchmarks show that Java on a 
modern Java runtime can turn in performance comparable to C on many 
everyday problems. "Java is always very slow" is a canard from the early 
days of the technology that deserves serious debunking.

This isn't exactly a new argument, by the way...the very same argument 
has existed since the early 1950's (before there even was FORTRAN, much 
less C or Java) to argue in favor of hand-coded machine language over 
the use of any sort of compiler at all. That's the subject of a 
forthcoming short article of mine that will be appearing in Java 
Developer's Journal soon; I'll let you folks know when it appears.

    73 de Maggie K3XS

-- 
-----/___.   _)Margaret Stephanie Leber CCP, SCJP/"The art of progress /
----/(, /|  /| http://voicenet.com/~maggie SCWCD/ is to preserve order/
---/   / | / |  _   _   _    `  _  AOPA 925383/ amid change and to  /
--/ ) /  |/  |_(_(_(_/_(_/__(__(/_      K3XS / preserve change amid/
-/ (_/   '        .-/ .-/        ARRL 39280 /order."-A.N.Whitehead/
/________________(_/_(_/_______AMSAT 32844_/<maggie@voicenet.com>/


----
Sent via amsat-bb@amsat.org. Opinions expressed are those of the author.
Not an AMSAT member? Join now to support the amateur satellite program!
To unsubscribe, send "unsubscribe amsat-bb" to Majordomo@amsat.org



AMSAT Top AMSAT Home