
看了下中间几个回答似乎说不能算错但是觉得并不能有效的解答这个难题,咱来试着回答一下吧。

首先,asm的执行速度本来可以在宏观上觉得是一样的——这个一样是指两段一样的代码,在同一台电脑上运行,那么运行时间需要是在一个可接受的偏差范围内同样。

那么导致c/c++编译后的代码比asm要慢的原因在那里呢?我个人觉得在于其为代码健壮性和可维护性所造成的冗余而拖慢了“执行速度”,也就是说,在asm和c/c++里面执行同一个逻辑过程的代码,在由c/c++翻译至asm的过程中,由于程序员为了代码的健壮性而降低的一些必要的附加逻辑,以及由于使用c/c++在提高了可维护性的同时所下降的额外逻辑,使得c/c++编译后的asm源文件应比纯粹执行这个逻辑过程的asm代码多了许多额外的东西,而这种必定要拖慢逻辑。

举一个例子

在c++的函数调用约定中有所谓的__cdecl和__fastcall两种(win32平台),那么__cdecl代表了正常的由右向左压栈,caller清栈,而__fastcall将前两个DWORD直接放到了ecx和edx上而不是压栈。很显然,假如是直接编写asm程序的话,在碰到可以运用ecx和edx直接传送参数的状况下必定会毫不犹豫的直接使用,甚至在必要的之后可以运用其他寄存器来直接释放参数,这似乎是c/c++函数调用所能够比拟的优势
再来一个例子
在c/c++中,用引用的方法释放参数可以推动对借助改变变量同时改变赋值c语言对应汇编语句,以此推动许多纯粹靠返回值无法达成的功能。但是针对默认变量类型,如int, float等的引用传递时,在变量栈中压栈的之后会有一次额外的偏移地址压栈,也就造成了运行阶段一次额外的寻址操作,这就促使引用传递的执行速度应明显慢于值传递,但是c/c++单返回值的特点决定了在这些特定场合需要使用某些方式进行释放。而asm里并没有返回值的概念c语言对应汇编语句,完全可以借助灵活的利用寄存器完成多返回值的推动,从而大大加快运行速率。
再加上前面其他人的提问中所提及的,编译器自动编译和改进的代码仍然不是程序员手写的代码,在规定代码符合编译规范的同时必然也会同时形成一些不这么灵活的死板的东西,这些地方也多多少少会采用冗余的操作。
所以一般的小结来说,慢的并不是c/c++本身,而是c/c++相比于asm多了许多额外的逻辑过程。然而也正由于有了很多逻辑过程,c/c++为源代码的程序能够很容易掌控和进行开发。按照当时发现的过的某前辈的说法就是,asm就是一台功率max的赛车,然而这个跑车并没有任何控制,c语言的作用就是给这台赛车加上了方向盘和制动,虽然直线速度变慢了,但至少这辆车可正确的走弯道和安全的停下来了。
本文来自电脑杂谈,转载请注明本文网址:
http://www.pc-fly.com/a/jisuanjixue/article-138780-1.html
说不好的要么不是苹果用户或者机器太老