我何时应该使用ASM呼叫?

时间:2011-12-13 12:06:52

标签: c++ performance assembly

我打算用C ++编写一个游戏,它将非常耗费CPU(寻路,遗传算法,神经网络......) 所以我一直在考虑如何最好地解决这种情况,以便顺利运行。

(让这个问题的上半部分是旁边的信息,我不希望它限制主要问题,但如果你能给我一些附注也会很好) < / p>


学习如何使用ASM是否值得,所以我可以用C ++进行ASM调用, 它能给我一个显着/显着的性能优势吗?

我应该在什么情况下使用它?

7 个答案:

答案 0 :(得分:14)

几乎从不:

  • 您只想在分析C ++代码并将特定部分标识为瓶颈后使用它。
  • 即便如此,只有在用完所有C ++优化选项后才会这样做。
  • 即便如此,你只想使用ASM进行紧密的内循环。
  • 即便如此,在现代平台上击败C ++编译器需要付出相当多的努力和技巧。

答案 1 :(得分:4)

如果您不是一位经验丰富的汇编程序员,我怀疑您是否能够比编译器更好地优化汇编代码。

另请注意,装配不可移植。如果您决定采用这种方式,则必须为您决定支持的所有体系结构编写不同的程序集。

答案 2 :(得分:3)

简答:取决于您,很可能您不需要它。

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

做一些分析。

除非您对代码进行分析,否则无法确定瓶颈在哪里。通过编写asm,99%的时间你不会获得如此多的性能提升。您甚至可能恶化您的表现。如今的优化工具非常擅长他们的工作。如果你确实有瓶颈,很可能是因为一些选择不当的算法,或者至少可以在高级别中解决的问题。

我的建议是,即使你确实学习了asm,这是一件好事,也不要这样做,以便你可以优化。

个人资料个人资料....

答案 3 :(得分:3)

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

但是,您不需要编写实际的程序集,而只需使用内部函数。见,例如, this

答案 4 :(得分:2)

不要超越自己。

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

这不是通过事先假设需要快速完成的事情来完成的。

这是通过“profiling”完成的,我把它放在引号中,因为我使用的方法不是使用分析器。 相反,我依赖于random pausing,这是一种已知的方法,并且被一些程序员使用效果很好。

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

当您进行多次迭代时,这些加速比率会相乘(如复合兴趣)。 这就是你获得主要加速的方式。

当且仅当你遇到一些代码占用大部分时间并且它不包含任何函数调用的点时,你认为你可以编写汇编代码比编译器更好,那么去吧。

P.S。如果您想知道,使用分析器和随机暂停之间的区别在于分析器会在假设这些是本地化的东西时寻找“瓶颈”。他们寻找负责大部分总时间的例程或代码行。 他们错过的是 diffuse 的问题。 例如,您可以有100个例程,每个例程占用1%的时间。 也就是说,没有瓶颈。 但是,在许多或所有这些例程中可能会进行一项活动,占1/3的时间,可以做得更好或根本不做。 随机暂停将看到具有少量样本的活动,因为您没有总结,您检查样本。 换句话说,如果您拍摄了9个样本,平均而言您会注意到其中3个样本的活动。 这告诉你它很重要。 所以你可以修复它并获得你的3/2加速比。

答案 5 :(得分:1)

“要理解递归,首先必须了解递归。”当我考虑我对你的问题的回答时会想到这句话,“直到你明白何时使用汇编,你就不应该使用汇编。”在您完全实现了自己的需求之后,广泛地分析了其性能并确定了精确的瓶颈,并尝试了几种替代解决方案,然后您可以开始来考虑使用汇编。如果您在拥有一个工作且广泛分析的程序之前编写了一行程序集,那么您就犯了一个错误。

答案 6 :(得分:1)

如果你需要问你而不需要它。