Just think about it logically: if you have a multi-proc machine with good disks then yes, you can see performance improvements by building things in parallel. If you have a single-proc machine with a rinky-dink 5400 RPM drive then no, chances are that you won't see any performance benefit (and might even see a net increase in build time).
For WAS, we build in parallel at the sub-project level* & we saw some good build performance gains when the parallelism was introduced. That said, we have a dedicated build lab with very good hardware, so YMMV.
* - we use our own custom tasks for this instead of <parallel>, but the principle is the same
| ____________________________________________________________________________________________ | |
| Jeffrey E. (Jeff) Care | |
| IBM WebSphere Application Server Development |
WAS Pyxis Lead
Release Engineer
|
|
| |
Shree <[EMAIL PROTECTED]> wrote on 04/06/2006 08:31:26 AM:
> Hi Conor,
>
> You had said that "<parallel> was not intended as a performance
> enhancer, but the ant manual says
>
> Parallel tasks have a number of uses in an Ant build file including:
>
> * Taking advantage of available processing resources to reduce build
> time
>
> Following example was also cited in the ant manual
>
> <parallel>
> <javac ...> <!-- compiler servlet code -->
> <wljspc ...> <!-- precompile JSPs -->
> </parallel>
>
> "This example shows two independent tasks being run to achieve better
> resource utilization during the build. In this instance, some servlets
> are being compiled in one thead and a set of JSPs is being precompiled
> in another."
>
> Apart from <cc>, I have also experiment-ed using concat tasks, where
> there will be significant file i/o. Even then <parallel> is not at par
> with sequential. Any clarifications will be highly helpful.
>
> Thank you,
>
> Best rgds
> Shreedhar
>
>
>
>
>
> Conor MacNeill wrote:
>
> >Any performance improvement using <parallel> will depend significantly
> >on what you are doing in parallel and on what hardware resources your
> >platform provides.
> >
> >For example, the <cc> tasks could be interacting in ways you don't
> >expect. Maybe these tasks block each other somehow. I have no idea.
> >
> >In the end, <parallel> was not originally intended as a performance
> >enhancer. It was originally designed to allow you to run two operations
> >at once, where those operations may block without the other. The classic
> >example is starting a server and then running tests against that server.
> >These can not be performed sequentially.
> >
> >If <parallel> can deliver a performance benefit, that would be nice but
> >it will depend on your platform.
> >
> >Conor
> >
> >
> >Shree wrote:
> >
> >
> >>Hi Stefan,
> >>
> >>I tried evaluating the performance of "<parallel> task" with sequential
> >>way doing(without using <parallel>) a set of tasks. I find <parallel>
> >>does not help to improve the performance much and infact it sometimes
> >>even slower than sequential(as far I had experimented with some examples).
> >>
> >>I did several examples. One such method was - I tried compiling c files
> >>in 3 different folders(src1,src2,src3). The destination folder for the
> >>created objs were different say src1->obj1, src2->obj2, src3->obj3. I
> >>had 3 xml files, parallel.xml, sequential.xml and template.xml.
> >>Template.xml contains the logic for compiling cfiles.
> >>
> >><!- source of template.xml -->
> >><project name = "template" basedir="." default = "All">
> >><!-- the properties are passed as parameters from main build, in
> this>>case either parallel.xml or sequential.xml -->
> >> <target name = "All" depends = "create_dir">
> >> <cc name = "msvc" outtype = "executable" objdir = "${objdir}">
> >> <includepath path = "${includes}"/>
> >> <fileset refid = "${SrcID}"/>
> >> </cc>
> >> </target>
> >> <target name = "create_dir">
> >> <mkdir dir = "${objdir}"/>
> >> </target> </project>
> >>
> >>Parallel.xml is the main build file that invokes the target "all"
> >>within a parallel task, so all the c-files in the 3 different folders
> >>are compiled into objs parallely while sequential is another build file
> >>that invokes the target "all" for each folders sequentially(without
> >>parallel task). I expected parallel to finish faster, but found
> >>sequential outperforming parallel most of the times.
> >>
> >>Code snippet from parallel.xml
> >>-------------------------------
> >>
> >><parallel>
> >>
> >> <ant antfile="template.xml" inheritrefs="true">
> >> <property name = "SrcID" value="CSource"/>
> >> <property name = "includes"
> >>value="${env.include};${basedir}\cSource\Build"/>
> >> <property name = "objdir" value="${basedir}\Build1" />
> >> </ant>
> >> <ant antfile="template.xml" inheritrefs="true">
> >> <property name = "SrcID" value="CSource2"/>
> >> <property name = "includes"
> >>value="${env.include};${basedir}\cSource\Build"/>
> >> <property name = "objdir" value="${basedir}\Build2" />
> >> </ant>
> >> <ant antfile="template.xml" inheritrefs="true">
> >> <property name = "SrcID" value="CSource1"/>
> >> <property name = "includes"
> >>value="${env.include};${basedir}\cSource\Build"/>
> >> <property name = "objdir" value="${basedir}\Build3" />
> >> </ant>
> >></parallel>
> >>
> >>whereas in sequential.xml I do not use <parallel> task. Comparing the
> >>time for compiling files in sequential and parallel mode, I find using
> >><parallel> does not improve the performance. If one argues that there
> >>are " no i/o or legitimate cpu wait/sleep" in the above code, for which
> >>- I also experimented with task that performs file i/o(Concat task) in
> >>parallel and sequential mode, still there were no results in favor of
> >><parallel> task. What is wrong and where one should use "Parallel" tasks ?
> >>
> >>Thank you,
> >>
> >>Best regards
> >>Shreedhar
> >>
> >>
> >>
> >>---------------------------------------------------------------------
> >>To unsubscribe, e-mail: [EMAIL PROTECTED]
> >>For additional commands, e-mail: [EMAIL PROTECTED]
> >>
> >>
> >>
> >>
> >
> >---------------------------------------------------------------------
> >To unsubscribe, e-mail: [EMAIL PROTECTED]
> >For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
> >
> >
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
