int运算通常比float快，因整数单元延迟低、吞吐高；但除法、取模等例外，且simd/fma可提升float加减速度；float循环计数易致精度误差和性能下降。
int 运算通常比 float 快，但取决于具体操作和硬件
现代 CPU 上，int 的整数加减乘（尤其不溢出时）一般比 float 的对应运算快，主因是整数单元更简单、延迟更低、吞吐更高。但除法、取模、位操作等例外；而 float 的加减在支持 SIMD 或 FMA 的 CPU 上可能接近整数速度。关键不是“类型本身快”，而是“指令路径是否被充分优化”。
常见错误现象：float 循环计数（如 for (float i = 0; i ）不仅慢，还容易因精度丢失导致无限循环或跳过边界——这是典型误用，不是性能问题，是逻辑缺陷。
- 使用场景：密集数值计算（如图像处理、物理模拟）中，若数据天然为整数（像素坐标、索引），硬转
float反而引入转换开销和缓存压力 - 参数差异：
int运算不涉及舍入、NaN、无穷等检查；float每次运算都可能触发异常标志（即使未启用异常）、需遵守 IEEE 754 规则 - 性能影响：x86-64 下，
add eax, ebx延迟约 1 cycle；addss xmm0, xmm1延迟常为 3–4 cycles（视微架构而定）；但 AVX-512 下批量float加法可远超单条整数指令吞吐
别忽略隐式转换带来的真实开销
混合 int 和 float 运算时，编译器必须插入转换指令，比如 int → float 调用 cvtsi2ss，这比纯整数加法多 2–4 cycles，且可能打破指令流水线。
示例：int a = 10; float b = 3.14f; auto c = a * b; —— 这里 a 被悄悄转成 float，再做浮点乘。如果本意只是缩放整数，应改用 static_cast<float>(a) * b</float> 显式表达，并确认是否真需要浮点结果。
立即学习“C++免费学习笔记（深入）”；
- 容易踩的坑：模板函数中传入
int却被推导为float类型（如auto x = sqrt(4);在 C++11 后返回double），引发一连串隐式升格 - 兼容性影响：ARM Cortex-A 系列上，整数到浮点转换延迟显著高于 x86；某些嵌入式 MCU 甚至无硬件浮点单元，
float运算全靠软件模拟，慢几个数量级
用 benchmark 判断，而不是靠“常识”
“int 快”只是粗略经验，实际要看编译器优化级别、目标架构、数据局部性、是否向量化。比如 GCC/Clang 在 -O2 下对 int 循环常做强度削减（strength reduction），把乘法换成移位加法；而对 float 循环可能保留原指令，也可能自动向量化——结果完全相反。
实操建议：用 std::chrono 测真实热点，确保测试代码不被优化掉（如把结果写入 volatile 变量或输出到全局）。别测空循环，要测带内存访问、分支、依赖链的典型模式。
- 示例陷阱：
for (int i = 0; i vs <code>for (float i = 0; i —— 后者多出 float→int 转换 + 潜在精度截断，且编译器很难向量化 - 性能工具推荐：Linux 下用
perf stat -e cycles,instructions,uops_issued.any看 IPC 和微指令数，比单纯看 wall-clock 更准
真正拖慢程序的往往不是 int 或 float，而是 cache 和分支
在绝大多数非计算密集型场景中，int 和 float 运算速度差异可以忽略。一次 L3 cache miss（~40 ns）就抵得上几百次整数加法；一次错误预测的分支（~15 cycles）可能吃掉整个小循环的收益。
所以优先检查：数组是否按行连续访问？指针是否别名混乱导致编译器不敢向量化？循环是否含难以预测的 if？这些的影响远大于底层类型选择。
- 容易被忽略的地方：结构体中混用
int8_t和float可能导致填充字节增多，缓存行利用率下降；用vector<float></float>存大量小整数（如 0–255）反而浪费带宽和空间 - 复杂点在于：性能是系统级现象。你改了类型，可能让编译器选了不同指令序列，进而影响寄存器分配、流水线调度、甚至最终生成的机器码大小——这些都得实测，没法静态推断
