|
|
1
6
如果您的手工编写的代码与编译后的函数相当,那么请确保它们的大小相似,它们正在做同样的事情,如果您可以与编译器竞争,那么您将是相同或相似的。 现在,您的文件大小表明您看到的都是错误的东西。您正在查看的名为二进制文件的文件中有大量其他内容。在这个上下文中,您想比较各个苹果,然后比较函数的大小、机器代码,而不是保存函数的容器的大小加上调试信息加上字符串再加上其他一些东西。 你的实验有缺陷,但结果很粗略地表明了预期的结果。但如果您以相同的方式生成代码,则会出现这种情况。这种可能性很小,所以说不,除非以相同的方式生成代码,否则不应该期望类似的结果。 以这个简单的函数为例
同一编译器生成了以下内容:
还有这个
因为设置不同。13条指令比3条指令大4倍以上。 一个人可能直接从C生成这个,没什么特别的
从操作顺序来看,不确定在将金额添加到a之前,您是否必须将1添加到b。或者,如果这无关紧要。我从左到右,编译器从右到左。 因此,您可以说编译器和我的程序集生成的二进制字节数相同,或者您可以说编译器生成的二进制字节数是我的4倍以上。 将以上内容扩展到一个真正的程序中,可以做一些有用的事情。 向读者进行练习(OP,请不要破坏它),找出为什么编译器可以生成两个大小如此不同的正确解决方案。 编辑 .exe、elf和其他提到的“二进制”格式可以包含调试信息,ascii字符串包含函数/标签的名称,这些名称构成了漂亮的调试屏幕。它们是“二进制”的一部分,因为它们是行李的一部分,但不是执行该程序时使用的机器代码或数据,至少不是我提到的东西。您可以在不更改程序所需的机器代码或数据的情况下,操纵程序的大小。exe或使用编译器设置的其他文件格式,因此相同的编译器汇编器链接器或汇编器链接器路径可以通过包含或不包含此附加行李,使二进制文件在该单词的某些意义上变大或变小。因此,这是理解文件大小的一部分,也是为什么即使您的hello world程序大小不同,但如果一个文件长10个字节,而另一个文件长10个字节,那么整个文件的大小可能大致相同。exe为40K,则噪声中有10个字节。但如果我理解你的问题,那么10个字节就是你感兴趣的,你想知道编译的C和手写的C之间的比较。 还要注意的是,编译器是由人类制造的,因此它们产生的输出与这些人所能产生的结果相当,其他人可以做得更好,许多人做得更差,这取决于你对更好和更差的定义。 |
|
2
5
绝对大小为39+Kb,与编译器和使用的语言无关( c/c++ 或 asm公司 )不同的优化、调试信息等可以改变这个微小代码的大小,比如1000字节。但不是更多。i用于测试构建下一个程序
链接器选项:
并为x86/x64获取大小为2560字节的exe。
有什么不同?在里面
由静态链接的c运行时提供的剩余35kb以上的大小。即使您在asm上编写程序,也需要使用一些lib来链接
任务不是c++与asm-这里没有什么不同。任务正在使用c-runtime或未使用 |
|
|
3
4
我同意old\u time,但我也做了一个快速测试,以了解地面真相。使用VS-2017 Pro,我在可执行文件的大小上得到了类似的结果(约37KB),但只有在查看debug output文件夹的情况下。在构建发布版之后,它的大小接近9KB。这种差异主要在于调用OS/C运行时DLL所需的静态库的大小。 编辑:尽管大多数现代C编译器可以匹配或优于大多数手工编写的汇编代码,但手工编写的种类可以更小,因为它不需要所有的C运行时,但这种差异很少足以保证汇编代码的额外开发和维护成本,特别是对于非平凡的应用程序。有一个原因是,大多数现代操作系统内核主要是用C或其他高级语言编写的,只有少数关键函数中的针孔汇编优化。 普通的“hello world”类程序对于C和汇编程序来说不是一个很好的比较。编译器或人类没有足够的机会在优化方面做很多工作。编写一个数学或数据处理库和应用程序,并进行比较。我敢打赌编译器会踢你的,但是。 |