benchmark result

[Andrew Haley]

Mathieu Lacage writes:
 > 
 > On Mon, 2004-12-06 at 12:15 +0000, Andrew Haley wrote: 
 > > Ouch!  Compile with -ffast-math and get some speedup.
 > 
 > I get a 18% wall-clock time improvement with gcc 3.4.3:
 > 
 > [mlacage@chronos treegrowth]$ time -p ./native/MainSimulation --max-
 > iterations=4000 --seed=1
 > real 8.68
 > user 8.44
 > sys 0.05
 > 
 > I get similar results with gcc 4.0.0 which brings the performance of
 > code generated by 4.0.0 on par with 3.4.3 (modulo the measurement noise
 > which seems to be around 0.1s).

OK, good.

 > >  >   7.79   3461.00   507.00                             ZN4java4util9ArrayList3getEi
 > >  >   4.98   3785.00   324.00                             Z20_Jv_IsAssignableFromPN4java4lang5ClassES2_
 > >  >   4.92   4105.00   320.00                             Jv_CheckCast
 > > 
 > > You're doing a lot of access to generic contatiners, so there's a lot
 > > of cast checks.
 > 
 > I use -fno-bounds-check -fno-store-check. Would it be possible to
 > disable more checks for my production builds ?

Not sanely, no.

 > > You're doing a great many interface calls.  I don't think gcj's
 > > interface dispatch is particularly slow, so interface dispatch might
 > > be just as significant a drain on runtime on other systems.  You might
 > > get better performance by using ArrayList in your code instead of
 > > AbstractList.
 > 
 > I do use ArrayList already. ZN4java4util14AbstractList$17hasNextEv and
 > ZN4java4util14AbstractList$14nextEv look like the iterator methods
 > hasNext and next.

Yes, I see.

We could improve the performance of these collection classes with
little work.  What is required is someone to study the code, do some
profiling, and fix things.

 > > As far as I'm aware the Boehm gc is fine, but we aren't taking
 > > advantage of the opportunity quickly to recycle very short-lived
 > > objects.  This is something that we can improve.  But to have gc use
 > > only 10% in an application really isn't tragically bad.
 > 
 > Well, this is for really short simulations: the overhead of the gc
 > increases with the length of the simulations because I build a data
 > structure whose size always increases. I have measured a (~2/3)%
 > wall- clock time usage for the GC in similar situations with the
 > sun JDK 1.5.0 and a rather naive profiler I wrote (It should be
 > noted that the results of the 1.5.0 jdk are not as good as the
 > 1.4.3 jdk and they are close to the results of gcc 3.4.3 without
 > -ffast-math).
 > 
 > An interesting optimization which is clearly impossible with the
 > sun JDK would be to mark this huge growing data structure as
 > outside of the scope of the GC. I have no idea whether or not this
 > is even remotely possible with gcj (hint: I am willing to follow
 > any advice which gives ideas on how to do this, even those
 > including hacking gcj itself).

Chapter 5 of the Real-Time Specification for Java describes the class
ImmortalMemory, which has methods such as newArray(Class, number) and
newInstance(Class).  We could implement that simply by switching the
memory allocator.  I don't know if the gc would continue to function.
Hans?

Andrew.