引用一下（感谢作者开发和分享算法！）：
https://tavianator.com/fast-branchless-raybounding-box-intersections/
由于现代浮点指令集可以在没有分支的情况下计算最小值和最大值
作者提供的相应代码如下：
dmnsn_min(double a, double b)
{
return a < b ? a : b;
}
_mm_max_ps，但那是一个向量指令。上面的代码明显是以标量形式使用的。_mm_min_ps/_mm_max_ps（以及_pd）内嵌函数视为可交换，即使汇编指令不是这样。特别是GCC似乎有这个错误：PR72867，这个错误已经在GCC7中修复，但对于_mm_min_ss等标量内嵌函数可能会再次出现或永远不会被修复（_mm_max_ss在clang和gcc之间有不同的行为，GCC bugzilla PR99497）。fmin(a,b)（保证NaN传播），因此您必须在易于检测问题与更高性能之间做出选择。
大多数矢量 FP 指令都有标量对应物。MINSS / MAXSS / MINSD / MAXSD 是你需要的指令。它们按照您预期的方式处理 +/-Infinity。
MINSS a,b 完全 根据 IEEE 规则实现了 (a<b) ? a : b，这意味着它保留源操作数 b 的值，并在 NaN 和 Infinities 时做出了相应处理。(即，在无法比较的情况下，b 保留。) 这意味着 C++ 编译器可以将它们用于 std::min(b,a) 和 std::max(b,a)，因为这些函数基于同一表达式。请注意 std:: 函数的操作数顺序为 b,a，与 x86 asm 的 Intel 语法相反，但与 AT&T 语法匹配。
MAXSS a,b 是将 b 与 a 进行比较，并返回较大的值，如果两个数相等，则返回其中任意一个。与此同时，b 保持不变。类似于 std::max(b,a)。
使用 x = std::min(arr[i], x); 对数组进行循环（即使用 minss 或者 maxss xmm0, [rsi]），如果内存中存在 NaN，将会获取该 NaN，并且将其后面的非 NaN 元素作为结果返回。因此，你通常不希望这样做，因为它只适用于不包含 NaN 的数组。但是，这意味着您可以在循环外部使用 float v = NAN;，而不是使用第一个元素或 FLT_MAX 或 +Infinity，这可能简化处理可能为空的列表的方式。在汇编代码中，它还是很方便的，可以使用 pcmpeqd xmm0,xmm0 进行初始化以生成一个全为 1 的位模式（负 QNAN），但不幸的是 GCC 的 NAN 使用了不同的位模式。
v = std::min(v, arr[i]);（或max）忽略数组中的NaN，代价是需要加载到寄存器中，然后将其minss到该寄存器。_mm_min_ss; 这个内置函数只能用于__m128操作数，并且Intel的内置函数没有任何方法将标量浮点数放入__m128的低元素中，而不清零高元素或以某种方式进行额外工作。 即使最终结果不依赖于上部元素中的任何内容，大多数编译器实际上仍会发出无用的指令来执行此操作。(Clang通常可以避免这种情况，通过死向量元素的内容应用as-if规则。) 没有像__m256 _mm256_castps128_ps256 (__m128 a)这样的东西，可以将浮点数强制转换为带有垃圾值的__m128。我认为这是一个设计缺陷。 :/
但幸运的是，你不需要手动执行此操作，编译器知道如何为您使用SSE/SSE2 min/max。 只需编写您的C代码即可。 你问题中的函数是理想的：如下所示（Godbolt链接）：
// can and does inline to a single MINSD instruction, and can auto-vectorize easily
static inline double
dmnsn_min(double a, double b) {
return a < b ? a : b;
}
_mm_min_ss/_mm_min_ps内部函数可能具有或不具有此行为，这取决于编译器。
我认为内部函数应该具有与asm指令相同的操作数顺序语义，但gcc很长时间以来已将_mm_min_ps的操作数视为可交换甚至没有启用-ffast-math，从gcc4.4或更早版本开始。GCC 7最终对其进行了更改以匹配ICC和clang。
英特尔的在线内部函数查找器没有记录该函数的行为，但它可能不应该是详尽无遗的。汇编指令参考手册并未说明内部函数不具备该属性；它只将_mm_min_ss列为MINSS的内部函数。
当我在谷歌上搜索"_mm_min_ps" NaN时，我发现this real code和其他一些关于使用内部函数处理NaN的讨论，因此许多人明显期望该内部函数的行为类似于汇编指令。(这是我昨天写代码时遇到的情况，我已经考虑撰写这篇自问自答的问答文章了。)
std::min和std::max中的函数，它们是基于>或<定义的，并且不像fmin和fmax那样对NaN的行为有相同的要求。除非您需要其NaN行为，否则请避免使用fmin and fmax以提高性能。
在C语言中，我认为只需编写自己的min和max函数（如果安全的话可以使用宏）。
float minfloat(float a, float b) {
return (a<b) ? a : b;
}
# any decent compiler (gcc, clang, icc), without any -ffast-math or anything:
minss xmm0, xmm1
ret
// C++
float minfloat_std(float a, float b) { return std::min(a,b); }
# This implementation of std::min uses (b<a) : b : a;
# So it can produce the result only in the register that b was in
# This isn't worse (when inlined), just opposite
minss xmm1, xmm0
movaps xmm0, xmm1
ret
float minfloat_fmin(float a, float b) { return fminf(a, b); }
# clang inlines fmin; other compilers just tailcall it.
minfloat_fmin(float, float):
movaps xmm2, xmm0
cmpunordss xmm2, xmm2
movaps xmm3, xmm2
andps xmm3, xmm1
minss xmm1, xmm0
andnps xmm2, xmm1
orps xmm2, xmm3
movaps xmm0, xmm2
ret
# Obviously you don't want this if you don't need it.
_mm_min_ss / _mm_min_ps，请编写代码，使编译器即使没有使用 -ffast-math 选项也能生成良好的汇编代码。lowest = _mm_min_ps(lowest, some_loop_variable);
因此，即使没有AVX，也可以就地更新持有lowest的寄存器。
假设你的标量代码是这样的
if(some condition)
lowest = min(lowest, x);
PSRAD xmm, 31广播符号位。)x与+Inf混合。或者执行newval = min(lowest, x);并将newval混合到lowest中。(使用BLENDVPS或AND/ANDNOT/OR)。__m128 inverse_condition = _mm_cmplt_ps(foo, bar);
__m128 x = whatever;
x = _mm_or_ps(x, condition); // turn elements into NaN where the mask is all-ones
lowest = _mm_min_ps(x, lowest); // NaN elements in x mean no change in lowest
// REQUIRES NON-COMMUTATIVE _mm_min_ps: no -ffast-math
// AND DOESN'T WORK AT ALL WITH MOST GCC VERSIONS.
minss/minsd。即使没有这样的指令，其他架构也应该能够使用条件移动实现无分支。gcc和clang都会将(a < b) ? a : b优化为minss/minsd，所以我不需要使用内部函数。但不能确定其他编译器是否会这样做。a < b测试几乎是完全不可预测的，因此避免这些分支非常重要。像if (ray.dir.x != 0.0)这样的测试非常可预测，因此避免这些分支不那么重要，但它确实可以缩小代码大小并使其更容易向量化。最重要的部分可能是消除除法。minss/minsd的行为与(a < b) ? a : b完全相同，包括它们对无穷大和NaN的处理。
_mm_max_ps有一个标量等效函数_mm_max_ss。 - haroldfmin()、fmax()的行为，我没有向他们建议，尽管个人而言，那是我的首选（它是最直接的C代码，我习惯于在平台上工作，其中映射到一个机器指令；很惊讶地发现这对于x86仍然不是真实的）。我也没有对你的答案有任何意见，所以我认为我们是“激烈的一致” :-) - njuffa