commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jake Mannix <jake.man...@gmail.com>
Subject Re: [math] Performance optimization in the vector classes
Date Mon, 02 Nov 2009 20:51:58 GMT
On Mon, Nov 2, 2009 at 12:43 PM, Luc Maisonobe <Luc.Maisonobe@free.fr>wrote:

>
> There are several cases. If you do:
>
>  RealVector v = new ArrayRealVector(...);
>
> and later use v, a static analysis would be sufficient to know v is
> really an ArrayRealVector instance.
>

Ok, I was familiar with this, yes, and in this case, you never even
fall into the method which has the whole "try { return methodCall((ARV)v);
}"
implementation - you just skip right to the correct method, and all is good,
no if(), not thrown exception, top speed all around.


> If you have a more complex code, but at the beginning of the loops the
> JVM knows it has only loaded one class implementing RealVector, then the
> compiler will use that information when optimising the native code it
> creates at run time. If later a new implementation is loaded, then the
> JVM invalidates this code and redo the compilation using different
> assumptions for optimisation. This is one of the great things with
> dynamic compilation and optimisation. It adjusts itself according to how
> the code is used. Modern optimizers are really smart.
>

What I'm not sure about is that if you have complex code with lots of
mixtures
between different implementations of the interface, then my understanding
was
that eventually the JVM realizes it can't keep inlining and throwing away
the
inline, then doing it again and again, and drops back to the unoptimized
version, because, as you say, the compiler is smart, and realizes that it
can't win by continually changing this implementation.

In this scenario, the JVM has to throw exceptions and then catch them on
each method call where the cast is wrong.  This seems like a really nasty
performance bug to track down if this was the case.

Either way, I see that this idiom is not consistently applied: in
OpenMapRealVector,
the far more common if/else instead of try/catch is used for the flow
control.

  -jake

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message