Re: Java (bytecode) execution speed

Lee <Lee@xxxxxxxxxxxx> wrote:
All other things being equal, we expect an interpreted language to run a
bit slower than native machine code.

Okay, but there are no interpreted languages discussed in the rest of
your post. All common implementations of Java use a JIT compiler, which
should lead to to no foregone conclusions about whether it will be
faster or slower than a compiled language. There are reasons it's
likely to be slower (the compiler must run quickly, so it won't do a lot
of global optimization), and reasons that today's very sophisticated JIT
compilers for Java are likely to run faster (because it runs at runtime,
the compiler can take advantage of statistical information about how
users are using the application right now, and optimize them as the fast
cases).

If you are looking into performance numbers for Java, you are making a
mistake by focusing on the bytecode execution model. In the end, it's
about a wash -- no loss or gain there. The really important stuff is in
garbage collection and management of the heap. Java's language
definition is such that there are often far more heap allocations than a
typical C program, and they are far shorter lived. Different heap
management techniques are used to adapt to that situation. This affects
the performance of Java applications quite a lot.

On average, the best heap allocation management (including garbage
collection) algorithms out there perform slightly worse than a C-style
explicit heap with free lists. Of course, there are applications where
it performs much better because it reduces the amount of computation
that goes into book-keeping; and there are applications where it
performs much worse if the lifecycles of objects in the application are
unusual. (Some poorly performing cases, should you be interested, are
when a large number of objects live just ever so slightly long enough to
make it out of the nursery, or when there are lots of long-lived objects
that contain frequently modified references to very short-lived
objects.)

Whats the current state of the art? Would we expect a java program to
run at 0.5 * the speed of C, or 0.7 or 0.9 or what?

I'd say anywhere from 0.7 to 1.1 times the speed of C would be a
reasonable guess, depending mainly on the nature of object lifetimes.
But it's just that; a guess.

--
Chris Smith
.

Relevant Pages

  • Re: "STL from the Ground Up"
    ... high-level intermediate language than can interoperate with many other ... If your language lacks expressive features then you cannot write code ... memory management in comparison. ... Mostly because type errors mean that the programmer and compiler disagree ...
    (comp.programming)
  • Re: A note on computing thugs and coding bums
    ... It would handle international characters if the execution character ... method I used in "Build Your Own .Net Language and Compiler". ... work areas and counting on Nul is an illusion. ...
    (comp.programming)
  • Re: WaitForSingleObject() will not deadlock
    ... represent an incorrect implementation of the language. ... the *compiler* does not guarantee this. ... but to state it in terms of the execution instead of the formal semantics of the language ... as long as the optimizations do not change the semantics of the language). ...
    (microsoft.public.vc.mfc)
  • Re: subroutine stack and C machine model
    ... Use a compiler optimizer ... higher determinism means that optimizer has more information. ... C programmers like to brag that their "language" is more ... prospective computer science majors at Princeton. ...
    (comp.lang.c)
  • Re: "STL from the Ground Up"
    ... are not features of a language. ... To support reflection you make a compiler embbed type and functional information in the compiled program. ... When the OCaml compiler is given a complicated nested pattern match it ... virtual const Base *clone= 0; ...
    (comp.programming)