[XSL-LIST Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: Re: XSLT and parallel processing (Was: RE: XSL-Lis

Subject: Re: 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
xsl to haxml
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:  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

PURCHASE STYLUS STUDIO ONLINE TODAY!

Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.