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]