24

INLINABLEここにリンクされているに関する以前の質問に対して Simon Marlow が行った回答を改善することを期待して、この質問をしています。

関数に INLINABLE プラグマを使用しない理由はありますか?

これは、多くのライブラリ作成者にとって最も重要な重要な質問に Simon Marlow が答えていないことを除いて、その質問のほぼ重複であることを認識していますINLINABLE。

私が知る限り、唯一の欠点は次のとおりです。

  • コンパイル時間が遅い

  • より大きなインターフェイス ファイル (つまり*.hi)

しかし、私が本当に知りたいのは、INLINABLEプラグマを追加した結果、コードの実行速度が低下するかどうかです。言い換えれば、INLINABLEプラグマによって GHC が最適化されていない最適化を選択する可能性はありますか?

私が尋ねる理由は、私を含め、多くのライブラリ作成者がインターフェイス ファイルのサイズを気にせず、INLINABLEプラグマを追加するときにコンパイルの大幅な速度低下が見られないためです。そうするのに費用はかからないようです。

逆に、それらを除外することのコストは、モジュールが非常に大きくなるghcと、スペースを節約するためにインターフェイス ファイルからいくつかの関数を選択的に省略し始めることです。どの機能を省略しますか。

個人的には、アノテーションの結果として関数の実行が遅くなるのを目撃したことはありませんINLINABLEが、それは完全に運のせいかもしれません。速度が低下する場合がある場合はINLINABLE、コンパイラ プラグマのすべての順列を退屈にベンチマークするのではなく、いつプラグマを追加するかについてより適切に推論できるように、その理由を知りたいと思います。

4

1 に答える 1

12

これが純粋に機能的な観点に該当するかどうかは不明であり、あなたの質問に対する完全な答えではないことは確かですが、それは少しです.

システム管理の観点または観点から見ると、すべてを INLINEABLE にするということは、関数への小さな変更のたびにインターフェイスが変更され、新しいパッケージ ID を取得し、このモジュールに応じてすべてを再コンパイルする必要があることを意味します。

これは、たとえば、ディストリビューションで問題を引き起こしています。Debian 安定版のパッケージにセキュリティ修正をバックポートしようとしています。修正によって ABI が変更されない場合は、単純に 1 つのパッケージを更新できます (そして、静的にビルドされたすべてのプログラムを再ビルドします)。ABI が変更された場合、数十個以上のパッケージを再構築する必要があるかもしれません。このような問題は、問題を処理しなければならないが、特に Haskell を気にかけない人にとって、Haskell は悪く見えます。

于 2013-03-15T23:00:37.647 に答える