我正在处理一段代码，在其中需要处理不一定在0到1范围内的UV坐标（2D纹理坐标）。举个例子，有时我会得到一个具有u分量为1.2的UV坐标。为了处理这种情况，我正在实现一个包裹（wrapping）功能，通过以下方式实现重复平铺：
u -= floor(u)
v -= floor(v)
这样做会使1.2变为0.2，这是期望的结果。它还处理了负数情况，例如-0.4变为0.6。
然而，这些floor函数调用相当慢。我使用Intel VTune对我的应用程序进行了分析，并且我花费了大量的周期来执行此floor操作。
在对该问题进行一些背景阅读后，我得出了以下函数，它略微更快，但仍然有很多需要改进的空间（我仍然会遇到类型转换惩罚等问题）。
int inline fasterfloor( const float x ) { return x > 0 ? (int) x : (int) x - 1; }
我看到过一些使用内联汇编完成的技巧，但似乎没有任何一个能完全正确工作或有显著的速度提升。
有没有人知道如何处理这种情况的技巧？
虽然是老问题，但我却遇到了，并对没有得到令人满意的答案感到有些不满。
总之，不要使用内联汇编、内建函数或其他给出的解决方案！相反，使用快速/不安全的数学优化（在g++中使用“-ffast-math -funsafe-math-optimizations -fno-math-errno”）。floor()的运行速度之所以如此慢，是因为如果转换会导致溢出（FLT_MAX无法适应任何大小的标量整数类型），它会更改全局状态，这也使得它无法向量化，除非你禁用严格的IEEE-754兼容性，但你应该尽可能不依赖它。使用这些标志进行编译可以禁用这个问题。
一些备注：
使用标量寄存器的内联汇编不可向量化，这严重限制了编译时的性能。它还要求任何存储在矢量寄存器中的相关值都必须溢出到堆栈中并重新加载到标量寄存器中，这违背了手动优化的目的。
使用SSE cvttss2si 的内联汇编，按照你提供的方法，实际上比一个简单的for循环加上编译器优化更慢。
这可能是因为如果允许它将整个代码块向量化在一起，编译器将更好地分配寄存器并避免流水线停顿。对于像这样具有很少内部依赖链和几乎没有机会发生寄存器溢出的短代码片段，它几乎不可能比被asm()包围的手动优化代码表现更差。内联汇编是不可移植的，在Visual Studio 64位版本中不受支持，并且极难阅读。内建函数也遭受同样的警告以及上述提到的问题。
所以你想进行一个非常快的浮点数转整数？据我所知，整数向浮点数转换很快，但至少在MSVC ++上，浮点数向整数转换会调用一个小的辅助函数ftol()，这个函数会做一些复杂的处理来确保进行符合标准的转换。如果您不需要如此严格的转换，可以使用一些汇编技巧，假设您使用的是兼容x86的CPU。
下面是一个用于将浮点数快速舍入为整数的函数，使用MSVC++内联汇编语法（它应该能给你正确的思路）：
inline int ftoi_fast(float f)
{
int i;
__asm
{
fld f
fistp i
}
return i;
}
在MSVC++ 64位中，由于64位编译器拒绝内联汇编，因此您需要一个外部的.asm文件。该函数基本上使用原始的x87 FPU指令来加载浮点数（fld），然后将其存储为整数（fistp）。请注意：您可以通过直接调整CPU上的寄存器来更改此处使用的舍入模式，但不要这样做，否则会破坏很多东西，包括MSVC对sin和cos的实现！
如果您可以假定CPU支持SSE（或者有一种简单的方法来生成支持SSE的代码路径），您也可以尝试：
#include <emmintrin.h>
inline int ftoi_sse1(float f)
{
return _mm_cvtt_ss2si(_mm_load_ss(&f)); // SSE1 instructions for float->int
}
基本上是相同的操作（将浮点数加载，然后存储为整数），但使用的是 SSE 指令，这些指令稍微快一些。
其中之一应该涵盖了昂贵的浮点数转整数情况，同时任何整数到浮点数的转换都应该便宜。很抱歉，我在这里只提到了 Microsoft 特定的情况，但这是我进行类似性能优化工作的地方，我通过这种方式获得了很大的性能提升。如果可移植性/其他编译器是一个问题，你将不得不寻找其他方法，但这些函数编译成可能只需少于5个时钟周期的两条指令，而不是需要100多个时钟周期的辅助函数。
ftoi_fast函数比让编译器自动生成代码显着更快。 - Cody Grayftol()函数。因此，在64位构建中，您无需执行使用外部ASM文件的所有工作；实际上，这样做可能会导致比编译器生成的代码稍慢的代码！ - Cody Gray#include <math.h>
u = fmodf(u, 1.0f);
u = (u + 16.0); // Does not affect fractional part aside from roundoff errors.
u -= (int)u; // Recovers fractional part if positive.
就此而言，根据您的数据外观和处理器类型，如果其中很大一部分是负数，但只有很小一部分低于16.0，则在进行条件整数转换之前添加16.0f可能会使您的条件可预测，从而提高速度。或者您的编译器可能会使用其他类型的条件分支来实现这个功能，那么它就没有用处了；除非进行测试并查看生成的汇编代码，否则很难说。
如果范围较小，另一个可能行得通的愚蠢想法是 ...
使用位操作从浮点数中提取指数，然后使用查找表查找掩码以从尾数中擦除不需要的位。使用此查找表可以找到最低值（清除小数点以下的位），以避免重新归一化问题。
编辑 我将其删除，因为它太愚蠢了，而且还存在正负问题。由于它被投票赞成了，所以我把它恢复了，让其他人决定它有多愚蠢。
这个方法不能解决转换成本，但应该在数学上是正确的：
int inline fasterfloor( const float x ) { return x < 0 ? (int) x == x ? (int) x : (int) x -1 : (int) x; }
如果可能出现的值的范围非常小，也许你可以使用二分查找来确定底部的值。例如，如果可能出现的值满足 -2 <= x < 2...
if (u < 0.0)
{
if (u < 1.0)
{
// floor is 0
}
else
{
// floor is 1
}
}
else
{
if (u < -1.0)
{
// floor is -2
}
else
{
// floor is -1
}
}
我对此不做任何保证 - 我不知道比较效率与floor相比如何，但值得一试。
if (u>1) u -= 1 至少需要两条指令 - 比较、减法，以及根据架构如何处理条件语句可能需要额外的指令。 - Ponkadoodle