什么时候应该使用ASM调用

几乎从不:

• 你只希望使用它一旦你已经分析了你的c++代码，并确定了一个特定的部分作为瓶颈。
• 即使这样，你也只想在用尽所有c++优化选项后再做。
• 即使这样，您也只希望将ASM用于紧密的内部循环。
• 即便如此，要在现代平台上击败c++编译器也需要相当多的努力和技巧。

如果你不是一个有经验的汇编程序员，我怀疑你能比你的编译器更好地优化汇编代码。

还要注意程序集是不可移植的。如果您决定采用这种方式，您将不得不为您决定支持的所有体系结构编写不同的程序集。

简短的回答:看情况，很可能你不需要它。

不要过早地开始优化。编写易于阅读和修改的代码。将逻辑部分分成模块。写一些容易扩展的东西

做一些分析。

你不能告诉你的瓶颈在哪里，除非你分析你的代码。99%的情况下，您不会通过编写asm获得那么多的性能提升。很有可能你的表现甚至会变差。现在的优化器非常擅长他们所做的事情。如果你确实遇到瓶颈，那很可能是因为一些选择不当的算法，或者至少是一些可以在高级中修复的东西。

我的建议是，即使你学习了asm，这是一件好事，也不要只是为了优化而学习。

Profile Profile Profile ....

进入低级(尽管有时编译器可以为您推断)的合法用例是使用SIMD指令，例如SSE。我认为至少你提到的一些算法将受益于并行处理。

但是，您不需要编写实际的汇编，相反，您可以简单地使用内在函数。看，比如这个。

不要操之过急。

我发布了一个sourceforge项目，展示了一个模拟程序是如何大规模加速的(超过700倍)。

这不是通过预先假设需要快速制作的内容来完成的。

它是通过"剖析"完成的，我把它放在引号里，因为我使用的方法不是使用剖析器。相反，我依赖于随机暂停，这是一种已知的方法，并且被一些程序员使用过，效果很好。

它通过一系列迭代进行。在每次迭代中，识别和固定大量的时间消耗源，从而产生一定的加速比。

在进行多次迭代时，这些加速比率会相乘(就像复利一样)。这就是如何获得major加速。

当，且仅当，某些代码占用大量时间，且不包含任何函数调用时，你认为你可以编写比编译器更好的汇编代码，那么就去做吧。

注:如果您想知道，使用分析器和随机暂停之间的区别在于，分析器查找"瓶颈"，假设这些是局部的东西。他们寻找占总时间很大比例的例程或代码行。他们忽略的是那些弥散的问题。例如，您可以有100个例程，每个例程占用1%的时间。也就是说，没有瓶颈。然而，可能有一个活动在许多或所有这些例程中完成，占1/3的时间，可以做得更好或根本不做。随机暂停会看到少量样本的活动，因为你不是总结，而是检查样本。换句话说，如果你取9个样本，平均你会注意到其中3个样本的活动。这说明它很大。所以你可以修复它，得到3/2的加速比

"要理解递归，必须首先理解递归。"当我考虑我对你的问题的回答时，这句话浮现在我的脑海中，这是"直到你知道什么时候使用汇编，你永远不应该使用汇编。"在您完全实现了您的解决方案，广泛地分析了它的性能并确定了精确的瓶颈，并试验了几种替代解决方案之后，您可以开始考虑使用汇编。如果在您有一个工作和广泛分析的程序之前编写了一行汇编代码，那么您就犯了一个错误。

如果你需要问，那你就不需要了。