1

私は非常に小さな数を非常に大量に使用するつもりです (各 int は 1 から 10 の間で、一度にこのような数百の変数を持つため)。 16 ビット整数と 32 ビットの使用の違い。私のユーザーのほとんどは 64 ビット プロセッサを使用しますが、32 ビットを使用するユーザーもいます。

4

3 に答える 3

4

CPU

個々の数値を扱う場合、よりコンパクトな表現を使用すると、わずかに改善される可能性があります。あれは、

ushort a;
ushort b;

// @mikez pointed a & b are  promoted to int when added
// C# spec, 7.3.6.2 Binary numeric promotions
ushort result = (ushort)(a + b);

よりもわずかに速いかもしれません

ulong a;
ulong b;

ulong result = a + b;

アルゴリズムに応じて。その理由は、個々の数値が小さいほど CPU キャッシュに収まるデータが多くなり、最終的に RAM から CPU に転送する必要のあるデータが少なくなるためです。

一方で、64 ビットのアドレス境界に揃えられていないデータの読み取り/書き込みが原因で、わずかに遅くなる場合があります。

両方の要因が互いに反対に作用します。ユースケースを測定して、CPU の観点から見て良いか悪いかを調べます。

RAM内

a のList<ushort>代わりに aを使用するList<ulong>と、メモリ コストが 75% 節約されます。 これによりスワッピングが防止されれば、アプリケーションにメリットがあります。

ディスク上

データベースに保存する場合、ワーキング セットが大きすぎてデータベース エンジンで使用できる RAM に収まらない場合は、より小さいサイズを使用するとパフォーマンスに大きな違いが生じる可能性があります。これは、より多くのレコードがディスクのより少ないセクターに収まるため、ディスク シークが減少するためです。時間 (SSD がない場合) と、単位時間あたりに IO チャネルを介して転送できるデータ ポイントの量を増やします。

警告

これはすべて、コンピューターの処理能力と比較して本当に大きな量が当てはまる場合にのみ問題になることに注意してください。すべてのデータをメモリに保持するのに十分な RAM がある場合は、スワップしません。データベース サーバーやストレージ コントローラのキャッシュがワーキング セットをメモリ内に保持できる場合、ディスク ストレージ サイズの考慮事項はほとんど問題になりません。

結論

処理する値の範囲について間違っていて、すべての値を保持するために突然大きなデータ型が必要になった場合にのみ、より小さいデータ型を使用しても問題が生じます。

主要なアルゴリズムの簡単なプロトタイプを作成します。ushort、uint、ulong のさまざまな選択肢を使用して、いくつかの測定を実行します。

「数百の変数」にそれぞれ単一の数値しか含まれていない場合 (たとえば、多数の数値を含むリストとは対照的に)、これは問題ではありません。コンピューターに負荷をかけ始めたとき (何をしているかにもよりますが、おそらく数千から数億のデータ ポイント) でのみ、これらの最適化はユーザーにとって実際に重要になります。

于 2012-07-30T21:52:59.303 に答える
3

迷ったら測る。しかし、メモリ消費の違いを除けば、何も見えないでしょう。

于 2012-07-30T21:52:25.850 に答える
2

ここでの回答は一般的には適切ですが、.NET プラットフォームには特定の考慮事項があります。CIL には 8 ビットまたは 16 ビットの算術演算はありません。

つまり、すべての 8 ビットと 16 ビットの値は、演算のために暗黙的に 32 ビットに変換されます。

ECMA 仕様 - パート 3 (CIL) - セクション 1.6 暗黙の引数強制

于 2012-07-30T22:04:14.827 に答える