This is the mail archive of the xsl-list@mulberrytech.com mailing list .


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

RE: XSL-List Digest V3 #1125


CA> Is anyone aware of any XSLT processors that make use of parallel
processing
CA> to increase speed, or any reasearch in this area?

DM>Excellent question!

DM>XSLT is suited "by design" to parallel execution -- no need to conver the
source
DM>code of a stylesheet to parts that can be executed in parallel.

DM>Not too-long ago I pointed out an approach for building recursive
templates based on
DM>the implementation of "Divide and Conquer" algorithms. This is
straightforward
DM>usable with an XSLT processor that can take advantage of an existing
multiprocessor
DM>configuration.

DM>The general conclusion is to prefer DvCq algorithms to Head + Tail
recursive
DM>algorithms in case of multiprocessor execution platform and cognisant
XSLT
DM>processor.

DM>Therefore, the same question again -- it is ***important***!:

I think so too, and I am intending to build a parallel-processing XSLT
processor to do some exprimentation - hence the question - I wanted to find
out if any research has been done yet.

CA> Hello developers, is there a single XSLT processor that will
CA> make use of a
CA> multiprocessor platform in executing a transformation?

MK>I think if there were, we'd know about it.

MK>The design challenge, of course, is making sure that the synchronisation
MK>overheads don't swamp the gains. A common experience with parallel
execution
MK>is that only 30% of the run time turns out to be parallelisable - for
MK>example, it's hard to see how you could do the XML parsing, tree
building,
MK>and result tree serialisation in parallel.

DM>I think the above statistic is from attempts to parallelize imperative
style
DM>programs -- not functional style ones. It is obvious that in the former
DM>synchronisation problems will prevail.

Of course, I will be using a pure functional language to write the processor
- I think this will also be a
quicker approach than trying to take existing source code (Saxon, for
instance), and trying to parallize it.
But first I have to make the XML parser that I have (HaXml) namespace aware.

DM>What we're talking about is to perform in parallel the "sequential" flow
of the
DM>transformation, e.g.:

DM><xsl:apply-templates select="$nodeset1"/>
DM><xsl:apply-templates select="$nodeset2"/>
DM><xsl:apply-templates select="$nodeset3"/>

DM>or

DM><xsl:call-template name="someDvCqtemplate">
DM>  <xsl:with-param name="theNodeSet" select="$half1"/>
DM></xsl:call-template>
DM><xsl:call-template name="someDvCqtemplate">
DM>  <xsl:with-param name="theNodeSet" select="$half2"/>
DM></xsl:call-template>

DM>etc...

DM>In nontrivial transformations the time to perform such parts of a
transformation
DM>(essentially all content-producers) may be 50%, 80% or even higher of the
total time
DM>to perform the transformation.

DM>A simple example (only to illustrate my point!) is reversing a 1MB string
using a
DM>"divide and conquer" algorithm. It must be obvious, that much more than
30% of the
DM>time is parallelizable in this case. 

DM>(It is obvious that nothing will be gained in "parallelization" of a
head-then tail
DM>recursive algorithm.)

DM>And the majority of simple recursive algorithms have their "divide and
conquer"
DM>counterparts.

DM>Exploiting parallelism will make "practical" transformations that take
prohibitively
DM>long time if handled sequentially, thus increasing the power and
usefulness of XSLT
DM>applications.

OK, when I've actually got something written (I have yet to start), I'll ask
you for some suitable test cases.

colin@colina.demon.co.uk


KSS Ltd
A division of Knowledge Support Systems Group plc
Seventh Floor  St James's Buildings  79 Oxford Street  Manchester  M1 6SS  England
Company Registration Number 2800886 (Limited) 3449594 (plc)
Tel: +44 (0) 161 228 0040	Fax: +44 (0) 161 236 6305
mailto:kssg@kssg.com		http://www.kssg.com


The information in this Internet email is confidential and may be legally privileged. It is intended solely for the addressee(s). Access to this Internet email by anyone else is unauthorised.

If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited and may be unlawful. When addressed to our clients any opinions or advice contained in this Internet email are subject to the terms and conditions expressed in the governing engagement letter or contract.

This email message and any attached files have been scanned for the presence of computer viruses.  However you are advised that you open any attachments at your own risk.

 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]