我一直在努力同时实现 Dixon 的算法,但结果很差。对于 <~40 位的小数字,它的运行时间大约是我班级中其他实现的两倍,并且在大约 40 位之后,需要更长的时间。
我已尽我所能,但我担心它有一些我找不到的致命问题。
我的代码(相当长)位于此处。理想情况下,该算法将比非并发实现运行得更快。
我一直在努力同时实现 Dixon 的算法,但结果很差。对于 <~40 位的小数字,它的运行时间大约是我班级中其他实现的两倍,并且在大约 40 位之后,需要更长的时间。
我已尽我所能,但我担心它有一些我找不到的致命问题。
我的代码(相当长)位于此处。理想情况下,该算法将比非并发实现运行得更快。
为什么你会认为它会更快?启动线程并添加同步调用是巨大的时间同步。如果你无法避免 synchronized 关键字,我强烈推荐使用单线程解决方案。
您可以通过各种方式避免它们 - 例如,通过确保给定变量仅由一个线程编写,即使由其他线程读取,或者通过像函数式语言一样操作并使用 Recursion 变量存储使所有变量最终化(不确定,很难想象这会加速任何事情)。
但是,如果您真的需要快速,我最近确实从我自己尝试寻找快速解决方案的尝试中发现了一些非常违反直觉的事情......
我已经能够直觉的是,编译器在优化方面非常聪明,并且可以优化“理想”java代码。静态方法远非理想——它们是一种反模式……是最理想的模式之一。
我建议你编写最清晰、最好的 OO 代码,作为参考,它实际上可以正确运行——然后计时并开始尝试调整以加快速度。