Arm vs X86的论文

碎梦刀

x86做移动芯片真不行？为Intel“平反”
http://news.mydrivers.com/1/257/257076.htm

T神说的论文就是这篇报道里的内容吧。能在IEEE高性能计算机架构国际研讨会上发表的研究报告应该具有一定的份量和严谨性。
一直以来PCI里的争论大都具有一定的技术含量，当年酷睿出世时的论辩，近来ARM与intel孰优孰劣的争论。
只是唯心论者是永远也辩不倒的，与其谩骂不如静看arm与intel未来1-5年间的发展。

YsMilan

Tempestglen 发表于 2013-3-12 16:44
单线程ipc，A8接近于A9，A9等于atom。

atom不就是借着当年dec的超线程技术实现了1c2t来对抗A9的2c2t ...

T神不是神喻过我等，超线程无用么?

YsMilan

x86上叫放弃半壁江山
Arm上就叫性能立马暴涨...

the_god_of_pig

Tempestglen 发表于 2013-3-12 16:44
单线程ipc，A8接近于A9，A9等于atom。

atom不就是借着当年dec的超线程技术实现了1c2t来对抗A9的2c2t ...

发什么梦，atom是顺序的所以超线程才能提升大，Core是乱序HT也就提升10%，你要YY ARM上SMT只能等A57的儿子，手机上ARM能不能活到那个时候都是问题

YsMilan

等A15出来.
等A57出来..
等xxG的Axx出来...
等丹佛出来....
等解决了chrome的优化问题...
等xx工艺出来...
最新：等Arm启用超线程

foolme

largewc 发表于 2013-3-12 13:45
arm最恶心的是最早的标准居然没有32位赋值，直到thumb-2才支持，两条指令做一个32位赋值，而且见鬼的安卓 ...

今天看到CM10.1的nightly开始默认启用armeabi-v7a了，应该是默认启用了neon和thumb-2
另外，arm的指令集系统不是有两套吗？为什么一定要用thumb子集呢？
完全使用arm指令集不就行了吗？
毕竟thumb指令集是针对指令密度要求比较高的嵌入式环境的
应该ios、android、wp8之类的系统不需要考虑用thumb指令集吧。

PS：本人不会汇编，arm架构也不清楚，只是外行的看法。

largewc

foolme 发表于 2013-3-12 17:45
今天看到CM10.1的nightly开始默认启用armeabi-v7a了，应该是默认启用了neon和thumb-2
另外，arm的指令集 ...

标准arm指令效率更低，再写一遍吧，标准arm，比如说int a = 12345678;

x86一条mov a,0小2345678的事情

编译的结果一定是

:start
ldr r0,[+0];//取得memroy偏移的内容
b next      //跳下去继续执行
:memery
0x12345678
:next


因为arm或者thumb-2都是32位固定长度指令，所以肯定无法一条指令进行足够的32bit赋值，至少需要两条，而thumb-2就是有专门的两个，一个是给高16bit赋值，一个是给地16bit赋值，两条可以进行一个赋值。

对于c++原生开发来说，是必要的，ios从4.0开始，强制了thumb-2，其实就是iphone 3gs以后才能升级，之前不允许了。xcode默认也是thumb-2

wp来说，也是如此，thumb-2是默认选项，没有疑问。

安卓由于兼容性考虑，老的armv11之类还有在用的吧，所以ndk默认是thumb

这跟系统没关系，是每一个原生软件的问题，比如说游戏，播放器，导航之类，都是原生程序。

largewc

还有的事，标准的arm，比如说堆栈内临时变量，一般采用堆栈寄存器加偏移地址来实现的。
void test()
{
...
..

int b = i;//这样的访问,b假如代码很长，临时变量很多，或者有一个数组的临时变量，超过了一个长度（貌似是4000字节左右的，具体忘了）
}

对于x86，那就是mov eax,[ebp+0x很长的偏移;假设

而arm则不行，因为ldr r0,r15,0x很长偏移；这里的很长偏移超过一定长度，超过了32bit指令的描述范围，单挑指令就不行了

所以结果就成了，刚才那个32bit赋值，付给了r1之类，然后再用ldr r0,r0,r1来实现。


thumb-2的话，则略好点，首先是thumb-2版本的ldr宽度变宽了，支持一些压缩数据算法，其次就是即使宽度不够了，需要的指令数量也远远少于arm本身指令。


thumb-2以后，arm的性能才稍微可以看看，标准arm就算了。

安卓其实早该统一下标准淘汰老的armv11之类的cpu算了。

Prescott

foolme 发表于 2013-3-12 17:45
今天看到CM10.1的nightly开始默认启用armeabi-v7a了，应该是默认启用了neon和thumb-2
另外，arm的指令集 ...

ARM指令集有时候性能还不如Thumb-2。尤其是当ARM处理器的内存带宽有限的时候。
编译成Thumb-2指令集通常会减少30%左右的可执行文件大小，在内存带宽很小，缓存也很小的时候，反而提高性能（减少了从内存读取指令的大小，减少了指令占用的缓存大小）。

现在的高性能ARM，带宽也不算低了，应该影响不大了

不过Thumb-2真是讽刺，鼓吹定长RISC指令集的ARM，居然搞出一个变长的指令集出来。

largewc

Prescott 发表于 2013-3-12 18:25
ARM指令集有时候性能还不如Thumb-2。尤其是当ARM处理器的内存带宽有限的时候。
编译成Thumb-2指令集通常 ...

thumb-2也是定长的啊，汗

thumb-2主要是支持了一些压缩数据之类，增加了不少专有指令，弥补了arm本身的不足。

Prescott

largewc 发表于 2013-3-12 18:14
标准arm指令效率更低，再写一遍吧，标准arm，比如说int a = 12345678;

x86一条mov a,0小2345678的事情 ...

hehe，基本上就是因为RISC非要定长，所以一条指令只有32bit长，操作码寄存器占掉大部分，结果就是想写个稍微大点的常量到指令里就不行，哈哈。

给寄存器赋常量值，跳转，偏移量寻址等等，都受限

Prescott

largewc 发表于 2013-3-12 18:33
thumb-2也是定长的啊，汗

thumb-2主要是支持了一些压缩数据之类，增加了不少专有指令，弥补了arm本身的 ...

Thumb-2 is an enhancement to the 16-bit Thumb instruction set. It adds 32-bit instructions that can be freely intermixed with 16-bit instructions in a program. The additional 32-bit instructions enable Thumb-2 to cover the functionality of the ARM instruction set. The 32-bit instructions enable Thumb-2 to combine the code density of earlier versions of Thumb, with performance of the ARM instruction.
基本上，thumb-2比thumb增强的部分就是可以16bit指令和32bit指令混写。
原来的thumb指令只能是16位的，处理器需要一条指令(BX/BLX)在32bit的ARM模式和16bit的thumb模式之间切换，切换的开销倒不是很大，不到10个cycle。但是通常没人这么干过（碰巧我这么干过，连OS都要改才能跑）

largewc

Prescott 发表于 2013-3-12 18:37
Thumb-2 is an enhancement to the 16-bit Thumb instruction set. It adds 32-bit instructions that ca ...

arm跟thumb切换吧，必须代码地址偏移加一才能正常。

thumb-2比标准arm优化了些东西，应该算是cisc化增强吧，当然不排除为了弥补arm先天问题，继续增加thumb-3指令，不过整个产业链是否可以接受折腾就不知道了。

我自己有一个语言编译器，jit搞过x86和arm，对arm较熟悉，arm其实性能感觉比当初奔三啥的强，很大的因素就是gpu，现在的操作系统对gpu优化到位了，当初p3是靠cpu傻跑的

foolme

largewc 发表于 2013-3-12 18:14
标准arm指令效率更低，再写一遍吧，标准arm，比如说int a = 12345678;

x86一条mov a,0小2345678的事情 ...

专门查了一下C语言的标准。因为C语言通常采用一段地址专门储存常量，所以情况可能有些出入
以你的例子，int a=0x12345678
如果是C编译器生成的指令的话，应该是
ARM:
mov r1,=addr of 0x12345678
ldr r0,[r1]
x86:
mov EBX, addr pf 0x12345678
mov EAX, [EBX]
因此两者开销相差不多。
就算是如同你的例子，我也没觉得有什么问题，
原因有几点：
1.内存是8位宽度为基础的。对于CPU来说无论是x86还是arm，数据都还是一个个的读到CPU里的。如果说什么预取技术之类的那么大家都一样有。而且以arm来说由于指令对齐。预取效率说不定更高。
2.对于CPU来说，实现一个操作不是看汇编的，而是看机器码的，并不是说汇编指令少就一定执行的快。以你的例子我认为机器码所占空间相差不大。x86在这方面只不过占了阅读和书写的便宜。
3。现在除了一些特定场合外，应该没有什么必要用汇编来写程序了吧。实际上有研究表明手工优化的汇编并不比C语言编译出来的代码执行效率更优秀。
另外CM10.1今天开始就是默认用armeabi-v7a来编译系统，只不过仍然保留armeabi的运行库。
希望以后的程序都采用这个标准吧。

总而言之，我认为指令集的差别并不会太影响cpu性能。差别主要在硬件实现上

一家之言，请多指教

largewc

foolme 发表于 2013-3-12 20:46
专门查了一下C语言的标准。因为C语言通常采用一段地址专门储存常量，所以情况可能有些出入
以你的例子， ...

我跟你说，mov r1,=addr of 0x12345678这个指令不成立，因为arm就是32bit的，光0x12345678就有32bit，指令码要放在哪里？你去找编译器写段试试，然后反编译看看就知道了。


你以为是动长的x86？mov eax,0x12345678可以用六个字节来表示？

定长的arm指令，操作数受限的问题，有一堆麻烦事，夺取看看再说吧。


长度怎么不重要，你的解码，运行都是需要周期的。还是那个东西，多写写汇编就懂了。


指令怎么不重要，很简单的问题a7 a15有除法指令，a8 a9没有的，你去测试一下真机除法的效率吧，测试一下你再说结论吧。


至于汇编优化的问题，这个意思就是，大部分人对cpu的理解来看，你写还不如编译器优化懂得多，因为你不理解cpu原理的话，很可能你写出来的代码比原来的代码效率还低。



最简单的，说个难听的，02年一家老牌的游戏公司，在做2d alpha blend的时候，当时是没有gpu加速的，他们采用的办法居然是把加法改成了查表……

好吧，内存操作要浪费的时间远比cpu运算高多了。

largewc

而且你的这段代码的意思相当于 int a = *(int*)0x12345678;

这个代码用x86就是mov eax,dword ptr[0x12345678];一条指令

用arm，最优化的thumb-2，也需要
movw r1,0x1234;
movt r1,0x5678;
ldr r0,r1
三条指令，你的那个汇编指令mov r1,=0x12345678在编译过程中，翻译成thumb-2机器码结果就是我写的这段代码。arm编译器支持部分伪代码，就是为了让你看起来方便，合并了一些指令，但是实质是很多条。

如果用arm标准指令最低是四条，如果指令集真的没用的话，thumb-2，为什么要加入movw和movt来优化32位赋值呢，而且它仍然比不了动长的x86效率。


复杂指令的特点就是，x86那个指令是一个专用指令，它优化了效率。


-----------------------------
我说的就是机器码，其实无论是x86，还是arm，光一个mov，其实有很多不同的机器码的，机器码的数量比你看到的汇编指令多太多了，x86的特点就是足够的多，它考虑了各种情况，所以效率是最高的，但是编译器做起来也是最麻烦的，因为优化你要考虑太多的专有指令了。

arm虽然相对简单，但是thumb-2也增加了不少指令，不过它的效率仍然无法跟x86相比。

------------------------------

要说可读性，其实arm汇编读起来比x86简单太多了，x86编译器太复杂，代码可读性很差，更别说x86还有专门的代码混淆算法，因为变长指令通过非常规跳转可以让汇编代码完全不可被分析。

largewc

Prescott 发表于 2013-3-12 18:35
hehe，基本上就是因为RISC非要定长，所以一条指令只有32bit长，操作码寄存器占掉大部分，结果就是想写个稍 ...

是啊是啊，而且见鬼的arm很多指令都是三操作数的，也就是add r1,r2,r3这种格式
--------------------------
arm并且还有16个常规寄存器，也就是每个寄存器是4位的，add r1,r2,0x1234这样的话，除去指令码的16bit 两个寄存器的8 bit，还有标志位啥啥的2-3bit，留给操作数的往往只有5-7bit了，操作数最大不能超过127的太多了……
--------------------------
更正一下，查了一下资料，add之类的指令码占10bit 寄存器两个8 bit 标志位3bit，留给操作码有11bit，也就是最大不能超过2048，加上标志位的正负判定，也就是4096最大范围，这个是准确的。

如果操作数不够，就得拆成2b的mov r7,操作数啥啥的

怪不得arm需要16个寄存器，定长指令，如果寄存器不够拿来凑数的话，估计效率会坑死。

Prescott

foolme 发表于 2013-3-12 20:46
专门查了一下C语言的标准。因为C语言通常采用一段地址专门储存常量，所以情况可能有些出入
以你的例子， ...

mov r1,=addr of 0x12345678
ldr r0,[r1]

这个mov r1,=addr of 0x12345678还是回到了第一个问题，因为addr of var实际上也是个常量。
ARM可以这样干:
ldr    r0, [pc, offset]，不过offset的范围只有4096

foolme

Prescott 发表于 2013-3-12 21:27
mov r1,=addr of 0x12345678
ldr r0,[r1]

就是这个意思，即间接寻址，addr of var是个常量，
但是编译后一般这个地址有可能是由一个基地址+变量组成。
我不太清楚arm的地址空间有多大，但是x86也有段地址+偏移量的寻址方法。arm难道没有吗？
有没有可能用一个指令完成地址加载呢。

如果说arm一定要用立即数的方式的话，就像largewc所写的
movw r0,0x1234
movt r0,0x5678
不就解决问题了？
实际代码长度是多少呢？和x86比起来呢？

另外 largewc
我的意思C编译器出来的机器码x86的机器码长度和arm有可能是一样的。
另外除法指令是有与没有的区别，当然很大，但是实现同样功能的指令集性能就相差不会太远吧？
arm官方的说法是thumb-2的性能是arm标准指令集的98%，实际上任何稍微差些的程序结构就会把这2%的性能给挥霍掉了。