[kaffe] Optimization?

[Jukka Santala]

On Mon, 27 May 2002, Dalibor Topic wrote:
> the -prof option on i386-linux with jit3. In that case
> the most popular method in HashMap is bucket. Most
> time is spent in the put method. The total time spent

bucket() is the other function called by find(Object) method, and most of
the calls typically come from that. put() is allowed to be slow-ish in
most hash implementations, because it is called relatively less often than
the lookup methods.

> in HashMap methods is less then 5 % of the total
> running time :( . Is there a specific application that
> you are referring to?

X-Smiles, ofcourse. And overall the hash-methods don't have that strong
impact, but I was surprised to see them at the top of the (for Classlib)  
profiles nonetheless. It makes good sense to have them relatively fast,
even if the optimizations only weight up to some 1% or so of the execution
time. Besides, oftentimes the hash lookups occur during interactive phases
of program execution. This is certainly the case for X-Smiles, where
viewing consists mostly of reading the DOM etc. rather than modifying it.
The low overall percentage is why I'm not goign overboard with it,
inlining whole get() method or trying the native approaches when just
inlining find(Object) seemed to give 25% (for that code path).

> I, too, would like to see more performance
> improvements to kaffe's libraries. However, I'm not
> sure if manual method inlining is the way to go. Here
> are my reasons: 

Yeah, the duplication is something I'm concerned with as well,
particularily as it also means that multiple copies of the code need to
exist in memory, and so some cache advantages could be lost. I'm not sure
duplicating a few critical codepaths in rather stable parts of the code is
all that significant for maintenance, though. In fact, some could argue
that trying to maintain a tangled spaghetti-code of nested calls to shared
methods whose changes could have unforeseen consequences to other
code-paths is harder.

And while I concur with the notion of automated optimization tools, these
are blind to application design issues and accumulated developer wisdom;
hence it's usually better to hand-optimize few trouble spots, than risk
things like the aforementioned cache-effects for whole code.

> I'd prefer to see a generic Klasses.jar that simply
> works, and different Klasses.jar's for download on
> kaffe.org for specific needs: a size optimized one and
> a speed optimized one. Both kinds of optimization

I'm not sure it would be so significant in the end, most people would not
bother picking one or the other, and often enough small size comes with
speed. Something I've thought of before is providing a "JDK 1.1 only"
classlib for those size-optimization purposes. This would require more
work than simple automated optimization-utilities, ofcourse, due to
differences in the API. But as it is, Kaffe can't run full Java2 anyway,
so most of the Java2 specific things are dead weight when it's being used
to primarily run JDK1.1 code.

> Could you write a few classes that extend HashMap and
> implement the optimizations you proposed?

Well, I did the basic inlining already, Kaffe native is bit over my head
currently, altough I could do JNI based version. Ofcourse, for this it
should probably be sufficient to just build soem stubs and a benchmark to
exercise them, for determining the relative overhead with different types
of calls on different platforms. The rest (native code performance) is
rather implementation and situation dependent.

> Regarding benchmarking: I would still like to see it
> coming to kaffe.org, you just need to push me harder
> ;) I've taken a look at ashes, and it kind of works

Well, the generic idea was to have contributors run it on their platforms,
so I really have mostly myself to blame for not having that ready. Altough
mostly, we didn't settle on what kind of benchmarks to run on it. It still
seems some standard open-source benchmark(s) would be preferable;
application-specifics are always good, but there may be less agreement on
what is pertinent, and in the end it won't work to require every
contributor benchmark every possible application others are using Kaffe
for. But I do suggest at least XML processing be included, as it has
become standard part of Java, and is a rather heavy test. Maybe we can
include some docbook benchmark or the like.

> for me: I had some trouble with getting the scripts
> and paths to work correctly. I'm also looking at IBM's
> jMocha, that seems to work well (except for result
> analysis, our serialization seems to have some bugs
> that are triggered by it). I also looked at coffeine
> Mark 3.0, that one works well with kaffe, but isn't

> open source or free software. Did you find time to
> take at look at a specific benchmarking toolkit?

I checked aroudn a bit, and was tending towards Ashes, but didn't even try
to egt the scripts running yet. Guess it's as good time as any.

 -Jukka Santala