Subject: [xsl] RE: XSL-List Digest V3 #1125 From: Colin Adams <AdamsC@xxxxxxxx> Date: Thu, 27 Sep 2001 10:57:24 +0100 |
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@xxxxxxxxxxxxxxxxxx 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@xxxxxxxx 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
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
[xsl] Re: loop in creation of table, Yang | Thread | [xsl] Euro symbol, José Farinha |
[xsl] Re: loop in creation of table, Yang | Date | [xsl] Euro symbol, José Farinha |
Month |