

Java入門書を見ていたら、次のような記述がありました。

> 最近のコンピュータは多くのメモリを搭載しているため、これら4つの型を厳密に使い分ける必要があるケースはまれです。また、`short` や `byte`
> より `int` のほうが高速に処理できるコンピュータも多いので、 **整数を代入したい場合、通常は`int` 型** を使えば問題ありません。

何故shortやbyteなどの確保する記憶領域が少ないものの方が低速な処理になるという事が起こるのでしょうか？

何らかの最適化を行っているのでしょうが、直感とは反するので気になりました。

また、これはJavaのみの話ではなく他の言語でも同様なのでしょうか？(c言語など)


CC BY-SA 4.0
2017-11-06T15:17:50.677
39344
2022-11-07T16:27:02.030
2022-11-07T16:27:02.030
3060
25791
question
java c cpu
なぜ int は short や byte より高速に処理できる場合があるのか


（細かい話をすれば色々違うかもしれませんが以下は概念的な話として理解して下さい）  
例えば、３２ビットコンピュータの場合、３２ビットのデータを扱えます。  
３２ビットのデータを扱えるとは、８ビットのデータを４回に分けて扱う訳では無いということです。  
つまり、メモリからレジスタにデータを読み出す場合(８ビットずつ４回にわけて読込されるのではなく)３２ビットが並列的に読み込まれます。  
このような場合には、メモリから３２ビット毎の並びでデータを処理することが有利なわけです。  
反面、同じように１バイト(８ビット)のデータをメモリから読み出す場合、バイトの位置（３２ビット単位でいうと４つの位置があります）によって調整する必要が生じます。  
なので、その余分な操作の分速度に影響します。


CC BY-SA 3.0
2017-11-06T16:01:40.570
39347
2017-11-06T16:01:40.570
5044
39344
answer


演算の面でいうと 32bit CPU は 32bit の演算のみができるものが多い（というかほとんど）で、つまり 16/8 bit
の演算命令は無いわけです。 `short` や `byte` に対して演算を行う場合、結果を元の型つまり `short` や `byte`
に収めるための命令が余計に生成されることになり性能が低下します。

(x86 は 16/8 bit
の演算ができますし、数も多く出ていますが、互換性を維持するためにトランジスタ数が減らせなくてコストも高止まりしています。これが標準とは思わないほうが良い)


CC BY-SA 3.0
2017-11-06T21:44:24.893
39350
2017-11-06T21:44:24.893
8589
39344
answer


実際の速度を決定づけているのはJavaやCなどの言語ではなく、演算を実行するプロセッサーです。プロセッサーは表面上は8bit /
16bit演算をサポートしている場合もありますが、それでも内部的には32bitなどより大きな値で演算を行った上で値を切り詰めている場合があります。32bit
/ 64bitプロセッサーが一般的となっている現在では、`int`などで演算を行うのが無難です。  
その上で、大量の値を演算する場合は、不要なメモリアクセスを削減する目的で`char`や`short`などの適切な最小サイズを選択するべきですが、そうではない場合であれば、やはり`int`で十分です。

[x64では32ビット整数と64ビット整数の演算はどちらが高速？](https://ja.stackoverflow.com/q/22346/4236)も参考にしてください。特にEgtraさんがコメントされていますが、x86
/ x64プロセッサーでは16bit演算は8bit / 32bit演算に比べて少しだけ効率が悪いです。  
またC言語においては`int_fast8_t`、`int_fast16_t`等、 **8bit / 16bit演算を高速に行えるデータ型**
という概念が存在します。（もっとも、x86 / x64 Linuxでは不適切で実際にはあまり高速ではないという欠点がありますが…。）


CC BY-SA 3.0
2017-11-06T22:02:39.987
39351
2017-11-06T22:02:39.987
4236
39344
answer