--- Steve Loughran <[EMAIL PROTECTED]> schrieb:
> Michael Meyer wrote:
> >> --- Steve Loughran <[EMAIL PROTECTED]> schrieb:
> >>> this is really interesting. I'd thought javac
> was
> >>> unthreaded too, but
> >>> even so you'd expect file IO to work in the
> other
> >>> CPU, so get a boost
> >>> from the second core.
> >>>
> >>> what happens when you try a different javac,
> like
> >>> the eclipse one?
> >
> > In order to rule out any pathologies in my ant
> build
> > file or my source code, I benchmarked a compile
> run
> > again, this time the compilation of the Ant 1.7.0
> > source code.
> >
> > Additionally, I have deinstalled the powernowd
> > package, so the frequency of the cpu is not
> reduced
> > when idle, rather all the time at 2.4 GHZ (Intel
> Core
> > 2 Duo E6600).
> >
> > Compile run this time with:
> >
> > ant clean ; ant build ; ant clean ; sleep 10 ;
> time
> > ant build
> >
> > (This way, every file to be compiled and the jdk
> files
> > are preloaded into memory, and before the timed
> ant
> > build there is a wait period of 10 seconds so that
> the
> > journal daemon from the ext3 file system can write
> all
> > emitted byte code files (done every 5 seconds by
> > default) before the actual compile run starts.)
> >
>
> -this is interesting stuff. Stick it up on a web
> page and I'll point to it.
>
> At the same time, I dont know why it is happening.
> It does hint at
> something I've been seeing on my desktop though, in
> which builds in
> VMWare images (with a single CPU option) seem faster
> than the stuff on
> the main desktop.
>
> 1. I wonder if we are doing some kind of
> synchronisation on I/O that is
> causing us to take longer to acquire locks?
>
> 2. A good test would be to focus on javac and see if
> a .sh script to
> build the classes shows the same slowdown. if it
> does, its a javac
> problem. If it doesnt, its an ant problem.
>
I did only manage to do a quick javac run with the
Main java class:
time javac -sourcepath src/main/
src/main/org/apache/tools/ant/Main.jav
1 core:
real 0m1.900s
user 0m1.812s
sys 0m0.040s
2 cores:
real 0m1.436s
user 0m1.828s
sys 0m0.076s
whereas the complete compile run with ant (time ant
build) was:
1 core:
real 0m4.520s
user 0m4.312s
sys 0m0.176s
2 cores:
real 0m8.150s
user 0m14.849s
sys 0m0.400s
(both with the Sun JDK 6 Update 5).
So I guess this hints strongly to ant and not the
compiler antd/or vm causing the slowdown on two cores.
There is a tiny overhead with two cores at the user
and sys times, but real (the actual wall time) goes
down by almost 25% on two cores, despite the fact that
javac does not seem to be multithreaded. So this
effect will be caused by the I/O operations done by
the OS on the second core, as you mentioned.
On the other hand: the actual wall time of the
complete ant build is 80% slower on two cores than on
one core. This is caused almost solely by the 244%
increase of the user time (sys time increased by 127%,
but very low absolute). The sys time of the compile
run without ant is only increased by less than 1%.
As the main part of the bump in the wall time clock is
caused by the 244% of the time spend in user space,
this might suggest, that it has nothing to do with I/O
synchronisation, but instead it must be caused by some
actual part of the ant code? Or am I wrong?
Lesen Sie Ihre E-Mails jetzt einfach von unterwegs.
www.yahoo.de/go
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
