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

Question

查看 Alexandre C 的回复 在另一个主题中，我很想知道内置类型是否有任何性能差异：

char 与 short 与 int 与 float 与双。

通常我们在现实生活项目中不会考虑这种性能差异（如果有的话），但出于教育目的我想知道这一点。可以问的一般问题是：

• 积分运算和浮点运算之间有性能差异吗？

• 哪个更快？速度更快的原因是什么？请解释一下。

Answer 1

浮点与整数：

从历史上看，浮点可能比整数运算慢得多。在现代计算机上，情况已不再如此（在某些平台上速度会稍慢，但除非您编写完美的代码并针对每个周期进行优化，否则差异将被代码中的其他低效率问题所淹没）。

在一些有限的处理器上，例如高端手机中的处理器，浮点可能比整数慢一些，但只要有可用的硬件浮点，它通常在一个数量级内（或更好）。值得注意的是，随着手机被要求运行越来越多的通用计算工作负载，这种差距正在迅速缩小。

在非常有限的处理器（廉价手机和烤面包机）上，通常没有浮点硬件，因此需要在软件中模拟浮点运算。这很慢——比整数运算慢几个数量级。

正如我所说，人们期望他们的手机和其他设备的行为越来越像“真正的计算机”，硬件设计人员正在迅速增强 FPU 以满足这一需求。除非您追求每一个最后的周期，或者您正在为非常有限的 CPU 编写代码，这些 CPU 很少或没有浮点支持，否则性能差异对您来说并不重要。

不同大小的整数类型：

通常，CPU 在处理其本机字大小的整数时速度最快（对于 64 位系统有一些注意事项）。在现代 CPU 上，32 位操作通常比 8 位或 16 位操作更快，但不同架构之间的差异很大。另外，请记住，您不能孤立地考虑 CPU 的速度。它是一个复杂系统的一部分。即使对 16 位数字进行操作比对 32 位数字进行操作慢 2 倍，但当您使用 16 位数字而不是 32 位数字表示数据时，您可以在缓存层次结构中容纳两倍的数据。如果这使得所有数据都来自缓存而不是频繁缓存未命中，那么更快的内存访问将胜过 CPU 的更慢运行。

其他说明：

向量化进一步倾向于更窄的类型（浮点以及 8 位和 16 位整数）——您可以在向量中执行更多操作宽度相同。然而，好的矢量代码很难编写，因此如果不经过大量的仔细工作，您就无法获得这种好处。

为什么会有性能差异？

影响CPU运算速度快与慢的因素其实只有两个：运算的电路复杂度和用户对运算速度的要求。

（在合理范围内）如果芯片设计者愿意投入足够的晶体管来解决问题，任何操作都可以快速完成。但晶体管需要花钱（或者更确切地说，使用大量晶体管会使芯片变得更大，这意味着每个晶圆上的芯片更少，产量也更低，这会花钱），因此芯片设计人员必须平衡哪些操作使用多少复杂性，以及他们根据（感知的）用户需求来做到这一点。粗略地说，您可能会考虑将操作分为四类：

                 high demand            low demand
high complexity  FP add, multiply       division
low complexity   integer add            popcount, hcf
                 boolean ops, shifts

高要求、低复杂性的操作在几乎任何 CPU 上都会很快：它们是唾手可得的果实，并为每个晶体管带来最大的用户利益。

高要求、高复杂性的操作在昂贵的 CPU（如计算机中使用的 CPU）上速度会很快，因为用户愿意为此付费。然而，您可能不愿意为烤面包机额外支付 3 美元来实现快速 FP 乘法，因此便宜的 CPU 会忽略这些指令。

低需求、高复杂性的操作在几乎所有处理器上通常都会很慢；只是没有足够的好处来证明成本的合理性。

如果有人费心去思考，低需求、低复杂性的操作将会很快，否则就不存在。

进一步阅读：

• Agner Fog 维护着一个不错的网站，其中有很多关于低风险的讨论-级性能详细信息（并且有非常科学的数据收集方法来支持它）。
• 英特尔® 64 和 IA-32 架构优化参考手册（PDF 下载链接是页面下方）也涵盖了很多这些问题，尽管它专注于一个特定的架构系列。

Answer 2

绝对地。

首先，当然，这完全取决于所讨论的 CPU 架构。

然而，整型和浮点类型的处理方式非常不同，因此几乎总是这样：

• 对于简单操作，整型很快。例如，整数加法通常只有一个周期的延迟，而整数乘法通常约为 2-4 个周期（IIRC）。
• 浮点类型的执行速度要慢得多。然而，在当今的 CPU 上，它们具有出色的吞吐量，并且每个浮点单元通常可以在每个周期退出一个操作，从而获得与整数操作相同（或相似）的吞吐量。然而，延迟通常更差。浮点加法通常有 4 个周期左右的延迟（整数为 1 个周期）。
• 对于一些复杂的操作，情况则不同，甚至相反。例如，FP 上的除法可能比整数的延迟更少，仅仅是因为在这两种情况下实现操作都很复杂，但它在 FP 值上更常用，因此需要更多的努力（和晶体管）可能会花在优化该案例上。

在某些 CPU 上，双精度数可能比浮点数慢得多。在某些架构上，没有用于双精度的专用硬件，因此它们是通过传递两个浮点大小的块来处理的，这会给您带来更差的吞吐量和两倍的延迟。在其他系统上（例如 x86 FPU），两种类型都转换为相同的内部格式 80 位浮点（对于 x86），因此性能相同。在其他情况下，float 和 double 都有适当的硬件支持，但由于 float 的位数较少，因此可以更快地完成，通常相对于 double 操作会稍微减少延迟。

免责声明：所有提到的时间和特征都只是从记忆中提取的。我没有查过，所以可能是错误的。 ;)

对于不同的整数类型，答案因 CPU 架构而异。 x86 架构由于其漫长而复杂的历史，必须原生支持 8、16、32（以及今天的 64）位操作，并且一般来说，它们都同样快（它们使用基本相同的硬件，只是零根据需要取出高位）。

然而，在其他 CPU 上，小于 int 的数据类型的加载/存储成本可能更高（将字节写入内存可能必须通过加载其所在的整个 32 位字来完成，然后进行位掩码以更新寄存器中的单个字节，然后将整个字写回）。同样，对于大于 int 的数据类型，某些 CPU 可能必须将操作分成两部分，分别加载/存储/计算下半部分和上半部分。

但在 x86 上，答案是这并不重要。由于历史原因，CPU 需要对每种数据类型都有相当强大的支持。因此，您可能注意到的唯一区别是浮点运算有更多的延迟（但吞吐量相似，因此它们本身并不慢，至少如果您正确编写代码的话）

Answer 3

我认为没有人提到整数提升规则。在标准 C/C++ 中，不能对小于 int 的类型执行任何操作。如果 char 或 Short 在当前平台上恰好小于 int，它们会被隐式提升为 int （这是错误的主要来源）。编译器需要执行这种隐式升级，在不违反标准的情况下没有办法绕过它。

整数提升意味着语言中的任何操作（加法、按位、逻辑等）不能发生在比 int 更小的整数类型上。因此，对 char/short/int 的操作通常同样快，因为前者被提升为后者。

除了整数提升之外，还有“通常的算术转换”，这意味着 C 努力使两个操作数具有相同的类型，如果它们不同，则将其中之一转换为两者中较大的一个。

然而，CPU 可以在 8、16、32 等级别执行各种加载/存储操作。在 8 位和 16 位架构上，这通常意味着尽管有整数提升，8 位和 16 位类型的速度更快。在 32 位 CPU 上，这实际上可能意味着较小的类型较慢，因为它希望将所有内容整齐地排列在 32 位块中。 32 位编译器通常会优化速度并在比指定的更大的空间中分配更小的整数类型。

虽然通常较小的整数类型当然比较大的整数类型占用更少的空间，所以如果您打算优化 RAM 大小，那么它们是首选。

Answer 4

上面的第一个答案很棒，我将其中的一小部分复制到下面的副本中（因为这是我首先结束的地方）。

“char”和“small int”比“int”慢吗？< /a>

我想提供以下代码，用于配置分配、初始化并对各种整数大小进行一些算术：

#include <iostream>

#include <windows.h>

using std::cout; using std::cin; using std::endl;

LARGE_INTEGER StartingTime, EndingTime, ElapsedMicroseconds;
LARGE_INTEGER Frequency;

void inline showElapsed(const char activity [])
{
    QueryPerformanceCounter(&EndingTime);
    ElapsedMicroseconds.QuadPart = EndingTime.QuadPart - StartingTime.QuadPart;
    ElapsedMicroseconds.QuadPart *= 1000000;
    ElapsedMicroseconds.QuadPart /= Frequency.QuadPart;
    cout << activity << " took: " << ElapsedMicroseconds.QuadPart << "us" << endl;
}

int main()
{
    cout << "Hallo!" << endl << endl;

    QueryPerformanceFrequency(&Frequency);

    const int32_t count = 1100100;
    char activity[200];

    //-----------------------------------------------------------------------------------------//
    sprintf_s(activity, "Initialise & Set %d 8 bit integers", count);
    QueryPerformanceCounter(&StartingTime);

    int8_t *data8 = new int8_t[count];
    for (int i = 0; i < count; i++)
    {
        data8[i] = i;
    }
    showElapsed(activity);

    sprintf_s(activity, "Add 5 to %d 8 bit integers", count);
    QueryPerformanceCounter(&StartingTime);

    for (int i = 0; i < count; i++)
    {
        data8[i] = i + 5;
    }
    showElapsed(activity);
    cout << endl;
    //-----------------------------------------------------------------------------------------//

    //-----------------------------------------------------------------------------------------//
    sprintf_s(activity, "Initialise & Set %d 16 bit integers", count);
    QueryPerformanceCounter(&StartingTime);

    int16_t *data16 = new int16_t[count];
    for (int i = 0; i < count; i++)
    {
        data16[i] = i;
    }
    showElapsed(activity);

    sprintf_s(activity, "Add 5 to %d 16 bit integers", count);
    QueryPerformanceCounter(&StartingTime);

    for (int i = 0; i < count; i++)
    {
        data16[i] = i + 5;
    }
    showElapsed(activity);
    cout << endl;
    //-----------------------------------------------------------------------------------------//

    //-----------------------------------------------------------------------------------------//    
    sprintf_s(activity, "Initialise & Set %d 32 bit integers", count);
    QueryPerformanceCounter(&StartingTime);

    int32_t *data32 = new int32_t[count];
    for (int i = 0; i < count; i++)
    {
        data32[i] = i;
    }
    showElapsed(activity);

    sprintf_s(activity, "Add 5 to %d 32 bit integers", count);
    QueryPerformanceCounter(&StartingTime);

    for (int i = 0; i < count; i++)
    {
        data32[i] = i + 5;
    }
    showElapsed(activity);
    cout << endl;
    //-----------------------------------------------------------------------------------------//

    //-----------------------------------------------------------------------------------------//
    sprintf_s(activity, "Initialise & Set %d 64 bit integers", count);
    QueryPerformanceCounter(&StartingTime);

    int64_t *data64 = new int64_t[count];
    for (int i = 0; i < count; i++)
    {
        data64[i] = i;
    }
    showElapsed(activity);

    sprintf_s(activity, "Add 5 to %d 64 bit integers", count);
    QueryPerformanceCounter(&StartingTime);

    for (int i = 0; i < count; i++)
    {
        data64[i] = i + 5;
    }
    showElapsed(activity);
    cout << endl;
    //-----------------------------------------------------------------------------------------//

    getchar();
}


/*
My results on i7 4790k:

Initialise & Set 1100100 8 bit integers took: 444us
Add 5 to 1100100 8 bit integers took: 358us

Initialise & Set 1100100 16 bit integers took: 666us
Add 5 to 1100100 16 bit integers took: 359us

Initialise & Set 1100100 32 bit integers took: 870us
Add 5 to 1100100 32 bit integers took: 276us

Initialise & Set 1100100 64 bit integers took: 2201us
Add 5 to 1100100 64 bit integers took: 659us
*/

我在 i7 4790k 上的 MSVC 中的结果：

初始化 &设置 1100100 8 位整数花费：444us
将 5 加到 1100100 个 8 位整数花费：358us

初始化和初始化设置 1100100 16 位整数花费：666us
将 5 加到 1100100 个 16 位整数花费：359us

初始化和初始化设置 1100100 32 位整数花费：870us
将 5 加到 1100100 个 32 位整数花费：276us

初始化和初始化设置 1100100 64 位整数花费：2201us
将 5 加到 1100100 64 位整数花费：659us

Answer 5

积分运算和浮点运算之间有性能差异吗？

是的。然而，这在很大程度上是特定于平台和 CPU 的。不同的平台可以以不同的速度进行不同的算术运算。

话虽这么说，所讨论的答复有点更具体。 pow() 是一个处理双精度值的通用例程。通过向其提供整数值，它仍然可以完成处理非整数指数所需的所有工作。使用直接乘法可以绕过很多复杂性，这就是速度发挥作用的地方。这实际上不是不同类型的问题（这么多），而是绕过使用任何指数创建 pow 函数所需的大量复杂代码。

Answer 6

一般来说，整数数学比浮点数学更快。这是因为整数数学涉及更简单的计算。然而，在大多数操作中，我们谈论的时钟不到十几个。不是毫、微米、纳或刻度；时钟。在现代内核中每秒发生 2-30 亿次。此外，由于 486，许多内核都有一组浮点处理单元或 FPU，它们通过硬连线来有效地执行浮点运算，并且通常与 CPU 并行。

因此，尽管从技术上讲它速度较慢，但​​浮点计算仍然如此之快，以至于任何对差异进行计时的尝试都会在计时机制和线程调度中产生比执行计算实际所需的更多的固有错误。可以的时候使用整数，不能的时候要理解，并且不要太担心相对计算速度。

Answer 7

取决于处理器和平台的组成。

由于必须在协处理器之间传输值，因此具有浮点协处理器的平台可能比积分运算慢。

如果浮点处理位于处理器的核心内，则执行时间可以忽略不计。

如果通过软件模拟浮点计算，那么积分运算会更快。

如有疑问，请查看个人资料。

在优化之前让编程正确且稳健地工作。

Answer 8

不，不是真的。这当然取决于 CPU 和编译器，但性能差异通常可以忽略不计——如果有的话。

Answer 9

浮点数和整数运算之间肯定存在差异。根据 CPU 的特定硬件和微指令，您可以获得不同的性能和/或精度。准确描述的良好谷歌术语（我也不确切知道）：

FPU x87 MMX SSE

关于整数的大小，最好使用平台/架构字大小（或两倍），在 x86 和 int64_t 上它归结为 int32_t在 x86_64 上。有些处理器可能具有同时处理其中多个值的内在指令（例如 SSE（浮点）和 MMX），这将加快并行加法或乘法的速度。