問題タブ [ctfe]

DのMixinを使用して、線形代数演算をCPUコードとOpenCLまたはGLSLなどのGPU頂点シェーダー関数のいずれか/両方にマッピングできますか？これは、Dの真のキラーアプリケーションであり、CPUとGPUの両方の実行を対象としたより優れたブリッジロジックになります。これを、固定サイズの線形代数のみをCPUコードにコンパイルするglmおよびDのgl3nと比較してください。

VexCLは、OpenCLとC ++ 11（GCC 4.6以降）を使用したこの概念実証であり、メモリ割り当てとコード実行に関するバックエンド依存（CPU / GPU）実装の詳細を、C++AMPにいくらか類似して完全に抽象化します。それで、物事はDでのみ良くなることができますか？ミックスインは、VexCLで使用されるC ++式テンプレートの使用を完全に置き換えることができますか？これは、その使用法に関する優れたチュートリアルです。

CTFEは、この議論でもここで役割を果たす可能性があります。

コンパイル時にファイル名と画像形式を結合したい。次の例はstring[]、コンパイル時に評価できないため、機能しません...

次のエラー メッセージで失敗します。

これを最終的に にフィードする必要がありますimport()。エラーはどのように解決できますか?

単純な utf8 strlen 関数をテストしたところ、trunk clang がそれを完全に排除したことに非常に驚きました (gcc はそうではありません):

clang++ -O3 -S -fverbose-asm:

これは、D のコンパイル時の関数評価に似ています。これは C++ でも合法ですか?

つまり、そもそも彼らがそのくだらないconstexprを発明したのには理由があるに違いありません。厳しく制限されているため、私の知る限り、ここでは使用できませんでした。

コンパイル時に D で正規表現を評価する方法はありますか?

このコードは、getA!B() 呼び出しの 2 番目の単体テストで失敗します。エラーは次のとおりです。「タイプ「文字列」の「値」には「これ」が必要です」

質問は。UDA が型であるか opCall であるかにかかわらず、getA が常に A を返すようにするにはどうすればよいですか?

初めての D プロジェクトについてアドバイスが必要です。私はそれをアップロードしました:-

https://bitbucket.org/mrjohns/matcher/downloads

IDEA : 3 つのランタイム アルゴリズムのベンチマークと、それらのコンパイル時のバリアントとの比較。これらの唯一の違いは、コンパイル時にルックアップ テーブル (つまり、配列 bmBc、bmGs、およびサフィックス) をコンパイル時に計算する必要があることです (私は現在 CTFE に依存しています)。一方、実行時のものの場合、ルックアップ テーブルは実行時に計算されます。

NB : パターン マッチング アルゴリズム自体はコンパイル時に実行する必要はなく、ルックアップ テーブルのみを実行する必要があります。これを述べた上で、既知の (コンパイル時に計算された) テーブルで実行されるアルゴリズムは、実行時に計算する必要があるものよりも高速でなければなりません。 .

私の結果は何か違うことを示しているようです。最初のペア (BM_Runtime と BM_Compile-time) のみが許容可能な結果を​​もたらし、他の 2 つのペアはコンパイル時のバリアントの実行時間を長くします。ここに何かが欠けていると思います。助けてください。

pattern="GCAGAGAG" の現在の結果は以下のとおりです:-

コードの実行: dmd -J. matcher.d input.d rtime_pre.d ctime_pre.d && numactl --physcpubind=0 ./matcher

ご提案いただければ幸いです。

よろしくお願いします。