带有Integral类型类的Haskell斐波纳契列表

Question

If I load the following list in GHCi the list is computed slowly, until the program eventually closes just after computing 3524578, the 33rd item in the list.

fibonacci :: (Integral a) => [a]
fibonacci = 0 : 1 : zipWith (+) fibonacci (tail fibonacci)

If I remove the first line and load the following instead the list is computed very quickly and GHCi doesn't close.

fibonacci = 0 : 1 : zipWith (+) fibonacci (tail fibonacci)

Why is the polymorphic list so much slower than the Integer list? Why does GHCi close?

Answer 1

With your first version, while it looks like a value, you actually write a function (a function on a lower level than Haskell itself).

To understand this, think about the following code that would be possible with your definition:

main = println (fibonacci !! 17 :: Int, fibonacci !! 19 :: Integer)

Of course, the 17 and 19 are completly arbitrary. The point is that the first tuple element requires to compute fibonacci as a list of Int , while the second assumes it is a list of Integers . As you probably know, there is no such list in Haskell that is halfway Int and Integer - a list is either [Int] or [Integer] (or something completely different).

Because this is so, we can conclude on pure logical grounds, without having deep knowledge of Haskell's run time system, that fibonacci is neither a list of Int nor a list of Integer nor a list of something else - it is just a recipe to build such a list on request.

That being said, as long as you do something like:

take 10 fibonacci

it should not matter that much (fibonacci is just computed once up to 10 elements).

But when you say

map (fibonacci !!) [1..10]

chances are that fibonacci is recomputed for every index. Clearly, the higher the indexes go, the longer this will take.

Answer 2

This seemed suspicious, so I did a little bit of investigation. First I made two modules:

-- fib0.hs
fibonacci :: (Integral a) => [a]
fibonacci = 0 : 1 : zipWith (+) fibonacci (tail fibonacci)
main = print $ take 10000 $ fibonacci

-- fib1.hs
main = print $ take 10000 $ fibonacci
fibonacci = 0 : 1 : zipWith (+) fibonacci (tail fibonacci)

Then compiled as follows: ghc -O2 -prof -auto-all fib0.hs & ghc -O2 -prof -auto-all fib1.hs (Note: & is for Windows, *nix uses ; to seperate multiple commands on a line). And ran them with fib0 +RTS -p & fib1 +RTS -p . This will run both fibs and the flags +RTS -p produce a file name fib0/1.prof, which contains runtime information about your program. Doing this, I saw that they both took the exact same amount of time! (0.70s to be precise - it may take longer on your machine, if you can't stand waiting that long, then decrease the 10000 elements).

You'll notice I compiled with -O2 . This sets optimization to 'level' 2. There are three levels - 0,1, and 2. GHCi by default uses O0 . So then I tried ghc -O0 -prof -auto-all fib0.hs & ghc -O0 -prof -auto-all fib1.hs (ghc would default to -O1 , so you must manually set level 0). Wouldn't you know it, when I ran them, fib0 crashes with out of memory exception and fib0 completes just fine (albiet very slowly. I had to decrease take 10000 to take 100 - but this is obviously to be expected).

This would be a normal behaviour. Optimization removes bad programming mistakes - like manually enforcing polymorphism when it is beneficial to use a single type - don't do this unless you must!

If you would like to know more, you can try ghc -O0 -f-ext-core fib0.hs & ghc -O0 -f-ext-core fib1.hs . This will generate 'core' files for both programs. Core is the last stage of GHC compilation before you start making object files. It generates plain-text .hcr files. These may be very hard to read, so let me highlight some key points for you.

fib0.hcr contains the following:

...
base:GHCziNum.fromInteger @ ac zddNumazzzz
...

Basically, you call fromInteger on every single number, starting with 0 and 1, in your sequence. Why do this? You have told it, "the type of fibonacci must be any numeric type". It creates 0 and 1 as Integer s and then uses fromInteger to create values of type Num a => a (This is the only way to create polymorphic literals) . All of these calls to fromInteger build up very expensive thunks - so you get out of memory exception.

Take a look at fib1.hcr. Nowhere does it contain fromInteger . Leaving GHC to infer the type of fibonacci lets it just use Integer , which means no thunks.

Why does optimizing remove this problem? GHC notices that you only use fibonacci to print the numbers. You don't need this polymorphism. So it optimizes it away! Note that it also does other things that make fibonacci much, much faster, like inlining.