Ziga Mahkovec writes:
I upgraded to libgcj-4.0.0-0.32 and eclipse-ecj-3.1.0_fc-0.M5.12.
The results for compiling classpath:
ecj | ecj-native | jikes
-------------------------------------------------------------
real 1m31.786s | real 0m16.207s | real 0m8.423s
user 1m22.796s | user 0m14.925s | user 0m7.052s
sys 0m1.369s | sys 0m1.020s | sys 0m0.755s
(ecj-native went from 24.5s to 16.2s as a result of -O2)
I also uploaded oprofiles for ecj[1], ecj-native[2] and ecj-native-with-
the-old-gcjlib-tools-jar[3].
Note that I'm running a Centrino so the oprofile driver falls back to
timer interrupt mode.
[1]
http://www.bootchart.org/misc/ecj/M5.12/opreport.ecj.log
[2]
http://www.bootchart.org/misc/ecj/M5.12/opreport.ecj-native.log
[3]
http://www.bootchart.org/misc/ecj/M5.12/opreport.ecj-native-gcjlib.log
Thank you very much for doing this. It's very useful.
Jikes is famously fast, so I'm fairly pleased to see we're close.
It says here: "[Jikes] is astoundingly fast -- hundreds of thousands
of lines of code per minute (about ten times faster than other
compilers)"
There are some surprises here. Is ecj fully interpreted code?
_Jv_InterpMethod::run seems only to take 0.0036% of the time. I'm
going to investigate some more.
I'm sure that ecj-native isn't purely native code, because of this line:
399 2.2024 libgcj.so.6.0.0 _Jv_BytecodeVerifier::verify_instructions_0()
which is weird.
Thanks again,
Andrew.