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
_______________________________________________ kaffe mailing list kaffe@kaffe.org http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
