定義された要素の配列をクリアする。 - ページ 16

新しいコメント
 
Taras Slobodyanik:

フラッグとの相性もいいと思います。
http://osinavi.ru/asm/4.php

不要な演算子や比較のために...

プロファイリングで確認しました。比較、代入、マッチ演算のマッチング数
 
Nikolai Semko:

2つのループのロジックやチェックの回数、和がほぼ100％同じなのに、実行時間が違うというのは、私の誤解に 帰結するのです。


上に書いたように、私のコードでは比較演算が少なくなってしまいました...。

-----

アウトオブスクールの、90年代のどこかから。

1) （条件）A,B,Cが独立なら、確率が高くなればAND関数に、低くなればOR関数に突っ込まなければならない。

また、それらが依存関係にある場合は、1つの式にまとめてはいけません（例：do if (A && B) ）。

2) ループA,Bが入れ子になっている場合、外側のループの方が短いこと

3) ループの中に条件がある場合、可能であればループを分割して条件を外に持っていくことです。


 
Maxim Kuznetsov:

上に書いたように、私のコードでは比較演算が少ないので...。

-----

90年代のどこかで、校外学習から。

1) (条件)A,B,Cが独立している場合、確率の高い順にAND関数に、確率の低い順にOR関数に配置されるべきである。

と依存する場合、それらを1つの式にまとめることはできません（例：do if (A && B) ）。

2) ループA,Bが入れ子になっている場合、外側のループの方が短いこと

3) ループの中に条件がある場合、可能であればループを分割して条件を外に持っていくこと。


1) その逆で、まさにあなたが行ったことです。複合 AND演算 子の最初の条件が実行されない場合、なぜ他のすべての条件をチェックする必要があるのでしょうか？そこで、まず、偽である可能性が高い条件を確認します。

複合条件における真実の記述の確率が高い順に並べることです。

 
Алексей Тарабанов:

1) あなたが行った逆。C言語における条件演算子の実行の特異性。

書き方が悪かったかもしれませんが、一度にみんなに説明しやすいように...。

A && B && C

ANDは、他のすべての条件を試さないように、できるだけ早くFEEDする必要があります。プログラマは、プログラムがどのようなデータで実行されるかを知らないので、オプティマイザが代わりにやってくれるわけではない(*)。

A｜B｜C

というのは、ブール演算だからです :-)。!( ((!a)&&(!b)&(!c)))(括弧内を間違えないように、もう一度サインしてください）

(*) 最適化コンパイラは、条件がちょうどよく設定されていることを当てにして、その前提で内部のキッチンを構築することができる

 
Maxim Kuznetsov:

書き方が悪かったのかもしれませんが、一目でわかるようにしたほうが、みんなにわかりやすいと思うので...。

A && B && C

ANDは、他のすべての条件を通過しないように、できるだけ早くFEEDする必要があります。つまり、最初に置かれる述語は、それ以降の連鎖全体の実行に失敗するものです。 プログラムがどのデータで実行されるか分からないので、オプティマイザはプログラマのためにそれを行いません (*)。

A｜B｜C

ブール演算なので逆です :-)!( ((!a)&&(!b)&(!c)))(括弧内は符号の混同を避けるため)

(*) 最適化コンパイラは、条件がちょうどよく設定されていることを当てにして、その前提で内部のキッチンを構築することができる

全く同感です。

 
Nikolai Semko:

2つのループのロジックやチェックの回数、和がほぼ100％同じなのに、実行時間が違うというのは、私の誤解に 帰結するのです。

では、なぜクズネツォフのコードからこのような変種が生まれたのか、改めて考えてみましょう。

は、まったく同じことをする同じものよりも2倍以上速く動作します。

コンパイラのすばらしさとは？
そんなデザインが本当に可能なのだろうか。

は、コンパイラがプロセッサのために何か特別なアセンブラの検索コマンドを見つけたのでしょうか？しかし、内部にはi<jのチェックが追加されていますね。

なぜなら、forを通して同じことをすると、実行速度が格段に落ちるからです。

デモ用スクリプトのコードを添付します。

このようなことがよくあります。不要なゴミに追われているうちに、ちょっと面白いことに気がついた。

開発者の皆さん、実行コードを見て、何がこの違いを生んでいるのか、見ていただけませんか？

今後、より最適なアルゴリズムを作るために、コンパイラの論理を理解する必要があります。

一般に不思議な状況です。 コンパイラやテストするマシンに依存するものが多いと思います。 以下は、32ビットマシンでのあなたの例の結果です。

1


ご覧のように特にメリットはありません。そして、前回のバリアントから配列削除関数のテストです。

2

 
テスト結果が以前の結果と大きく異なることがあり、これが何によるものかは不明ですが、おそらくMQLコード処理における割り込みの特定のシステムなのでしょう
 
Stanislav Dray:
テスト中に 結果が以前と全く 異なることがありますが、その理由は不明です。おそらく、MQLコード処理における特定の割り込みシステムに関係があるのでしょう。

アルゴリズムをテストするときは、次のことを行う必要があります。

* または、あらかじめ用意されたデータセット（実際に必要とされるものとほぼ同じもの）。

* またはRNGに非常に 重要な数のパスを作る。

をテストしています。

* テスト順序を交互/シャッフルし

* ポーズを観察し、あらゆる種類のキャッシュをリセットします。



 
Maxim Kuznetsov:

アルゴリズムをテストするときは、次のことを行う必要があります。

* または、あらかじめ用意されたデータセット（実際に必要とされるものとほぼ同じもの）。

* またはRNGに非常に 重要な数のパスを作る。

をテストしています。

* テストシーケンスを交互/シャッフルし

* ポーズを観察し、あらゆる種類のキャッシュをダンプします。



を、あらかじめ用意されたデータを使うように。すべての機能において、テストには同じデータが使用されます。シャッフル／キューイングについては、そうですね、テストの順番を変えると違いが出てきますね。しかし、キャッシュをリセットする方法は？

 
Maxim Kuznetsov:

アルゴリズムをテストするときは、次のことを行う必要があります。

* または、あらかじめ用意されたデータセット（実際に必要とされるものとほぼ同じもの）。

* またはRNGに非常に 重要な数のパスを作る。

をテストしています。

* テストシーケンスの交互／シャッフル

* ポーズを観察し、あらゆる種類のキャッシュをダンプします。



人を馬鹿にしない

1...91011121314151617181920212223...30
新しいコメント