>> I'm saying that, from a pedagogical perspective, the first version is a bad example to begin with, and that it's better to show the separated version from the start >> (this also leads into the development/use of parList rseq [or probably rdeepseq]). My experience is that people copy examples... > > Ah, ok, fair enough. There's always a risk, I agree. I think the > presentation as given was inspired by the fact that the previous > digest covered par/pseq in isolation, and we wanted to move from there > to more advanced concepts step by step.
I'm saying that the separate strategy is the next step :)
>> We have been hitting some performance debugging issues - I'm pinging Simon independently about these - we really want this to be as easy to use >> as possible. > > So do we :) We'd probably be interested hearing about your performance > debugging issues, too, as we're still busy improving ThreadScope ...
I'll pass this on once I've worked out the technical details - in some cases we've rewritten code so that it works, but we only have an intuition why. One thing that would be immediately useful would be a spark profile (as I know is coming in the next release). The ThreadScope profiles can also hide detail (e.g. appear to show parallelism when this is actually subsumed by GC).
Best Wishes, Kevin
Kevin Hammond, Professor of Computer Science, University of St Andrews
In accordance with University policy on electronic mail, this email reflects the opinions of the individual concerned, may contain confidential or copyright information that should not be copied or distributed without permission, may be of a private or personal nature unless explicitly indicated otherwise, and should not under any circumstances be taken as an official statement of University policy or procedure (see http://www.st-and.ac.uk).
The University of St Andrews is a charity registered in Scotland : No SC013532