有没有在 32 x86 机器上使用 64 位整数的快速方法(在 c 语言编译器中)?
int
不保证为 64 位宽;它保证至少为 16 位宽。如果您想要一种保证至少 64 位宽的类型,请long long
改用。在这个级别上谈论优化是毫无结果的。您最好提出一个完整的解决方案,对其进行分析以确定解决方案中最慢的部分是什么,并针对您的代码的那部分进行优化,或者选择一种更快地执行该慢操作的不同算法。注意:通过解决方案,我的意思是“解决实际问题的程序”。
32 位 x86 在一定程度上支持 64 位操作(旧的 mmx 中可能有一些 movq 指令和一些其他命令),但是如何从 c 中使用它?
您的编译器是否自动执行您提到的 movq 和/或 mmx 优化是值得怀疑的,因为您没有告诉我们您正在使用哪个编译器。但是,考虑到与其他优化相比这种优化的简单性(例如死代码优化、尾调用优化,甚至循环展开),我猜你的编译器会自动执行它。这是在这个级别谈论优化没有结果的另一个原因。编写编译器的人通常是非常优秀的程序员,对算法有深刻的理解,可以编写自动机来轻松执行简单的优化。
如果有人想在 32 位 x86 机器上使用 c 中的 64 位整数算术怎么办 - 如何最简单有效地做到这一点?
您是否尝试过编译完全优化的测试用例并movq
在其机器代码中查找操作?如果我没有说服您应该分析您的代码以确定这是否真的值得作为目标,那么请执行以下操作:编译您的解决方案(解决问题的东西,记住......并编译为“完全优化”) ,对其进行基准测试,以便您有一些东西可以衡量您的优化,将机器代码转换为汇编,在汇编中执行任何手动优化,重新编译并再次进行基准测试。你可能会:
- 花一周时间寻找优化和基准测试,发现您已经减少了几微秒并放弃了......这将很好地表明您的编译器花费了几秒钟来生成与您需要几周的代码一样好的代码来写。保留编译器,但放弃微优化。
- 找到编译器没有执行的重要优化(不太可能)。要么选择一个更优化的编译器,要么与编写编译器的人联系,并向他们解释......
不管怎样,进步!