Really? Can you expand on that? I have seen Fibonacci being the poster child of the usefulness of memoization and maybe tail recursion, but never parallelization.
That baffles me. I think I've hardly read a paper on parallel functional programming that doesn't start with fib.
Here's example that agrees that it's the hello-world of parallelisation.
https://wiki.haskell.org/Haskell_for_multicores
It's trivial for a compiler to automatically parallelise it - for every binary operator evaluate the two operands in parallel - done.
Computing fib with memoisation from 1 will certainly be faster than (parallel) recursion without memoisation and data sharing.
An iterative fibonacci solution runs in linear time. Calculating the N'th fibonacci number requires O(N) serial operations.
A fully parallel, recursive solution without memoization requires that each value in the sequence is computed more than once. Consider the example of fib(4):
fib(4) = fib(3) + fib(2)
fib(3) = fib(2) + fib(1)
fib(2) = fib(1) + fib(0)
A quick google suggests that the time complexity of the recursive approach is O(2^N).
Absolutely nobody is under the impression that the naive parallel implementation of fib is actually useful code or the most efficient way to do it. You're missing the point if you're suggesting a different way to do it in the first place.
It's just something to use as a running example... like on the original article this whole thread is about.
I think maybe if there hadn't been such a vibe of "what, you don't know X?!?" then it would have just been an interesting fact to mention that parallelization demos often use fib, because it's an easy example to grok (though a confusing one if you already understand the faster method).