我正在开发非交互式cpu绑定应用程序,它只进行计算,几乎没有IO.目前它的工作时间太长,而我正在努力改进算法,我也认为它可以为改变语言或平台带来任何好处.目前,在使用英特尔C++编译器编译的Windows上,它是C++(没有OOP,因此它几乎是C).可以切换到ASM帮助和多少?可以切换到Linux和GCC帮助吗?
为了彻底:首先要做的是收集配置文件数据,第二件事要考虑你的算法.我相信你知道这一点,但他们必须在任何性能编程讨论中加入#included.
直接问你的问题"可以切换到ASM帮助吗?" 答案是"如果你不知道答案,那么可能不会." 除非您非常熟悉CPU架构及其细节,否则您的代码不可能比优化的C/C++编译器好得多.
接下来要说明的是,代码中的显着加速(除了算法改进之外)几乎肯定会来自并行性,而不是线性增长.桌面计算机现在可以在一项任务中投入4或8个核心,这比稍微好一点的代码生成器具有更多的性能潜力.由于您对C/C++感到满意,OpenMP几乎是不费吹灰之力的.它很容易用来并行化你的循环(显然,你必须观察循环携带的依赖,但它肯定是"最简单的并行可能工作").
说了这么多,代码生成质量确实在C/C++编译器之间有所不同.英特尔C++编译器因其优化质量而备受推崇,并且不仅完全支持OpenMP,还支持其他技术,如线程构建模块.
回到什么编程语言可能比C++更好的问题,答案是"编程语言,积极促进/促进并行和并发编程的概念." 在这方面,Erlang是球的美女,现在是一种"热门"语言,大多数对性能编程感兴趣的人都至少对它有所关注,所以如果你想提高你在这方面的技能,你可能会想看看.
它始终是算法,很少是语言.这是我的线索:"我正在努力改进算法".
调整可能还不够.
考虑对算法进行彻底的改变.你必须消除处理,而不是让处理更快.罪魁祸首通常是"搜索" - 循环查找数据.找到消除搜索的方法.如果你无法消除它,用某种树搜索或某种哈希映射替换线性搜索.
切换到ASM不会有太大帮助,除非你非常擅长和/或有一个特定的关键路径例程,你知道你可以做得更好.正如几位人士所说,现代编译器在大多数情况下利用缓存等优势更好.比任何人都可以手工做.
我建议:
尝试使用其他编译器和/或不同的优化选项
运行代码覆盖/分析实用程序,找出关键路径的位置,并在代码中优化它们
C++应该能够为您提供非常接近代码的最佳性能,因此我不建议您切换语言.根据应用程序的不同,您可以使用多个线程在多代码/处理器系统上获得更好的性能,这是另一个建议.