Paul Johnson wrote:
The solution is for the programmer to rewrite "mean" to accumulate a
pair containing the running total and count together, then do the
division. This makes me wonder: could there be a compiler optimisation
rule for this, collapsing two iterations over a list into one.
Do not forget:
http://www.haskell.org/tmrwiki/WhyAttributeGrammarsMatter
Though not a compiler optimisation, it's a thinker optimisation.
I have another thought. It is now time to investigate the viability of
mean x = s `par` l `par` (s/l) where
s = sum x
l = length x
If you worry that the sum thread and the length thread are not
synchronized and therefore there is still no bound on the list prefix
kept in memory, I'm sure you can improve it by one of the chunking
strategies.
As our hardware grows more cores but not more gigahertz, it may become
detrimal to fuse. Fusion implies entangling, an anti-thesis to
parallelism. One day we may call this an optimisation: unfuse code
hand-fused by programmers, then parallelize. Optimisation people on the
imperative side are already doing this (they have more hand-fused code
than we do), though targetting at older hardware like vector machines
and SIMD, not yet multiple cores.
_______________________________________________
Haskell-Cafe mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/haskell-cafe
