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]
