計算科学でC ++式テンプレートを使用する必要があるのはいつですか。また、使用しない*場合はありますか？

私がC ++で科学的なコードに取り組んでいるとします。同僚との最近の議論では、式テンプレートは本当に悪いことであり、gccの特定のバージョンでのみソフトウェアをコンパイルできる可能性があると主張されました。おそらく、この問題は、このDownfallのパロディの字幕で言及されているように、いくつかの科学的コードに影響を与えています。（これらは私が知っている唯一の例なので、リンクです。）

ただし、SIAM Journal of Scientific Computingのこのペーパーのように、一時変数への中間結果の保存を回避することにより、パフォーマンスの向上をもたらすことができるため、式テンプレートが有用であると主張する人もいます。

C ++でのテンプレートメタプログラミングについてはあまり知りませんが、それが自動微分および区間演算で使用される1つのアプローチであることは知っています。それが式テンプレートについての議論になりました。パフォーマンスの潜在的な利点とメンテナンスの潜在的な欠点の両方（それが正しい言葉である場合）を考えると、計算科学でC ++式テンプレートをいつ使用し、いつ避けるべきですか？

式テンプレートに関する私の問題は、それらが非常に漏れやすい抽象化であることです。非常に複雑なコードを記述して、より良い構文で簡単なタスクを実行するために多くの作業を費やしています。ただし、アルゴリズムを変更したい場合は、ダーティコードをいじる必要があり、型や構文が足りないと、完全に理解できないエラーメッセージが表示されます。アプリケーションが式テンプレートに基づいたライブラリに完全にマッピングされる場合、検討する価値があるかもしれませんが、よくわからない場合は、通常のコードを書くことをお勧めします。確かに、高レベルのコードはあまりきれいではありませんが、必要なことだけを行うことができます。利点として、コンパイル時間とバイナリサイズが大幅に減少し、コンパイラとコンパイルフラグの選択によるパフォーマンスの大きな変動に対処する必要がなくなります。

他の人は、ETプログラムを書くのがどれだけ難しいかという問題と、エラーメッセージを理解する複雑さについてコメントしています。コンパイラーの問題についてコメントさせてください。大きな問題の1つは、C ++標準に完全に準拠し、すべてを機能させ、移植性のあるコンパイラーを見つけることでした。その結果、多くのバグを発見しました。私の名前には、gcc、Intel icc、IBM xlC、およびPortlandのpgiccで配布されている2〜300個のバグレポートがあります。したがって、deal.II構成スクリプトは、主にテンプレート、フレンド宣言、名前空間などの分野での多数のコンパイラバグテストのリポジトリです。

しかし、コンパイラーのメーカーは本当に一緒に行動していることがわかりました。今日、gccとiccは今日すべてのテストに合格しており、2つの間で移植可能なコードを書くのは簡単です。PGIはそれほど遅れてはいないと思いますが、PGIにはいくつかの癖があり、長年にわたって消えないようです。一方、xlCはまったく別の話です-6か月ごとにバグを修正しますが、バグレポートを何年も提出しているにもかかわらず、進捗は非常に遅く、xlCは取り引きをコンパイルできませんでした。

これがすべてを意味するのは、2つの大きなコンパイラーを使い続ければ、今日動作することを期待できます。現在、ほとんどのコンピューターとOSには通常少なくとも1つが搭載されているため、これで十分です。より困難な唯一のプラットフォームはBlueGeneであり、通常システムコンパイラはすべてのバグを含むxlCです。

あなたが言ったように、コンパイラがまだそれらに苦しんでいたとき、私はかなり前にETのを少し実験しました。私のコードでは線形代数に電撃戦のライブラリを使用しました。問題は、優れたコンパイラーを得ることでした。私は完璧なC ++プログラマーではないため、コンパイラーのエラーメッセージを解釈していました。後者は単に管理不能でした。コンパイラは、平均で約1000行のエラーメッセージを生成します。プログラミングエラーをすばやく見つけることができませんでした。

詳細については、Ooonumericsの Webページをご覧ください（2つのETワークショップの議事録があります）。

しかし、私は彼らから遠く離れていたでしょう....

問題は、「式テンプレート（ET）」という用語ですでに始まっています。正確な定義があるかどうかはわかりません。しかし、その一般的な使用法では、「線形代数式のコーディング方法」と「計算方法」が何らかの形で組み合わされています。例えば：

ベクトル演算をコーディングします

v = 2*x + 3*y + 4*z;                    // (1)

そして、それはループによって計算されます

for (int i=0; i<n; ++i)                 // (2)
    v(i) = 2*x(i) + 3*y(i) + 4*z(i);

私の意見では、これは2つの異なるものであり、分離する必要があります。（1）インターフェイスであり、（2）1つの可能な実装です。これはプログラミングの一般的な方法です。確かに（2）は適切なデフォルトの実装かもしれませんが、一般的には、専用の専用実装を利用できるようにしたいと考えています。たとえば、次のような関数が必要です

myGreatVecSum(alpha, x, beta, y, gamma, z, result);    // (3)

コーディング中に呼び出されます（1）。多分（3）は（2）のようなループを内部的に使用するだけです。ただし、ベクターのサイズによっては、他の実装の方が効率的な場合があります。とにかく、高性能の専門家は可能な限り実装（3）することができます。（1）を（3）の呼び出しにマッピングできない場合は、（1）の構文糖を避けて、すぐに（3）を直接呼び出します。

私が説明するのは新しいことではありません。それどころか、BLAS / LPACKの背後にある考え方です。

• LAPACKのすべてのパフォーマンスクリティカルな操作は、BLAS関数を呼び出すことによって実行されます。
• BLASは、一般に必要な線形代数式のインターフェイスを定義するだけです。
• BLASには、さまざまな最適化された実装が存在します。

BLASのスコープが十分でない場合（たとえば（3）のような機能を提供しない場合）、BLASのスコープを拡張できます。したがって、60年代と70年代のこの恐竜は、石器時代のツールを使用して、インターフェイスと実装を明確かつ直交的に分離しています。（ほとんどの）数値C ++ライブラリがこのレベルのソフトウェア品質を達成しないのは、ちょっとおかしいです。プログラミング言語自体は非常に洗練されていますが。したがって、BLAS / LAPACKがまだ生きており、積極的に開発されていることは驚くことではありません。

したがって、私の意見では、ETはそれ自体悪ではありません。しかし、それらが数値C ++ライブラリで一般的に使用される方法は、科学コンピューティング界で非常に悪い評判を得ました。