Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Java > Java (bytecode) execution speed

Reply
Thread Tools

Java (bytecode) execution speed

 
 
Lee
Guest
Posts: n/a
 
      04-29-2007
All other things being equal, we expect an interpreted language to run a
bit slower than native machine code.

I understand that in the beginning, the earliest version of the JVM was
perceived to be demonstrably slower than a coresponding C program; but
that more recent versions have impreved coniderably.

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?

Obviously it all depends on what you're doing and how you're doing it,
but still, there must be some rough rule of thumb as to what's a
reasonable expectation for how by Java program should run compared to
the equivalent C routine.

I'm asking programmers, rather than the "announcement/advocacy" groups
in the hopes you will have a more realistic idea of how things actually
work under the sphere of the moon.


 
Reply With Quote
 
 
 
 
Chris Smith
Guest
Posts: n/a
 
      04-29-2007
Lee <(E-Mail Removed)> 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
 
Reply With Quote
 
 
 
 
Stefan Ram
Guest
Posts: n/a
 
      04-29-2007
Chris Smith <(E-Mail Removed)> writes:
>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.


Two quotations regarding gargabe collection:

»Your essay made me remember an interesting phenomenon I
saw in one system I worked on. There were two versions of
it, one in Lisp and one in C++. The display subsystem of
the Lisp version was faster. There were various reasons,
but an important one was GC: the C++ code copied a lot of
buffers because they got passed around in fairly complex
ways, so it could be quite difficult to know when one
could be deallocated. To avoid that problem, the C++
programmers just copied. The Lisp was GCed, so the Lisp
programmers never had to worry about it; they just passed
the buffers around, which reduced both memory use and CPU
cycles spent copying.«

<XNOkd.7720$(E-Mail Removed)>

»A lot of us thought in the 1990s that the big battle
would be between procedural and functional
programming, and we thought that functional
programming would provide a big boost in programmer
productivity. I thought that, too. Some people still think
that. It turns out we were wrong. Functional
programming is handy dandy, but it's not really the
productivity booster that was promised. The real
significant productivity advance we've had in programming
has been from languages which manage memory for you
automatically. It can be with reference counting or
garbage collection; it can be Java, Haskell, Visual Basic
(even 1.0), Smalltalk, or any of a number of scripting
languages. If your programming language allows you to grab
a chunk of memory without thinking about how it's going to
be released when you're done with it, you're using a
managed-memory language, and you are going to be much more
efficient than someone using a language in which you have
to explicitly manage memory. Whenever you hear someone
bragging about how productive their language is, they're
probably getting most of that productivity from the
automated memory management, even if they misattribute it.«

http://www.joelonsoftware.com/articles/APIWar.html

 
Reply With Quote
 
Stefan Ram
Guest
Posts: n/a
 
      04-29-2007
Supersedes: <(E-Mail Removed)-berlin.de>

I would like to add two quotations to this thread:

»Your essay made me remember an interesting phenomenon I
saw in one system I worked on. There were two versions of
it, one in Lisp and one in C++. The display subsystem of
the Lisp version was faster. There were various reasons,
but an important one was GC: the C++ code copied a lot of
buffers because they got passed around in fairly complex
ways, so it could be quite difficult to know when one
could be deallocated. To avoid that problem, the C++
programmers just copied. The Lisp was GCed, so the Lisp
programmers never had to worry about it; they just passed
the buffers around, which reduced both memory use and CPU
cycles spent copying.«

<XNOkd.7720$(E-Mail Removed)>

»A lot of us thought in the 1990s that the big battle would
be between procedural and object oriented programming, and
we thought that object oriented programming would provide
a big boost in programmer productivity. I thought that,
too. Some people still think that. It turns out we were
wrong. Object oriented programming is handy dandy, but
it's not really the productivity booster that was
promised. The real significant productivity advance we've
had in programming has been from languages which manage
memory for you automatically.«

http://www.joelonsoftware.com/articles/APIWar.html

Supersedes: <(E-Mail Removed)-berlin.de>
 
Reply With Quote
 
=?ISO-8859-1?Q?Arne_Vajh=F8j?=
Guest
Posts: n/a
 
      04-29-2007
Lee wrote:
> All other things being equal, we expect an interpreted language to run a
> bit slower than native machine code.


Since a Java is not interpreted but JIT compiled, then that point
is not so relevant.

> I understand that in the beginning, the earliest version of the JVM was
> perceived to be demonstrably slower than a coresponding C program; but
> that more recent versions have impreved coniderably.
>
> 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?


My expectations would be within the range 0.75-1.25 !

The variations between different C compilers with difference
settings and different JVM's with different switches and
the differences for different tasks is so big that the
language difference is insignificant.

Arne
 
Reply With Quote
 
Lee
Guest
Posts: n/a
 
      04-30-2007
Lee wrote:
> All other things being equal, we expect an interpreted language to run a
> bit slower than native machine code.
>

<SNIP>

At least two people were kind enough to point out that Java uses a JIT
compilation system and that in any case the difference of execution time
beween a Java progam and a hypothetical compiled version of the same
algorithm (or as similar as the two languages allow), would probably be
due more to the differences in heap managemant and/or garbage collection
than in raw compilation speed.

In that context it becomes plausible that in some circumstances Java
might actually run faster than an equivalent C/C++ implementation.

I must be missing an important nuance about Java and JIT.

Perhaps someone can "debug" me on this:

I had thought that bytcode was, so to speak, the "machine code" of the
Java Virtual machime. If that were true, I can't see how there would be
any room (or any need) for further compilation of the byte code. The
byte code itelf would "drive" the VM, taking the VM from internal state
to internal state until the computation was done.

But if the bytecode were just a portable abstraction, something "above"
the JVM's machine language but "below" the java source language, that
would create the need to compile the byte code "the rest of the way
down" to the actual jvm machine language, but NOT to native hardware
machine language.

So even in that case, the "compilation" would be down to the VM's
machine language, not the actual hardware's machine language.

But all the descriptions I see on the net about JIT talk in terms of
compilation to native machine language. I can see how that would work
with somethink like say the Pascal p-system, where pascal source would
be compiled into "p-code", and then the p-code would either be
interpreted or "just-in-time" compiled to native hardware machine language.

My problem is that in my conception, when it is a question of running a
virtual machine, the "compilation" would be to that vm's "machine"
language and thats as "low" as you could go.

What have I got wrong?
 
Reply With Quote
 
JT
Guest
Posts: n/a
 
      04-30-2007
On Apr 30, 3:48 pm, Lee <(E-Mail Removed)> wrote:
> I had thought that bytcode was, so to speak,
> the "machine code" of the Java Virtual machime.


It is.

>
> If that were true, I can't see how there would be any room
>


The Java Virtual Machine Specification is a precise document
on the meaning of bytecodes. So JIT compilers simply
attempt to produce native binaries that have the same behavior
as the bytecode.

I don't see how the JVMS prevents that.

>
> (or any need) for further compilation of the byte code.
>


The need is speed. Interpretation is much slower
than native execution.

> But if the bytecode were just a portable abstraction, something "above"
> the JVM's machine language but "below" the java source language


No. The byte code is the native machine code of the JVM.

> My problem is that in my conception, when it is a question of running a
> virtual machine, the "compilation" would be to that vm's "machine"
> language


The JIT does not compile to to the VM's machine language.
In fact, the JIT always compiles to the CPU's machine language.

>
> and thats as "low" as you could go.
>


Why? The JVM itself has full access to the Operating System
that the JVM is running on. Whenever you have native methods
(eg. some of the GUI methods and the IO methods...), the JVM
will have to invoke the corresponding services from the Operating
System.

So, a JVM could invoke a JIT to translate frequently-executed code
into a suitable binary format that the OS can execute.

I see no problem there. (And as you noted, there are many
powerful Java JIT out there)

- JT


 
Reply With Quote
 
Kai Schwebke
Guest
Posts: n/a
 
      04-30-2007
Lee schrieb:
> My problem is that in my conception, when it is a question of running a
> virtual machine, the "compilation" would be to that vm's "machine"
> language and thats as "low" as you could go.
>
> What have I got wrong?


In the end the code does not run on the vm, but on the real machine.
A runtime with "just in time compilation" compiles the virtual machine
code to real, machine dependent code much like a compiler would do.


Kai
 
Reply With Quote
 
Christian
Guest
Posts: n/a
 
      04-30-2007
Kai Schwebke schrieb:
> Lee schrieb:
>> My problem is that in my conception, when it is a question of running a
>> virtual machine, the "compilation" would be to that vm's "machine"
>> language and thats as "low" as you could go.
>>
>> What have I got wrong?

>
> In the end the code does not run on the vm, but on the real machine.
> A runtime with "just in time compilation" compiles the virtual machine
> code to real, machine dependent code much like a compiler would do.
>
>
> Kai

Is there any interpretation going on today in the jvm or is simply
everything compiled to machinecode just in time before execution?
 
Reply With Quote
 
JT
Guest
Posts: n/a
 
      04-30-2007
On Apr 30, 5:35 pm, Christian <(E-Mail Removed)> wrote:
> Is there any interpretation going on today in the jvm or is simply
> everything compiled to machinecode just in time before execution?


Depends on the JIT. The default JIT from Sun ("HotSpot")
will initially interpret the code. As the interpreter runs, HotSpot
then
analyzes the runtime behavior and try to identify which methods
should be compiled to native code.

See this section on Sun.com:
http://java.sun.com/products/hotspot...r.html#hotspot

- JT


 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
private data stashed in local/global execution context of PyEval_EvalCode disappears down the execution stack sndive@gmail.com Python 9 11-14-2007 10:31 PM
execution speed java vs. C nicolasbock@gmail.com Java 27 12-10-2004 10:09 AM
Java vs. JavaApplet execution speed =?ISO-8859-1?Q?Tomas_Bj=F6rklund?= Java 3 05-19-2004 12:21 PM
Comparing execution speed of Java to other interpreted languages. Dave Rudolf Java 6 01-14-2004 07:12 PM
speed speed speed a.metselaar Computer Support 14 12-30-2003 03:34 AM



Advertisments