在状态 WaitingForInfo 中超时。关闭。(我只是个机器人，如果这是个错误或者你有请求的信息，请大声说出来。)

遗憾的是，go1基准测试显示硬件除法运行时检查几乎没有改进。

"GOARM=8"之所以能发挥良好作用，是因为：

1. 软件分频例程会覆盖2个额外的寄存器。
2. 软件分频例程会用填充的结果覆盖输入寄存器。
   使用"GOARM=8",编译器可以将更多的分割值填充到保存的寄存器中，从而提高go1基准测试性能。
   因此，我强烈建议添加GOARM=8,正如ARM的官方定义：
3. ARMv8 == Aarch64 + Aarch32
4. Aarch64(ARM的术语) == ARM64(Go的术语)
5. Aarch32 = ARM32 + HWDIV + 其他一些特性
   GOARM=8不仅能提高除法速度，还具有潜在的好处(在armv8机器上运行arm32程序)

$\dfrac{1}{3}$

我认为为仅有两个指令引入另一个GOARM值并不是一个好主意，性能提升小于geomean的1%。在这种情况下，我认为动态特征检测仍然更好。
我不确定这是否适用于这里(甚至可能与现代内存保护机制一起使用),但在过去，动态特征检测有时是通过在运行时逐个调用来对可执行文件进行打补丁实现的。

你的意见是什么？

我认为为仅有的两个指令引入另一个GOARM值并不是一个好主意，性能提升小于geomean的1%。在这种情况下，我认为动态特征检测仍然更好。如果运行时的调用开销比我们想象的要大，我们可以内联生成特征测试和条件分支。与除法操作相比，我认为条件分支的开销是可接受的。

这听起来像是提案中的GOARM=8表示ARMv7+hwdivide。
而ARMv8是64位的ARM,对吧？
所以用32位的ARMv7和hw divide来调用GOARM=8有点奇怪。
从性能Angular 来看，这似乎并不重要。也许编译器应该发出代码来进行检查+分支，就像我们已经为写屏障所做的那样？这至少可以允许对硬件代码路径进行更多的优化(不进行不必要的溢出/重新加载等)。
一个非常依赖除法的函数可能只需要两个副本，编译器可以将检查从循环或其他主体中提升出来，以实现摊销，而无需使用GOARM=。
另一个选择是遵循GOMIPS并将GOARM=7+divide。但是，尝试更快的分支检查(类似于写屏障)似乎更好。

Can someone please try the faster branch check in the previous comment? We should have that data before making any decision to expose this detail to users.