me_*_*and 5 c int performance char
char在C中使用小整数有什么不利吗？除了占用/记忆效益之外还有其他优点吗？
特别是,处理器是否可能char更好或更差地应对整数运算(long/ short)int？
我知道这将是处理器/系统/编译器特定的,但我希望在一般情况下得到答案,或者至少是32位Windows和Solaris的一般情况,我正在研究的系统.我还假设已经处理了溢出/回绕问题等问题.
更新:Visual Studio 6.0实际上没有stdint.hChristoph建议的那样.Windows上的一些基准测试(VS 6.0,调试版本,32位)与一些堆叠循环一起提供int并long提供类似的性能,大约是其两倍char.使用gcc在Linux上运行相同的测试,类似于pegs int和long类似,并且速度都快char,尽管差异不太明显.
作为旁注,我没有花太多时间观察,但我发现(通过维基百科)的VS 6.0 的第一个实现stdint.h定义为,尽管在我的测试中看起来似乎更慢.因此,正如Christoph正确地提出的那样,故事的寓意:始终是基准!uint_fast8_tunsigned char
Chr*_*oph 12
C99添加了所谓的"最快"最小宽度整数类型来解决这个问题.对于您感兴趣的范围,类型将是int_fast8_t和uint_fast8_t,可以在中找到stdint.h.
请记住,可能没有性能提升(内存消耗的增加甚至可能会减慢速度); 一如既往,基准!不要过早地或仅仅根据应该起作用的可能有缺陷的假设进行优化.
好吧,第一个问题是C标准没有定义普通char是有符号还是无符号 - 所以你可以依赖的唯一范围是0到127.
除此之外,通常int应该是与体系结构的本机字大小相对应的类型(但当然这不是由任何东西强制实施的).这往往是具有最佳算术性能的类型,但这就是你所能说的.
需要注意的是操作数窄于int被加宽要么int或unsigned int反正表达式求值期间.