Hi, On Sat, 2005-04-30 at 22:00 +0200, Arnaud Vandyck wrote: > Tue, 15 Mar 2005 15:35:56 +0100, > Michael Koch <konqueror@gmx.de> wrote: > > > You are right, its not always a gain. Tom Tromey told me that he is > > aware of one case where the native library is slower then interpreting > > the jar. > > I think it's faster when it starts up, and I think there are more than > one case where native is slower the Sun's JIT! ;-) I asked Tom what he meant with that. And he couldn't remember what the context was. There are certainly (micro) benchmarks where gcj generated code is slower then when executed by some other execution model. But there are also (micro) benchmarks where the opposite is true. Anthony Green has collected a couple of those: http://www.spindazzle.org/benchmarks/ But on average gcj is comparable with other execution models. Sometimes faster, sometimes slower. Some (old) benchmarks can be found here: http://www.shudo.net/jit/perf/ These don't have gcj 4 benchmarks yet though. Note that the future looks bright. For GCJ 4 the focus was on completeness and correctness. There have not been many optimizations yet. GCC 4.0 comes with a new (Tree SSA) infrastructure to make optimization passes easier. Hopefully there will be some time to use that for GCJ 4.x. If you have any examples where gcj is not doing very well, please write to the gcj mailinglist. Sometimes the developers don't know yet that an optimization might make sense. Then having examples of badly performing code will help to correct the problem in the future. See for example this message: http://gcc.gnu.org/ml/java/2005-04/msg00119.html Cheers, Mark
Attachment:
signature.asc
Description: This is a digitally signed message part