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: Re: XSLT and parallel processing (Was: RE: XSL-List Digest V3 #1125)


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@yahoo.com>
To: <AdamsC@kssg.com>
Cc: <xsl-list@lists.mulberrytech.com>
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


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