Question

基于这篇文章中的参数：Performance of Built-in types，我可以得出结论，基于int的点结构的自定义实现比基于浮点的CGPoint更快或更有效吗？我已经回顾了许多关于类型性能差异的帖子，但没有找到包含由结构进一步包装的场景的帖子。感谢。

// Coord 
typedef struct {
    int x;
    int y;
} Coord;

CG_INLINE Coord CoordMake(int x, int y){
    Coord coord; coord.x = x; coord.y = y; return coord;
}

CG_INLINE bool CoordEqualToCoord(Coord coord, Coord anotherCoord) {
    return coord.x == anotherCoord.x && coord.y == anotherCoord.y;
}

CG_INLINE CGPoint CGPointForCoord(Coord coord) {
    return CGPointMake(coord.x, coord.y);
}

编辑：我已经完成了纯粹的算术测试，结果几乎可以忽略不计，直到数百万次迭代，我的应用程序将无法完成。我将继续使用Coord typedef，但会删除结构，因为@含义 - 事项暗示的一些原因。为了记录，测试确实表明基于int的结构快了大约30％，但是0.0001秒的30％并不是任何人应该关心的。我仍然对实施更好的要点和反点感兴趣。

Answer 1

这取决于你正在做什么。对于普通算术，吞吐量可以类似。整数延迟通常会少一些。在某些处理器上，GPR的延迟对于GPR而言比FPR更好。因此，对于许多测试，结果将相同或为整数计算提供小的优势。在32位计算机上，余额将翻转另一种方式进行双重与int64_t计算。（如果你正在编写CPU矢量代码并且可以使用16位计算，那么使用整数会快得多。）

但是，在计算坐标/地址以便将数据加载到寄存器中或从寄存器中存储数据的情况下，整数在CPU上显然更好。原因是加载或存储指令可以将整数操作数作为数组的索引，而不是浮点数。要使用浮点坐标，您至少必须先转换为整数，然后加载或存储，因此它应该总是较慢。通常，还必须设置一些舍入模式（例如，floor（）操作）并且可能需要一些非平凡的操作来考虑边缘模式，例如CL_ADDRESS_REPEAT寻址模式。对比一个简单的AND操作，这可能是在整数上实现相同的事情所必需的，并且应该清楚整数是一种更便宜的格式。

在GPU上，它更强调浮点计算，并且可能不会在整数计算上投入太多（即使它更容易），故事情况也大相径庭。在那里，您可以期望纹理单元硬件直接使用浮点值来查找所需的数据。用于找到正确坐标的浮点算法内置于硬件中，因此＆＃34; free＆＃34; （如果我们忽略了能耗考虑因素），并且围绕它构建了GL或CL等图形API。

一般来说，虽然在图形API中无处不在，浮点本身在采样数据的坐标系中是数字上较差的选择。它在图像的一个角落中会产生过多的精度，并且可能导致图像远角处的量化误差/不一致，从而导致线性采样的精度降低和意外的舍入效应。对于足够大的图像，图像中的一些像素可能变得不可被坐标系统寻址，因为不存在引用该位置的浮点数。可能的情况是，对于坐标系统，默认的舍入模式，舍入到最接近的偶数是不合需要的，因为线性过滤通常将坐标放置在两个整数值之间的中间位置，导致偶数像素向上舍入并向下舍入为奇数。这会导致像素重复而不是预期的结果，在最坏的情况下，它们都是地狱般的情况，而步幅是1.它很好用，它更容易使用。

定点坐标系统允许一致的坐标精度和整个表面的圆角，并将避免这些问题。 Modulo溢出很好地融入了一些常见的边缘模式。精度是可预测的。

Answer 2

通过快速搜索确认32位int和float操作在ARM处理器上看起来同样快（并且每个操作需要1个CPU周期）。请按照Zev Eisenberg的正确建议，自己寻找并做一个简单的测试。

然后由于以下原因（仅举几例）开始使用CGPoint编写自己的int内容并不是一个好主意：

结果不正确：将坐标舍入或截断为整数会产生各种奇怪/可怕/副作用。
与众多iOS库不兼容。
浪费时间。
不快。
创建一个混乱的代码库（Knuth在Zaph引入时是正确的。）

与尝试优化时一样：退后一步，调查您当前的方法/算法是否是最佳选择（对于您应用程序中可能的不同场景）。这是通常大规模改进数百％的方法。

Objective C float vs int，CGPoint vs基于自定义int的结构性能

2 个答案: