benchmark result

Mon Dec 6 13:57:00 GMT 2004

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. ZN4java4util14AbstractList17ドルhasNextEv and
 > ZN4java4util14AbstractList14ドルnextEv 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.