Optimization - any idea of actual machine code?

[Russell Wallace]

Hi all,

I've got some number crunching code I'm thinking of writing in Java,
and I'm wondering, after all algorithm-level optimization is done, is
there any way to view the actual machine code the JIT ends up
generating (I'm using version 1.4 under Windows if it matters), or get
some idea of what sort of optimizations it's likely to be capable of?
In C I'm used to being able to look at the compiler's output; of
course, looking at the byte codes isn't useful in this context
(they're definitely not optimized) - I assume the JVM can do basic
optimizations like common subexpression elimination? Can it inline
small static methods, for example?

Thanks,

 

[Roedy Green]

I've got some number crunching code I'm thinking of writing in Java,
and I'm wondering, after all algorithm-level optimization is done, is
there any way to view the actual machine code the JIT ends up
generating (I'm using version 1.4 under Windows if it matters), or get
some idea of what sort of optimizations it's likely to be capable of?
In C I'm used to being able to look at the compiler's output; of
course, looking at the byte codes isn't useful in this context
(they're definitely not optimized) - I assume the JVM can do basic
optimizations like common subexpression elimination? Can it inline
small static methods, for example?

If you had an assembler debugger you could view it, but I don't have
one that works on 32-bit code.

With static compilation, see
http://mindprod.com/jgloss/nativecompiler.html you can examine the exe
file with some sort of disassembler. Again, I don't have one for
32-bit code.

If it crashes, you could examine the dump. You could force a crash
with a bit of JNI.

If you get really desperate, I suppose you could search the exe file
for strings of hex you expect will be generated, and then snoop at the
surrounding bytes, using your pentium manual to look up op codes.

 

[Jesper Nordenberg]

Hi all,

I've got some number crunching code I'm thinking of writing in Java,
and I'm wondering, after all algorithm-level optimization is done, is
there any way to view the actual machine code the JIT ends up
generating (I'm using version 1.4 under Windows if it matters),

Don't know if you can somehow view the native code produced by
HotSpot. I'm sure the Sun engineers know how to.

or get
some idea of what sort of optimizations it's likely to be capable of?
In C I'm used to being able to look at the compiler's output; of
course, looking at the byte codes isn't useful in this context
(they're definitely not optimized) - I assume the JVM can do basic
optimizations like common subexpression elimination? Can it inline
small static methods, for example?

Have a look at:

http://java.sun.com/products/hotspot/

/Jesper Nordenberg

 

[Andy Fish]

Hi all,

I've got some number crunching code I'm thinking of writing in Java,
and I'm wondering, after all algorithm-level optimization is done, is
there any way to view the actual machine code the JIT ends up
generating (I'm using version 1.4 under Windows if it matters), or get
some idea of what sort of optimizations it's likely to be capable of?
In C I'm used to being able to look at the compiler's output; of
course, looking at the byte codes isn't useful in this context
(they're definitely not optimized) - I assume the JVM can do basic
optimizations like common subexpression elimination? Can it inline
small static methods, for example?

Thanks,

Presumably if you're interested in the exact machine code generated, this is
because you have a requirement for highly optmimized performance.

In this case, I can't help but wonder why you chose to implement the system
in java. If there are just a couple of algorithms that need to be finely
tuned maybe you should use JNI and implement those in C.

Even if you can find a way to change the machine code that gets executed for
a particular piece of java code, this won't be portable across hardware or
JVMs

 

[Chris Smith]

In this case, I can't help but wonder why you chose to implement the system
in java.

I'm not the OP, but the fact that Java consistently outperforms most
other languages except for Fortran in floating-point calculation on many
common hardware platforms could have something to do with it... or it
might just have to do with ease of interacting with other code that's
written in Java and expected to run in-process. Do we need to have this
discussion every time another troll sees another opportunity to beat the
dead horse?

If there are just a couple of algorithms that need to be finely
tuned maybe you should use JNI and implement those in C.

Careful here. Aside from the obvious factors (that C code may well end
up being slower to begin with), the cost of crossing the JNI boundary is
very large when compared to performance differences between Java and C.
You're likely to see a serious drop in performance from the effort to do
the type coercions and such needed to cross between C++ and Java. If
the C code does benchmark substantially faster, it's a good idea to
design a higher-level API in the native language, in order to minimize
the number of switchover points.

Even if you can find a way to change the machine code that gets executed for
a particular piece of java code, this won't be portable across hardware or
JVMs

This is a very good point. When you ask this question, the answer has
to be at least specific to JVM vendors and platforms; and what's more,
it's likely to be specific to the specific deployment hardware and
environment. For example, your average C compiler will generally target
only the common operations between an entire family of processors unless
you specifically choose otherwise, but a JIT compiler will generally
make use of whatever specific performance tricks are available for
whatever processor you've really got. Decisions on inlining or not may
be similarly based on how much memory is available to the process, and
its danger of swapping, and what the JIT knows about your processor's
branch optimization abilities.

Even further, you need to specify at what *point* in the execution you
want to know this stuff. Code may be changed around dynamically at
runtime at arbitrary points. For example, a virtual method call may be
inlined at one point because the compiler knows that you've only
instantiated one kind of object so there's only one possible target
method implementation; but that optimization can be undone when you
later load a new class that overrides the method and create an object of
that.

In essence, the answer to the OP's question is likely to be far more
complicated than the OP expects. Things just aren't that simple any
longer.

--
www.designacourse.com
The Easiest Way to Train Anyone... Anywhere.

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation

 

[marcus]

Wow Andy -- I took the exact opposite tack with this post.
I figure, anybody who has the chops to really optimize code better than
a modern compiler has no need to post such a ridiculous question here.
-- clh

Hi all,

I've got some number crunching code I'm thinking of writing in Java,
and I'm wondering, after all algorithm-level optimization is done, is
there any way to view the actual machine code the JIT ends up
generating (I'm using version 1.4 under Windows if it matters), or get
some idea of what sort of optimizations it's likely to be capable of?
In C I'm used to being able to look at the compiler's output; of
course, looking at the byte codes isn't useful in this context
(they're definitely not optimized) - I assume the JVM can do basic
optimizations like common subexpression elimination? Can it inline
small static methods, for example?

Thanks,

Presumably if you're interested in the exact machine code generated, this is
because you have a requirement for highly optmimized performance.

In this case, I can't help but wonder why you chose to implement the system
in java. If there are just a couple of algorithms that need to be finely
tuned maybe you should use JNI and implement those in C.

Even if you can find a way to change the machine code that gets executed for
a particular piece of java code, this won't be portable across hardware or
JVMs

 

[Russell Wallace]

Presumably if you're interested in the exact machine code generated, this is
because you have a requirement for highly optmimized performance.

In this case, I can't help but wonder why you chose to implement the system
in java. If there are just a couple of algorithms that need to be finely
tuned maybe you should use JNI and implement those in C.

Because cross-platform capability is a higher priority than
performance. (I can make any program run as fast as you like if it
doesn't have to work.)

That said, after tuning the code a bit and comparing it with a C++
test version, the two actually run about neck and neck so that'll do
fine.

(It seems to be spending most of its time in the floor() function; I
guess there isn't a way to make that go fast on a Pentium 3, or if
there is then neither Java nor Microsoft C++ 4.2 know about it.)

 

[Russell Wallace]

In essence, the answer to the OP's question is likely to be far more
complicated than the OP expects. Things just aren't that simple any
longer.

Oh, I'm familiar with the issues you outline (but thanks for the
explanation anyway). There are times, though, when you get to a point
where you're better to take the best simple answer and move on rather
than spend more time investigating the complex ones; and I'm now at
the point where "it's about as fast as C++" is such an answer ^.^