ant-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Meyer <mike65...@yahoo.de>
Subject Re: Ant build slower on two cores than on one core?
Date Tue, 11 Mar 2008 12:58:41 GMT

--- Steve Loughran <stevel@apache.org> schrieb:

> Michael Meyer wrote:
> >>  --- Steve Loughran <stevel@apache.org> 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: user-unsubscribe@ant.apache.org
For additional commands, e-mail: user-help@ant.apache.org


Mime
View raw message