Kiyo Inaba wrote:
> I said,
>>>The latest weekly test failed for m68k/linux.
>>The fail files say everything is timeout and earlier snap does not have this problem.
>>> This is not true, at least for jit3. Just become much SLOWER :-<
>> For 050421 snap, 'time $JAVA HelloWorldApp' tells,
> real 5m8.022s
> user 1m52.930s
> sys 0m16.640s
> but for 050428 snap, it tells
> real 11m33.120s
> user 5m11.830s
> sys 0m20.880s
>> Since this mac is now compiling snap for intrp, and the 'real' may be slightly
> slower than an idle machine.
>
Hi Kiyo,
thanks for the bug report!
Is there any chance of comparing the two profile outputs for the
different snapshots to see where the time went? Looking at the list of
changes in that week, it seems that the major changes were the
integration of (and switch to) the nio charset handling from GNU
Classpath, and Double/VMDouble (inclding fdlibm) merge. I'd guess that
the former might be a cause for the delay you observed, but it would be
interesting to see if measures can confirm it.
My assumption would be that writing more of the core class libraries in
java penalizes the slower CPUs much more than it does so on fast CPUs.
Going from that assumption, I think there are a few things one could do
to improve performance on smaller machines, beside making the jit better. :)
1) update the gcj bindings to 4.0 so that we can use a prebuilt
rt.jar.so file, and don't have to jit everything. I believe Transvirtual
had some good success there with mips-based devices and their gcj fork.
2) Improve the interpreter, by getting the changes from ertl (jim huang
posted a patch for that, afaik), and latte merged in.
3) Merge in a mixed mode engine patch from latte. Mixed mode probably
only works well if the interpreter is not too slow, as the first
mixed-mode attempts with kaffe found no imrovement over just using the jit.
cheers,
dalibor topic