«

I have some super time-critical code, where I'm doing a lot of integer math
across very large arrays. Performance isn't as good as it could be. I'm
wondering if the fact that Java does bounds checking on every array access
could be slowing things up.

Question: is the bounds-checking performed in bytecode, or in native JVM
code? I'm thinking that if it's in bytecode, I could generate a little
custom code that turns it off for those time-critical methods.

On Tue, 05 Jul 2005 14:25:56 -0500, Chris wrote:

> Question: is the bounds-checking performed in bytecode, or in native JVM
> code? I'm thinking that if it's in bytecode, I could generate a little
> custom code that turns it off for those time-critical methods.

It is done in the JVM itself.

--
You can't run away forever,
But there's nothing wrong with getting a good head start.
--- Jim Steinman, "Rock and Roll Dreams Come Through"

"Chris" <anon> writes:

> Question: is the bounds-checking performed in bytecode, or in native JVM
> code? I'm thinking that if it's in bytecode, I could generate a little
> custom code that turns it off for those time-critical methods.

Run your program with

Java -Xprof

and it will most likely tell you that your code is *compiled*, and
that means native assembler code running.

Harald.

--
---------------------+---------------------------------------------
Harald Kirsch (@home)|
Java Text Crunching: http://www.ebi.ac.uk/Rebholz-srv/whatizit/software

On Tue, 5 Jul 2005 14:25:56 -0500, "Chris" <anon> wrote or quoted :

>I have some super time-critical code, where I'm doing a lot of integer math
>across very large arrays. Performance isn't as good as it could be. I'm
>wondering if the fact that Java does bounds checking on every array access
>could be slowing things up.

It does not really do an explicit check. It just has to make sure you
don't go out of bounds. So for example

for ( i<0; i<n; i++ )

if n in a final constant, then it only needs check once before doing
any looping.

If n is a variable in may have to check i once per loop iteration, no
matter how many references to i there are.

Clever compilers (see http://mindprod.com/jgloss/jet.html)
can be clever about avoiding the work while still ensuring 100%
safety.

--
Bush crime family lost/embezzled $3 trillion from Pentagon.
Complicit Bush-friendly media keeps mum. Rumsfeld confesses on video.
http://www.infowars.com/articles/us/...s_rumsfeld.htm

Canadian Mind Products, Roedy Green.
See http://mindprod.com/iraq.html photos of Bush's war crimes

On Tue, 5 Jul 2005 14:25:56 -0500, "Chris" <anon> wrote or quoted :

>Question: is the bounds-checking performed in bytecode, or in native JVM
>code?

There are bytecode ops in the Java virtual machine that do array
operations. See the goldfish book for details. Those ops have built-in
bounds checking. There are no explicit checks in byte code. Of course
the implementation of the Java victual machine on any real machine is
free to avoid actually checking whenever it can prove to itself it
would be safe. This is true both of jit and native compilation, but
not interpreter.


See http://mindprod.com/jgloss/disassembler.html
http://mindprod.com/jgloss/jasm.html


--
Bush crime family lost/embezzled $3 trillion from Pentagon.
Complicit Bush-friendly media keeps mum. Rumsfeld confesses on video.
http://www.infowars.com/articles/us/...s_rumsfeld.htm

Canadian Mind Products, Roedy Green.
See http://mindprod.com/iraq.html photos of Bush's war crimes

Chris wrote:
> I have some super time-critical code, where I'm doing a lot of integer math
> across very large arrays. Performance isn't as good as it could be. I'm
> wondering if the fact that Java does bounds checking on every array access
> could be slowing things up.
>
> Question: is the bounds-checking performed in bytecode, or in native JVM
> code? I'm thinking that if it's in bytecode, I could generate a little
> custom code that turns it off for those time-critical methods.

A native compiler (whether JIT or AOT) will remove the checks when it
is safe to do that. So you should write your code in a manner that
enables the compiler to remove checks. One rule of thumb is: "use 'for'
loops and do not change the loop variable anywhere inside the loop
body". I.e. your loops must be equivalent to the Pascal/Modula FOR
statement. Then, you better not call any methods from the loop body
except when you are sure they will be substituted inline by the
compiler. An example is final set/get methods.

Also, the bytecode supplied to the JVM must not be optimized. So use
the standard javac compiler to produce bytecode, and never ever use any
bytecode obfuscators/optimizers.

Finally, check out Excelsior JET and Excelsior's performance tuning
services:
http://www.excelsior-usa.com/jet.html
http://www.excelsior-usa.com/services30.html

The current version, Excelsior JET 3.7, is not very good at doing
floating point math, but for integer arrays it should be a killer.