1

残念ながら、この例全体には多くのコードが含まれています。ここで完全なモジュールを確認できます(まだコンパイルされません)。以下の疑似コード関数 f は、hpaste の 'FIXME' タグに対応しています。

擬似コードの概要は次のとおりです。

module Test (run) where
    import Data.Vector.Unboxed as U

    run m i iters = let {get q} in do print $ testWrapper iters m q

    testWrapper :: forall i . Int -> Int -> i -> U.Vector i
    testWrapper iters m q =
        let {get test params: xs, dim, ru}
        in U.map fromIntegral (iterate (f dim ru) xs !! iters)

    {-# INLINE f #-}
    f :: (Int, Int) -> Vector r -> Vector r -> Vector r
    f dim ru = (g dim ru) . zipWith (*) ru

    {-# INLINE g #-}
    g :: (Int, Int) -> Vector r -> Vector r -> Vector r
    g dim ru = ...

特定のパラメーターの場合、このコードは約 0.5 秒で実行されます。

f を f' に変更することもテストしました。

f' dim ru = (g dim ru)

(最終的な zipWith を単純に削除して、必要な全体的な作業を減らしました)。

同じ入力パラメーターで、変更されたコードには 4.5 秒かかります。

これは、optimizaiton (GHC 7.4.2、ghc -O2 を使用し、さらに最適化を行ったもの) を使用してコンパイルした場合に発生します。高速版のコアは約 3000 行、低速版のコアは約 1900 行です。

これは大したことではないかもしれませんが、どのような種類の GHC の狂気が、私のプログラムが実行する作業を削減することによって、プログラムの速度を桁違いに遅くしている可能性がありますか? 最小のテスト ケースで 2000 行以上のコアが生成される場合、どうすればこのような問題を発見できるでしょうか?

ありがとう

4

1 に答える 1

3

ヒープ プロファイルを確認します。「より少ない作業」バージョンでは、いくつかのサンクが評価されないままになっている可能性がありますか? これにより、メモリ フットプリントが大きくなり、ガベージ コレクションによる速度に影響を与える可能性があります。

于 2013-02-10T20:46:31.737 に答える