10

int反復カウンターのように、特別なものがなく、実際には2 ^ 64までのスパンを必要としない変数に対して、64ビットプログラムで（x86とx86_64の両方で32ビット）を使用し続けるのは良い考えでしょうか。 size_tCPUのワードサイズに一致するものを使用することをお勧めします。

確かに、使用し続けるintとメモリの半分が節約され、CPUキャッシュについて何かを意味する可能性がありますが、64ビットマシンで使用する前に32ビット数ごとに64ビットに拡張する必要があるかどうかはわかりません。

編集：私は私のプログラムでいくつかのテストを実行しました（自己回答を参照してください、それは良いので、私はまだjannebを受け入れたままにします）。パフォーマンスが大幅に向上していることがわかります。

4

4 に答える 4

4

配列インデックスとポインタ演算の場合、ポインタと同じサイズの型（通常、size_tとptrdiff_t）は、レジスタをゼロまたは符号拡張する必要がないため、より適切な場合があります。検討


float onei(float *a, int n)
{
  return a[n];
}

float oneu(float *a, unsigned n)
{
  return a[n];
}

float onep(float *a, ptrdiff_t n)
{
  return a[n];
}

float ones(float *a, size_t n)
{
  return a[n];
}

x86_64上のGCC4.4-O2では、次のasmが生成されます。


    .p2align 4,,15
.globl onei
    .type   onei, @function
onei:
.LFB3:
    .cfi_startproc
    movslq  %esi,%rsi
    movss   (%rdi,%rsi,4), %xmm0
    ret
    .cfi_endproc
.LFE3:
    .size   onei, .-onei
    .p2align 4,,15
.globl oneu
    .type   oneu, @function
oneu:
.LFB4:
    .cfi_startproc
    mov %esi, %esi
    movss   (%rdi,%rsi,4), %xmm0
    ret
    .cfi_endproc
.LFE4:
    .size   oneu, .-oneu
    .p2align 4,,15
.globl onep
    .type   onep, @function
onep:
.LFB5:
    .cfi_startproc
    movss   (%rdi,%rsi,4), %xmm0
    ret
    .cfi_endproc
.LFE5:
    .size   onep, .-onep
    .p2align 4,,15
.globl ones
    .type   ones, @function
ones:
.LFB6:
    .cfi_startproc
    movss   (%rdi,%rsi,4), %xmm0
    ret
    .cfi_endproc
.LFE6:
    .size   ones, .-ones

ご覧のとおり、intおよびunsigned intインデックス（oneiおよびoneu）を持つバージョンでは、レジスタを符号/ゼロ拡張するために追加の命令（movslq / mov）が必要です。

コメントで述べたように、欠点は、64ビットレジスタのエンコードが32ビット部分よりも多くのスペースを必要とし、コードサイズを肥大化させることです。次に、ptrdiff_t / size_t変数は、同等のintよりも多くのメモリを必要とします。そのような配列がある場合、ゼロ/符号拡張を回避するという比較的小さな利点よりもはるかにパフォーマンスに影響を与える可能性があります。わからない場合は、プロファイルしてください。

于 2012-06-06T10:28:56.570 に答える
3

キャッシュに関しては、スペースを節約できます。キャッシュは、CPUが単一のアドレスを要求したか、キャッシュブロックサイズに等しい完全なチャンクを要求したかに関係なく、データのブロックを処理します。

したがって、32ビットの数値が64ビットマシンのキャッシュ内で64ビットのスペースを使用するかどうかを尋ねる場合、答えはノーです。それでも、32ビットの数値は32ビットを使用します。したがって、一般的に、特に頻繁にアクセスするような大きなアレイを使用している場合は、スペースを節約できます。

私の個人的な意見では、シンプルはよりシンプルintに見えsize_t、ほとんどのエディターはsize_tタイプを認識しないため、を使用すると構文の強調表示も向上しますint。;）

于 2012-06-06T10:27:48.543 に答える
3

少し剛体球モデルをコーディングしています。ソースはgithubにあります。

size_t配列のインデックスとして使用される変数やint、ワードサイズに関係のない他の操作を行う変数を使い続けようとしました。パフォーマンスの大幅な向上：実行時間の約27〜24時間の短縮。

于 2012-06-08T11:06:44.990 に答える
0

これは、コンパイラ開発者の決定である必要があります。

int「通常の」符号付き整数の自然型です。それが何であるかを決定するのはコンパイラー次第です。
特定のプラットフォームで64ビット整数を使用することに真の利点がある場合、コンパイラ開発者はint64ビットを作成することが期待されます。標準はそれを許可します。

コンパイラ開発者が32ビット整数を使用することにした場合は、通常、彼を信頼する必要があります。
まれに、大幅な最適化の取り組みを行った後、それがより効果的にlong機能する場合があります。次に、変更することをお勧めします。

于 2012-06-06T13:38:10.960 に答える