the width of your CPU limiting the number of iterations.
I think, the number of iterations is bound by the max-bound (on a
given hardware & compiler implementation) of the type used for the
Also, xsl:for-each is much easier to understand than a potentially
complex recursive function (you SEE that it is a loop, while you have
NOTICE that it is recursive).
very true :)
Also, xsl:for-each can (in theory) be implemented using parallel execution
while recursion necessarily must be a single core as it is up to the coder
where / when in
his particular algorithm the recursive call takes place.
your statement, that recursion cannot be parallelized, is true to a
large extent. But IMO, this cannot be generalized to every possible
I agree, that many "for loops" are potential candidates of
parallelization. I think parallelization support for "for loops" could
be available at following levels:
a) a given end-user program could try to do this (if the host language
provides support for parallel execution, say something like language
b) a language compiler could provide some support. IMO, since all "for
loops" cannot be parallelized, compilers could provide parallelization
support for specific scenarios. I think, the extent to which this
benefit could be provided by a compiler, is dependent on a
corresponding optimizer in a compiler.
c) there could be some support for parallelization at hardware level.
IMO, it's generally quite difficult (or impossible?) for compilers, to
exploit hardware-level parallelization benefits, if the compilers are
written in platform independent languages.
Totally wrong, as it is much more complex to read and understand as a simple
Some algorithms can be expressed naturally (and sometimes can only
be), when written recursively.
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
or e-mail: <mailto:xsl-list-unsubscribe(_at_)lists(_dot_)mulberrytech(_dot_)com>