既存のアプリケーションを C# に移植しており、可能な限りパフォーマンスを改善したいと考えています。多くの既存のループ カウンターと配列参照は、私が使用していた Int32 ではなく、System.UInt32 として定義されています。
UInt32 と Int32 を使用すると、パフォーマンスに大きな違いはありますか?
既存のアプリケーションを C# に移植しており、可能な限りパフォーマンスを改善したいと考えています。多くの既存のループ カウンターと配列参照は、私が使用していた Int32 ではなく、System.UInt32 として定義されています。
UInt32 と Int32 を使用すると、パフォーマンスに大きな違いはありますか?
プロセッサレベルでの符号付き演算と符号なし演算の違い以外に、パフォーマンスに関する考慮事項はないと思いますが、その時点では違いは意味がないと思います。
すべての言語がサポートしているわけではないため、署名されていない型は CLS に準拠していないため、より大きな違いは CLS 準拠にあります。
私は.NETの問題について調査を行っていませんが、Win32/C++の昔は、「signed int」を「signed long」にキャストしたい場合、CPUはopを実行して拡張する必要がありました記号。「unsigned int」を「unsigned long」にキャストするには、上位バイトにゼロを入れるだけです。節約は数クロック サイクルのオーダーでした (つまり、知覚可能な違いを得るには、何十億回も実行する必要があります)。
パフォーマンスに関しては、違いはありません。単純な整数計算はよく知られており、最新の CPU はそれらをすばやく実行できるように高度に最適化されています。
これらのタイプの最適化は、努力する価値があることはめったにありません。タスクに最も適したデータ型を使用し、そのままにしておきます。これがデータベースに影響を与えるほどであれば、C# でのコードの最適化を数百桁相殺する、DB 設計、クエリ構文、またはインデックス作成戦略に多数の微調整が見られる可能性があります。
どちらの方法でも同じ量のメモリを割り当てることになります (ただし、符号のスペースを節約しないため、より大きな値を格納できます)。したがって、いずれかのオプションが爆発するような大きな値/負の値を使用しない限り、「パフォーマンス」の違いが見られるとは思えません。
これは実際にはパフォーマンスとは関係なく、ループ カウンターの要件です。
おそらく、完了するまでに多くの反復があった
Console.WriteLine(Int32.MaxValue); // Max interation 2147483647
Console.WriteLine(UInt32.MaxValue); // Max interation 4294967295
何らかの理由で unsigned int が存在する可能性があります。