是“char”和“小int”比“int”慢 [英] Are "char" and "small int" slower than "int"?

问题描述

可能重复：

内置类型的性能：char vs short vs int VS float VS double

假设您有 32位处理器。是8位 char 和16位 short int 类型比本机32位 int ？
使用64位 long long int ？

这些数据类型默认支持硬件，或者通过使用附加的指令，它们都被转换成32位数据？

如果我必须存储少量的字符，

解决方案

在任何现代实用的机器上， char ， int 和 long 都会很快

有了 short ，在cpu架构和单个架构中甚至不同的cpu模型之间，说，没有好的理由使用小类型的单个变量，不管他们的速度。他们的语义混乱（由于默认促销 int ），他们不会保存你有意义的空间（甚至没有任何空间）。我只能使用 char ， short ， int8_t ， int16_t 等在数组或结构中必须匹配一个固定的二进制布局，你将有这么多的（例如像素或音频样本）每个人的大小实际上很重要。

Possible Duplicate:
Performance of built-in types : char vs short vs int vs. float vs. double

Hi. Assume, that you have 32-bit processor. Are 8-bit char and 16-bit short int types slower than native 32-bit int? What about using 64-bit long long int?

Are this datatypes supported by hardware by default, or they are all transformed into 32-bit data anyway, by using additional instructions?

In case, that I have to store a small amount of chars, isn't it faster to store them as ints?

解决方案

On any modern, practical machine, char, int, and long will all be fast (probably equally fast). Whether short is fast or not varies somewhat between cpu architecture and even different cpu models within a single architecture.

With that said, there's really no good reason to use small types for single variables, regardless of their speed. Their semantics are confusing (due to default promotions to int) and they will not save you significant space (maybe not even any space). The only time I would ever use char, short, int8_t, int16_t, etc. is in arrays or structs that have to match a fixed binary layout of where you'll have so many of them (e.g. pixels or audio samples) that the size of each one actually matters.

这篇关于是“char”和“小int”比“int”慢的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！