我不了解 iPhone,但是说拇指比 ARM 慢的笼统说法根本不正确。给定 32 位宽的零等待状态内存,拇指会慢一些,比如 5% 或 10%。现在如果是thumb2那就另当别论了,据说thumb2可以跑得更快,我不知道iPhone有什么我的猜测是它不是thumb2。
如果您没有用完零等待状态的 32 位内存,那么您的结果会有所不同。一件大事是 32 位宽的内存。如果您在像 GameBoy Advance 系列这样的 16 位宽总线上运行,并且在该内存或 ROM 上有一些等待状态,那么即使执行相同任务需要更多的拇指指令,拇指也可以轻松超越运行 ARM。
测试你的代码!发明一个提供您感兴趣或不感兴趣的结果的测试并不难。显示手臂吹走拇指就像拇指吹走手臂一样容易。谁在乎 dhrystones 是什么,重要的是它今天运行您的代码的速度有多快。
多年来我在测试 ARM 代码性能时发现,您的代码和编译器是最重要的因素。因此,thumb 在理论上慢了几个百分点,因为它使用更多的指令来执行相同的任务。但是您是否知道您最喜欢的编译器可能很糟糕,通过简单地切换编译器您可以运行速度快几倍(gcc 属于该类别)?或者使用相同的编译器并混合优化选项。无论哪种方式,您都可以通过聪明地使用工具来掩盖手臂/拇指的差异。您可能知道这一点,但您会惊讶地知道有多少人认为他们知道如何编译代码的一种方法是唯一的方法,而获得更好性能的唯一方法就是在问题上投入更多的内存或其他硬件。
如果您使用的是 iPhone,我听说那些人正在使用 LLVM?我在很多方面都喜欢 llvm 概念,并渴望在它成熟时将其用作我的日常驱动程序,但发现它生成的代码对于我正在执行的特定任务来说要慢 10-20%(或更多)。我处于手臂模式,我没有尝试拇指模式,并且我有一个 l1 和 l2 缓存。如果我在没有缓存的情况下进行测试以真正比较拇指和手臂,我可能会看到拇指慢几个百分点,但如果你考虑一下(当时我对此并不感兴趣),你可以缓存两倍于手臂代码的拇指代码可能意味着即使任务的整体代码增加了几个百分点,通过缓存更多的代码并减少平均获取时间拇指可以明显更快。我可能得去试试。
如果您使用的是 llvm,那么您还有另一个问题是要在多个地方执行优化。从 C 到可以优化的字节码,然后可以优化字节码本身,然后可以合并所有字节码并整体优化,然后从字节码到汇编程序时可以优化。如果您只有 3 个源文件,并假设每个机会只有两个优化级别,即不优化或不优化的级别,使用 gcc 您将有 8 个组合进行测试,使用 llvm 的实验数量几乎高出一个数量级. 比你真正能跑的多,成百上千。对于我正在运行的一项测试,不在 C 到字节码的步骤上进行优化,然后在单独时不优化字节码,而是在将字节码文件合并为一个大(ger)文件后进行优化。
底线...测试,测试,测试。
编辑:
我一直在使用字节码这个词,我认为正确的术语是 LLVM 世界中的位码。.bc 文件中的代码就是我的意思...
如果您使用 LLVM 从 C 转到 ARM,则中间有位码 (bc)。有用于优化 C 到 bc 步骤的命令行选项。一旦 bc 您可以优化每个文件,bc 到 bc。如果您选择,您可以将两个或多个 bc 文件合并为更大的 bc 文件,或者将所有文件合并为一个大 bc 文件。然后也可以优化这些组合文件中的每一个。
我的理论,到目前为止只有几个测试用例,如果你不做任何优化,直到你把整个程序/项目放在一个大的 bc 文件中,优化器就拥有最大数量的信息做它的工作。所以这意味着从 C 到 bc 没有优化。然后将所有 bc 文件合并为一个大 bc 文件。一旦你把整个事情变成一个大的 bc 文件,然后让优化器执行它的优化步骤,最大化信息并希望优化质量。然后从优化的 bc 文件转到 ARM 汇编程序。llc 的默认设置是启用优化,您确实希望允许该优化,因为它是知道如何针对目标进行优化的唯一步骤。bc 到 bc 优化是通用的,而不是特定于目标的 (AFAIK)。
你仍然需要测试、测试、测试。继续尝试步骤之间的优化,看看它是否会使您的程序运行得更快或更慢。