エニュメレーションを一貫して行うにはどうしたらいいですか？ - ページ 3

新しいコメント
 
Alexey Navoykov:

ここで示した例（ケース1：戻り値1、ケース2：戻り値2、ケース3：戻り値3・・・。その逆で、バイナリサーチを使う。

私は、配列を使った素敵なコードに両手を挙げて賛成しています。しかし、通常のNormalizeDouble よりも高速なNormalizeDouble を書くと、オプティマイザーの効果に遭遇しました。テスターではNormalizeDoubleが多用されているので、2番目のバリエーションを残しました。インジケーターに入れ、このモンスターを見ないようにしています。しかし、バックテストの実行速度は速い。
 
fxsaber:
私は、配列を使った素敵なコードに両手を挙げて賛成です。しかし、通常の NormalizeDouble よりも高速な NormalizeDouble を書くと、オプティマイザ効果に遭遇することがあります。つまり、const-array による素晴らしい解決策は switch-case による面倒なものよりもずっと遅いのです。テスターではNormalizeDoubleが多用されているので、2番目のバリエーションを残しました。インジケーターに入れ、このモンスターを見ないようにしています。しかし、バックテストの実行速度は速い。

以前、switchについて議論するスレッドがあったのですが、そこでは開発者がバイナリサーチとしての 実装についてしか話しておらず、当然ながら計算されたインデックスによる単純なアクセスよりもずっと遅いという話になっていたのを覚えています。もちろん、ネイティブ実装はラッパー実装より常に高速です。

もちろん、これはあなたの優先順位によります。でも、もし松葉杖を発明するほどスピードが重要なら、OOPやMQLもあきらめるべきでしょう（笑）。 でも、適切なコーディングをすれば、スピードの差はそれほど大きくならないでしょう。 テスト測定では、関数をループで数百万回まわすだけなのですから。そして、実際のコードではもっと合理的に使うんですね。

 
Alexey Navoykov:

以前、switchについて議論するスレッドがあったのですが、そこでは開発者がバイナリサーチとしての実装についてだけ話していて、当然ながら計算されたインデックスによる単純なアクセスよりもずっと遅いという話になっていたのを覚えています。もちろん、ネイティブ実装はラッパー実装より常に高速です。

コンパイラは、馬鹿でなければ、const-arrayとそのインデックスによる唯一の型参照をスイッチコードにしなければならないだろう。

もちろん、優先順位によって必要な場合もあるでしょう。しかし、もし松葉杖を発明するほどスピードが重要なら、OOPとMQLをあきらめるべきです。 正しいコーディングをすれば、スピードの差はそれほど大きくならないとは思いますが。 テスト測定では、単に関数を何百万回もループさせて競争させているに過ぎないのです。そして実際のコードでは、より合理的に使うのですね。

スピードは重要ではありませんが、不合理な書き方をしていると、違和感を覚えます。OOPを 全く使わないというのは、もちろん合理的ではありません。とにかく、あなたが並べたコドベースのささやかな努力を見て、何日も数えていない。そこで、同じNormalizeDoubleという形の松葉杖が登場したことが理解できると思います。それは、時に非合理的な開発者の実装によるランダムな事実の結果なのです。
 
fxsaber:
 コンパイラは、馬鹿でなければ、const-arrayとインデックスによる唯一の型参照をswitchコードにしたはずです。

つまり、配列は単なるconstなんですね。静止画についてはどうでしょうか？インデックス値と配列/列挙体のサイズを 比較し、小さければ必要な要素のアドレスを配列のアドレス＋インデックスとして取得し、そこから値を読み取るという単純な操作です。このような無意味なことは、平等にコンパイルしなければならないと思いました。

とにかく、並べたまま何日も数えていないkodobaseの地味な努力に注目です。そこで、同じNormalizeDoubleという形の松葉杖が登場したことが理解できると思います。それは、開発者の非合理的な実装による偶然の事実の結果です。
ちなみに、この比較は何年前に行ったのですか？もしかして、当時はまだコンパイラが「馬鹿」だったのでは？
 
Alexey Navoykov:

つまり、配列は単なるconstなんですね。静止画についてはどうでしょうか？インデックス値と配列/列挙体のサイズを比較し、小さければ必要な要素のアドレスを配列のアドレス＋インデックスとして取得し、そこから値を読み取るという単純な操作です。こんなくだらないものは、きっと同じようにコンパイルするのだろうと思っていました。

constメソッドで静的配列を作成できるかどうかは、はっきりとは覚えていませんが、確かにそうかもしれません。原則的に私は静止画ではなく、定型文を作っていたのです。コンパイラの知能をあてにする。コンパイル後は、ガッツリ配列のヒントが全くない状態だったはずです。statikはconstよりもずっと複雑な構造です。 だから、コンパイラはstaticに対応できないと確信していました。でも、やってみないとわからない。

ところで、この比較は何年前に行われたのでしょうか？もしかして、当時はまだコンパイラが「馬鹿」だったのでは？
モデレーターの一人がいくつかのボタンを押し、kodobaseにコードを公開するゴーサインを出せば、その努力はすぐに目に見えるものとなるのです。性能のことは考えずに自分にとって都合の良い解決策を作り、ビルド1383 32bitでほぼ一桁のゲインを得ました。
 
fxsaber:

静的配列がconstにできるかどうかはよく覚えていませんが、methodはできません。原理的に、スタティックではなくコンストラストを作っていたのです。コンパイラの知能をあてにする。コンパイル後は、ガッツリ配列のヒントが全くない状態だったはずです。statikはconstよりもずっと複雑な構造です。 だから、コンパイラはstaticに対応できないと確信していました。でも、試してみないとわからない。

なるほど、そういうことだったのか。コンパイラが、設計の悪い解をさらに最適化してくれるという、コンパイラの過剰な知性に頼るべきではありません。 もしあなた自身が、「静力学はもっと複雑だ」（何が複雑なのか私にはわかりませんが）と言って、適切に行うことを怠るなら、なぜコンパイラを非難するのでしょう？

 
Alexey Navoykov:

なるほど、そういうことだったのか。コンパイラの過剰な知性に頼ってはいけません。 もし、あなた自身が「静的な方がずっと複雑だ」と言って、適切に実行できないのなら（何が複雑なのか私には分かりませんが）、なぜコンパイラを非難するのでしょうか？

配列にstaticを追加しました。スイッチの3倍近い速さで効果がありましたそのスイッチは捨てて ください。ご指摘ありがとうございます。
 
fxsaber:
配列にstaticを追加しました。スイッチの3倍近い速さで効果が出ましたこのスイッチをゴミ箱に ご指摘ありがとうございます。

どういたしまして、松葉杖を発明して走り回る前に、7回は考えなければならないという、今後の教訓になりました（笑)。

今になってわかったことだが、私はこのスイッチを褒めすぎたというか、開発者が早すぎたのだ。 だから、そこでは、列挙が倍数で行われる場合でも、すべてがバイナリ検索だけで 実装されている。 良くないことだ。

 
Alexey Navoykov:

どういたしまして、走る前に7回考えて松葉杖を発明するというのは、今後の教訓になりますよ（笑)。

標準のNormalizeDouble（ビルド1395）よりも約4倍高速化されました...は、開発者の松葉づえです。

 
fxsaber:
標準のNormalizeDouble（ビルド1395）よりも約4倍高速化されました...は、開発者の松葉づえです。

人は皆、罪がないわけではない）
12345678
新しいコメント