1

昔から、ゼロとの比較は他のどの値よりも高速であるという記憶が残っています (エヘム Z80)。

私が書いているいくつかの C コードでは、すべてのビットが設定されている値をスキップしたいと考えています。現在、これらの値のタイプは ですがchar、変更される可能性があります。テストを実行するには、次の 2 つの方法があります。

if (!~b)
    /* skip */

if (b == 0xff)
    /* skip */

後者は b が 8 ビット char であると仮定しているのに対し、前者はそうではありませんが、古いゼロ比較最適化トリックにより前者の方が高速でしょうか?

4

4 に答える 4

9

より高速な場合は、コンパイラが代わりに使用します。

一般に、コンパイラが C を最適化できる以上に C を書くことはできません。とにかく、それはアーキテクチャ固有です。

要するに、そのサブマイクロナノ秒が非常に重要でない限り、心配する必要はありません

于 2010-05-04T15:59:25.287 に答える
7

アーキテクチャのクラスで覚えていることから、それらは同じように高速であるべきだと思います。両方とも 2 つの命令があります。

最初の例 1. 一時レジスタへの b を否定する 2. 一時レジスタを 0 と比較する

2 番目の例 1. b から 0xff を減算して一時レジスタに入れる 2. 一時レジスタを 0 と比較する

これらは基本的に同一であり、さらに、特定のアーキテクチャがこれより多かれ少なかれ必要とする場合でも、ナノ秒の何分の一の価値があるのでしょうか? この質問に答えるだけで数分が費やされました。

于 2010-05-04T16:02:30.997 に答える
3

CPUがこれらの種類のトリックを超えているのは、コンパイラであるため、それほどではないと思います。

しかし、今日の CPU は 1 クロックまたは 2 クロック刻みの速度を引き出す単純なトリックを超えています。これを 1 秒間に 100,000 回行ったとしても、シングルコア 3Ghz コンピューターで 0.00003 秒の速度の向上について話しているだけです。このようなことを心配するのは時間の無駄です。

于 2010-05-04T16:00:22.160 に答える
2

コードを保守している人が理解しやすいものを使用してください。製品が成功した場合、ソフトウェアの費用のほとんどは保守に費やされます。不可解なコードを書くと、その費用が増えます。成功した製品がなくても、誰もそれを維持する必要がないので問題ありません。私は可能な限りすべてのバイトを保存しなければならず、あなたが与えたようなトリックに頼らなければならない状況にありましたが、私はそれをまさに最後の手段としてのみ行います.

于 2010-05-04T16:12:50.627 に答える