Re: AMPC 1.4.3 released (C to Java Class Files compiler suite)

"Eric" <englere.geo@yahoo.com>
18 May 2006 23:52:52 -0400

          From comp.compilers

Related articles
AMPC 1.4.3 released (C to Java Class Files compiler suite) napi@axiomsol.com (napi) (2006-05-11)
Re: AMPC 1.4.3 released (C to Java Class Files compiler suite) englere.geo@yahoo.com (Eric) (2006-05-15)
Re: AMPC 1.4.3 released (C to Java Class Files compiler suite) gah@ugcs.caltech.edu (glen herrmannsfeldt) (2006-05-16)
Re: AMPC 1.4.3 released (C to Java Class Files compiler suite) englere.geo@yahoo.com (Eric) (2006-05-18)
Re: AMPC 1.4.3 released (C to Java Class Files compiler suite) DrDiettrich@compuserve.de (Hans-Peter Diettrich) (2006-05-22)
Re: AMPC 1.4.3 released (C to Java Class Files compiler suite) gah@ugcs.caltech.edu (glen herrmannsfeldt) (2006-05-22)
| List of all articles for this month |

From: "Eric" <englere.geo@yahoo.com>
Newsgroups: comp.compilers
Date: 18 May 2006 23:52:52 -0400
Organization: http://groups.google.com
References: 06-05-03806-05-053 06-05-057
Keywords: Java, performance

The problem comes in the form of terrible efficiency. As I understand
it, array indexing in the JVM wouldn't be able to take advantage of the
fact that you're accessing a sequential range of bytes. Something like
this is very efficient in native code, but would slow down by maybe
10-100 times if you have to use array indexing and you have to re-index
into the array each time thru the loop.


This C code is very efficient:


        while(*p++)
                do_something(p);


Maybe a Java translation might be something like this:


      for (int i=0; i < p.length(); i++)
              do_something(p[i]);


These look similar, but the C-produced native code can use an index
register to scan memory efficiently. The Java-produced byte code would
likely re-index into the array for each iteration through the loop.
Array indexing is pretty slow because you don't get the advantage of
knowing that you're accessing a sequential range of bytes. Maybe a JIT
compiler could do something to make this more efficient, but it seems
like this would perform poorly in an interpreted JVM.


However, if the JVM understood the concept of dereferencing a pointer
to a memory location this could be much faster. This is done in the
.NET CLR and they were able to do it while still keeping type safety
and verifiable code. It's actually simple to define this type of
operation, but it looks to me that Sun went out of their way to avoid
doing this. Their fear of pointers was taken to an extreme, even though
it could have been done in a safe manner.


Eric


Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.