Re: Concurrency in m3 - a status report

[Igor Fedorenko <ig...@ifedorenko.com>]

I am sorry if this has been answered already, but do you have any info
that shows performance comparison single vs milti threaded build? If you
happen to have any profiler snapshots that show where time is spent
during single and multi threaded builds, I am interested to see these too.

PS: we got first // build question on tycho-users list last week ;-)

--
Regards,
Igor

Kristian Rosenvold wrote:
> Now that the first Jira issue has arrived on parallel maven, I think
> it's time I do a little summary of how things are ATM. For those of you
> that don't routinely hang around at #maven-dev on irc:
> 
> I have found and fixed a series of insidious concurrency problems in
> several plexus components (thanks a million Benjamin for all help with
> discussing & patching those!)
> 
> The issues were:
> http://jira.codehaus.org/browse/MNG-4632 
> http://jira.codehaus.org/browse/PLXUTILS-130
> http://jira.codehaus.org/browse/PLXCOMP-149
> 
> The last two of these issues affect linear-maven-2.2.1 too and can be
> the cause of deadlocks (in numerous plugins) and data
> corruption/deadlock/other interesting behaviour in the jar/war/ear/?ar
> plugins. 
> 
> plexus-utils (2.0.5), plexus-io (1.0) and plexus-archiver (1.0) are the
> required dependencies to stay clear. I will file issues on the affected 
> plugins/modules RSN.
> 
> Both parallel mode and weave mode now work stunningly well, and all my
> test builds are green (or otherwise accounted for). I have one last
> minor update on weave that's running the tests now, and I'm targetting
> http://jira.codehaus.org/browse/MNG-4633 for beta-2. 
> 
> All of Arnaud's projects that I was able to build with regular m3 on
> java 6 also build with parallel m3 now.
> 
> The CI running the tests can be seen here; and it's quite interesting.
> I'll leave it to the reader to spot the 6-core i7 980X vs the C2D 2.5
> Ghz in those graphs ;)
> 
> 
> Weave mode: http://rosenvold.dyndns.org:8085/browse/PARALLEL-CH1W
> PArallel:   http://rosenvold.dyndns.org:8085/browse/PARALLEL-CH1
> 
> m3 weave: http://rosenvold.dyndns.org:8085/browse/PARALLEL-M31W
> m3 parallel: http://rosenvold.dyndns.org:8085/browse/PARALLEL-M31
> 
> 
> This CI has now run 40.000 parallel builds (most of which are
> non-public) and all errors are accounted for. Those of you surfing
> around a little more will see a couple of disabled builds, which also
> has known causes. 
> 
> 
> Plugins
> =========
> I have only managed to find "real" concurrency problems in the EAR
> plugin and modello as of yet. Modello is fixed in trunk, ear is
> not started AFIK.
> 
> All the other stuff I've seen in the core plugins relate to the
> plexus-issues. 
> 
> Our jira issue is from a user who's complaining about plugins not
> working, and I think he's somewhat right in that we have to make some
> kind of system to indicate compatibility with the -T option.
> 
> Although several strategies may be recommended, my personal favourite 
> is to make a @threadsafe javadoc annotation and make M3 core 
> COMPLAIN LOUDLY about plugins that are unmarked, then proceed as
> requested (i.e. complain but still run threaded).
> 
> The problem with these things is that thread safety is not necessarily a
> constant, and in the next 9 months there will be issues. So for some
> plugins @threadsafe might equally much express an intent as much as it
> reflects reality. So that makes me a bit sceptical to @threadsafe too. 
> 
> Aggressively displaying the link to the wiki page containing the 
> most up-todate threading info may be an equally good solution; maybe
> even adding a WARNING: Experimental  or something to the build output.
> 
> 
> http://cwiki.apache.org/confluence/display/MAVEN/Parallel+builds+in
> +Maven+3 (if it's up), should contain all the information needed on 
> which plugins are known to have issues. But as we all know, it's an open
> ecosystem.
> 
> Documentation
> ============
> I will keep the wiki page updated, provided cwiki.a.o actually stays
> up ;)
> I will add a section on mojo threading models/threading concerns to the
> mojo api specification.
> 
> 
> I think we have to take some extra measures to keep users out of the
> issue trackers on this one, or at least make sure they go to the right
> place.
> 
> What do you think ?
> 
> Kristian
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: Concurrency in m3 - a status report - performance

[Kristian Rosenvold <kr...@gmail.com>]

Den 26.04.2010 04:02, skrev Igor Fedorenko:
> I am sorry if this has been answered already, but do you have any info
> that shows performance comparison single vs milti threaded build? If you
> happen to have any profiler snapshots that show where time is spent
> during single and multi threaded builds, I am interested to see these 
> too.
>
> PS: we got first // build question on tycho-users list last week ;-)

Interesting question; and the answer is not /always/ as clear cut as one 
would think.
Regarding overall performance I added another linear build for comparison.
This is not a particuarly good showcase project, but such is life:

Linear: http://rosenvold.dyndns.org:8085/browse/PARALLEL-CH  (~36-37 
seconds)
Parallel: http://rosenvold.dyndns.org:8085/browse/PARALLEL-CH1 (~34-35 
seconds)
http://rosenvold.dyndns.org:8085/browse/PARALLEL-CH1W (~29-30 seconds)

Remember it's a build cluster with one C2D and one i7-980X, so the
tall columns are the C2D. There's a third node being added any day now 
(i7 920).
Please remember that this build cluster is heavily loaded, also with
non-public jobs - so per build variantions can be significant.

Unfortunately bamboo's average build time calculation does not produce
reliable results in a cluster with very different nodes, so this is just 
my estimate:

The topology of your build is the most important factor governing parallel
  performance. Weave mode is less sensitive to this. Both parallel modes
are sensitive to indidivudal mojo executions being slow, and it effects 
the overall build.
If your build process ends up creating a 500mb EAR file, it'll tend to 
marginalize
effects of a few modules running in parallel here & there. Weave mode 
does a real good
job with projects that have tasks evenly distributed across modules (as 
opposed to
all the real work happening in just a few specific mojo executions in 
one or two modules).
Surefire in test-phase is not phase-locked to the upstream test phases 
in weave mode
(Haven't done this for it-phase yet). Parallel is not always faster than 
linear, weave
is always fastest.

Focus up to now has been on achieving stability and functionality, and 
for the next month
or so making all mojos work reliably will be my top priority. Regarding 
performance
I have not really investigated too much yet, but I will ;)

I have a short list of things I want to investigate:
- According to "strace", File.exists() is being called twice for all 
access to any
    file in the local repository (affects all modes)
- I am almost sure there's one or more synchronization points somewhere 
within surefire
    that is reducing surefire performance needlessly.

Only the first issue is within core, and my gut feeling is that not much 
more performance
will be tweaked out of the core unless one manages to re-think at a 
higher level an even
smarter way of executing mojos and respecting dependencies. Someone 
please prove
me wrong, but I think the remaining performance will have to be found in 
the
plugins/libraries - and it will be found.

I have run serveral profiler tests, but I'm mostly studying threading 
effects currently.
Most of the stuff I've seen is "as expected", and only a small 
percentage of execution
happens within core (and a fair size of that is related to xml parsing, 
surprise...)





















---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org