Subject: Re: [xsl] Re: XSLT and parallel processing (Was: RE: XSL-List Digest V3 #1125) From: "cutlass" <cutlass@xxxxxxxxxxx> Date: Thu, 27 Sep 2001 14:09:14 +0100 |
just to add my 2p, i have been playing around with HaXml for awhile now, in other unrelated activities; though i am not the first to suggest it; its quite apparant that one could convert xslt to Haskell, then go from there to take advantage of parallel processing, then of course we wouldnt be doing XSLT anymore. i agree with DN that u would start with existing source and refactor those parts that could take advantage. cheers, jim fuller ----- Original Message ----- From: "Dimitre Novatchev" <dnovatchev@xxxxxxxxx> To: <AdamsC@xxxxxxxx> Cc: <xsl-list@xxxxxxxxxxxxxxxxxxxxxx> Sent: Thursday, September 27, 2001 2:01 PM Subject: [xsl] Re: XSLT and parallel processing (Was: RE: XSL-List Digest V3 #1125) > Colin Adams <AdamsC at kssg dot com> wrote: > > [summary of previous discussion snipped] > > > 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. > > Colin, > > The most direct way to go about it would be to re-use the source code of some > existing XSLT processor and modify only the stylesheet execution logic. > > The modification that has to be done does not seem too complex: > > For every member of a sequence S of (sibling) content-producing xsl instructions > (e.g. xsl:apply-templates) initiate its execution in a separate thread. When all > threads have completed, serialize their outputs based on their code position in the > sequence S. > > I'm making the assumption here, that there is an underlying OS that will be able to > execute different threads on different processors. > > Even if only the above is successful, this will be a significant achievement. > > I think that in the future the most valuable xslt code (e.g. standard template > libraries or xslt applications that are executed most frequently) will be accessed > in a pre-compiled form, therefore the need to speed-up xml parsing and stylesheet > compilation will not be so great. > > [snip] > > > OK, when I've actually got something written (I have yet to start), I'll ask > > you for some suitable test cases. > > Hope this time will come soon! :o) > > Cheers, > Dimitre Novatchev. > > > __________________________________________________ > Do You Yahoo!? > Listen to your Yahoo! Mail messages from any phone. > http://phone.yahoo.com > > XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list > XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
[xsl] Re: XSLT and parallel process, Dimitre Novatchev | Thread | RE: [xsl] Re: XSLT and parallel pro, Michael Kay |
[xsl] Re: XSLT and parallel process, Dimitre Novatchev | Date | [xsl] SAXON and UTF-8, Gustaf Liljegren |
Month |