Стиль против производительности с использованием векторов

Вот код:

{-# LANGUAGE FlexibleContexts #-}

import Data.Int
import qualified Data.Vector.Unboxed as U
import qualified Data.Vector.Generic as V

{-# NOINLINE f #-} -- Note the 'NO'
--f :: (Num r, V.Vector v r) => v r -> v r -> v r
--f :: (V.Vector v Int64) => v Int64 -> v Int64 -> v Int64
--f :: (U.Unbox r, Num r) => U.Vector r -> U.Vector r -> U.Vector r
f :: U.Vector Int64 -> U.Vector Int64 -> U.Vector Int64
f = V.zipWith (+) -- or U.zipWith, it doesn't make a difference

main = do
    let iters = 100
        dim = 221184
        y = U.replicate dim 0 :: U.Vector Int64
    let ans = iterate ((f y)) y !! iters
    putStr $ (show $ U.sum ans)

Я скомпилировал с ghc 7.6.2 и -O2, и это заняло 1,7 секунды.

Я попробовал несколько различных версий f:

1. f x = U.zipWith (+) x
2. f x = (U.zipWith (+) x) . id
3. f x y = U.zipWith (+) x y

Версия 1 совпадает с оригиналом, в то время как версии 2 и 3 запускаются менее чем за 0,09 секунды (и INLINING f ничего не меняет).

Я также заметил, что если я сделаю f полиморфным (с любой из трех сигнатур выше), то даже при" быстром " определении (например, 2 или 3) он замедляется down...to ровно 1,7 секунды. Это заставляет меня задуматься, возможно ли, что исходная проблема связана с (отсутствием) вывода типа, хотя я явно даю типы для векторного типа и типа элемента.

Меня также интересует сложение целых чисел по модулю q:

newtype Zq q i = Zq {unZq :: i}

Как и при добавлении Int64s, Если я пишу функцию с каждым указанным типом,

h :: U.Vector (Zq Q17 Int64) -> U.Vector (Zq Q17 Int64) -> U.Vector (Zq Q17 Int64)

Я получаю на порядок лучшую производительность, чем если бы я оставьте любой полиморфизм

h :: (Modulus q) => U.Vector (Zq q Int64) -> U.Vector (Zq q Int64) -> U.Vector (Zq q Int64)

Но я должен по крайней мере быть в состоянии удалить определенный фантомный тип! Он должен быть скомпилирован, так как я имею дело с newtype.

Вот мои вопросы:

1. откуда берется замедление?
2. Что происходит в версиях 2 и 3 f, которые каким-либо образом влияют на производительность? Мне кажется ошибкой, что (что равносильно) стиль кодирования может повлиять на производительность, как это. Есть ли другие примеры за пределами Вектор, где частичное применение функции или другие стилистические варианты влияют на производительность?
Почему полиморфизм замедляет меня на порядок независимо от того, где полиморфизм (то есть в векторном типе, в типе Num, обоих или фантомном типе)? Я знаю, что полиморфизм делает код медленнее, но это смешно. Есть ли вокруг него Хак?

Правка 1

Я подал выпуск на страницу векторной библиотеки. Я нашел ... GHC вопрос , относящийся к этой проблеме.

EDIT2

Я переписал вопрос, получив некоторое представление из ответа @kqr. Ниже приведен оригинал для справки.

--------------ОРИГИНАЛЬНЫЙ ВОПРОС--------------------

Вот код:

{-# LANGUAGE FlexibleContexts #-}

import Control.DeepSeq
import Data.Int
import qualified Data.Vector.Unboxed as U
import qualified Data.Vector.Generic as V

{-# NOINLINE f #-} -- Note the 'NO'
--f :: (Num r, V.Vector v r) => v r -> v r -> v r
--f :: (V.Vector v Int64) => v Int64 -> v Int64 -> v Int64
--f :: (U.Unbox r, Num r) => U.Vector r -> U.Vector r -> U.Vector r
f :: U.Vector Int64 -> U.Vector Int64 -> U.Vector Int64
f = V.zipWith (+)

main = do
    let iters = 100
        dim = 221184
        y = U.replicate dim 0 :: U.Vector Int64
    let ans = iterate ((f y)) y !! iters
    putStr $ (show $ U.sum ans)

Я скомпилировал с ghc 7.6.2 и -O2, и это заняло 1,7 секунды.

Я попробовал несколько различных версий f:

1. f x = U.zipWith (+) x
2. f x = (U.zipWith (+) x) . U.force
3. f x = (U.zipWith (+) x) . Control.DeepSeq.force)
4. f x = (U.zipWith (+) x) . (z -> z `seq` z)
5. f x = (U.zipWith (+) x) . id
6. f x y = U.zipWith (+) x y

Версия 1 совпадает с оригиналом, версия 2 выполняется за 0,111 секунды, а версии 3-6 выполняются менее чем за 0,09 секунды (и INLINING f ничего не меняет).

Таким образом, замедление порядка величины, по-видимому, связано с ленью, так как force помогло, но я не уверен, откуда эта лень берется. Распакованные типы не допускаются к использованию. ленивый, да?

Я попытался написать строгую версию iterate, думая, что сам вектор должен быть ленивым:

{-# INLINE iterate' #-}
iterate' :: (NFData a) => (a -> a) -> a -> [a]
iterate' f x =  x `seq` x : iterate' f (f x)

, но с точкой-бесплатная версия f, это не поможет.

Я также заметил кое-что еще, что могло быть просто совпадением и отвлекающим маневром.: Если я делаю f полиморфным (с любой из трех сигнатур выше), даже с" быстрым " определением, он замедляется down...to ровно 1,7 секунды. Это заставляет меня задуматься, не является ли первоначальная проблема, возможно, из-за к (отсутствию) вывода типа, хотя все должно быть выведено красиво.

Вот мои вопросы:

1. откуда берется замедление?
2. Почему составление с помощью force помогает, а использование строгого iterate - Нет?
Почему U.force хуже, чем DeepSeq.force? Я понятия не имею, что U.force должен делать, но это звучит очень похоже на DeepSeq.force и, кажется, имеет аналогичный эффект.
3. Почему полиморфизм замедляет меня на порядок независимо от того, где находится полиморфизм (то есть в векторном типе, в типе Num или в обоих)?
Почему версии 5 и 6, ни одна из которых не должна иметь никаких последствий строгости вообще, так же быстры, как строгая функция?

Как отметил @kqr, проблема, похоже, не в строгости. Таким образом, что-то в том, как я пишу функцию, заставляет использовать generic zipWith, а не распакованную версию. Это просто случайность между GHC и Векторная библиотека, или здесь можно сказать что-то более общее?