- 主题:Cortex-M3平台下GCC编译器相比AC6编译器差距明显
最近给之前测试Dhrystone的代码增加了GCC的Makefile,刚好对比一下AC6和GCC的编译
结果
测试平台:GD32F103C8T6,Cortex-M3核心,8M主频。测试代码除了startup文件以外完
全相同。
编译器版本分别为:GCC v9.2.1和AC6 v6.13.1
测试结果如下:
GCC -Os面积优化,代码尺寸11136字节,运行时间115.5ms
AC6 -Oz面积优化,代码尺寸8536字节,运行时间64.88ms
GCC -O3速度优化,代码尺寸15484字节,运行时间67.89ms
AC6 -O3速度优化,代码尺寸16976字节,运行时间45.92ms
如果优化目标是代码体积,那么如11136/8536=1.305,115.5/64.88=1.779,GCC体积大
了三成,速度慢了近八成。
如果优化目标是执行速度,那么67.89/45.92=1.478,GCC速度慢了近五成,体积倒是小
了9%左右。
AC6的面积优化执行速度比GCC的速度优化还要快一点。
此外GCC都是开了`-fdata-sections -ffunction-sections -Wl,--gc-sections`选项的
,否则面积优化和速度优化GCC代码体积分别是19376和26448字节。分别还要增加七成。
从测试结果来看,都是AC6明显占优。
--
FROM 36.45.172.*
好!
【 在 spadger (echo) 的大作中提到: 】
: 最近给之前测试Dhrystone的代码增加了GCC的Makefile,刚好对比一下AC6和GCC的编译
: 结果
: 测试平台:GD32F103C8T6,Cortex-M3核心,8M主频。测试代码除了startup文件以外完
: ...................
--
FROM 114.87.232.*
我对这种测试免费产品和付费产品性能差距,而且知道很多编译后缀的大神都是很敬佩的。
【 在 spadger 的大作中提到: 】
: 最近给之前测试Dhrystone的代码增加了GCC的Makefile,刚好对比一下AC6和GCC的编译
: 结果
: 测试平台:GD32F103C8T6,Cortex-M3核心,8M主频。测试代码除了startup文件以外完
: ...................
--
FROM 180.116.239.*
我对这种对付费生产力工具强大性能表示惊讶的大神也是很敬佩的
【 在 feiy 的大作中提到: 】
: 相差7成这么大? 一般相差1-2成,我就受不了了。
: 毕竟两个编译器的优化等级,并不完全等效,即使都是等同的-O3,也不一定完全等效,
: 所以,得到的性能表现可能会有一些差异。我的经验认为这种差异(这种因为编译选项
: ...................
--
FROM 180.116.239.*
因为工作后我要么AC5/6,要么撸汇编,gcc我是不碰的,不过大学时候我撸过一阵子gcc,其实所有代码大小和速度的问题,在gcc上都可以归结为中断时候堆栈的push和pop问题,你去看看就知道了,普通的函数两种编译器做成的汇编差别不大
【 在 spadger 的大作中提到: 】
: 最近给之前测试Dhrystone的代码增加了GCC的Makefile,刚好对比一下AC6和GCC的编译
: 结果
: 测试平台:GD32F103C8T6,Cortex-M3核心,8M主频。测试代码除了startup文件以外完
: ...................
--
FROM 180.116.239.*
所以我建议你写个hello world,分别用AC6和gcc测试一下大小和速度,然后弄个RTOS,测试一下大小和速度
【 在 spadger 的大作中提到: 】
: 最近给之前测试Dhrystone的代码增加了GCC的Makefile,刚好对比一下AC6和GCC的编译
: 结果
: 测试平台:GD32F103C8T6,Cortex-M3核心,8M主频。测试代码除了startup文件以外完
: ...................
--
FROM 180.116.239.*
我其实不大关心性能,8M开始,不够就提高一点,大多数应用频率都远低于器件的最高
频率。
我比较在意的是代码密度,毕竟代码越小就能用更便宜的器件。
顺便请教如何在GCC下进一步减小代码尺寸。
【 在 feiy (null) 的大作中提到: 】
: 相差7成这么大? 一般相差1-2成,我就受不了了。
: 毕竟两个编译器的优化等级,并不完全等效,即使都是等同的-O3,也不一定完全等效,
: 所以,得到的性能表现可能会有一些差异。我的经验认为这种差异(这种因为编译选项
: ...................
--
FROM 111.18.44.*
__ASM()
【 在 spadger 的大作中提到: 】
: 我其实不大关心性能,8M开始,不够就提高一点,大多数应用频率都远低于器件的最高
: 频率。
: 我比较在意的是代码密度,毕竟代码越小就能用更便宜的器件。
: ...................
--
FROM 180.116.239.*
折算一下DMIPS/MHz?
快这么多的话, 超过官宣的1.25DMIPS/MHz了吧
【 在 spadger (echo) 的大作中提到: 】
最近给之前测试Dhrystone的代码增加了GCC的Makefile,刚好对比一下AC6和GCC的编译
结果
测试平台:GD32F103C8T6,Cortex-M3核心,8M主频。测试代码除了startup文件以外完
全相同。
编译器版本分别为:GCC v9.2.1和AC6 v6.13.1
测试结果如下:
GCC -Os面积优化,代码尺寸11136字节,运行时间115.5ms
AC6 -Oz面积优化,代码尺寸8536字节,运行时间64.88ms
GCC -O3速度优化,代码尺寸15484字节,运行时间67.89ms
AC6 -O3速度优化,代码尺寸16976字节,运行时间45.92ms
如果优化目标是代码体积,那么如11136/8536=1.305,115.5/64.88=1.779,GCC体积大
了三成,速度慢了近八成。
如果优化目标是执行速度,那么67.89/45.92=1.478,GCC速度慢了近五成,体积倒是小
了9%左右。
AC6的面积优化执行速度比GCC的速度优化还要快一点。
此外GCC都是开了`-fdata-sections -ffunction-sections -Wl,--gc-sections`选项的
,否则面积优化和速度优化GCC代码体积分别是19376和26448字节。分别还要增加七成。
从测试结果来看,都是AC6明显占优。
--
FROM 107.6.246.*
编译选项加 -ffunction-sections -fdata-sections
链接选项加 -Wl,--gc-sections
这是必须的
链接选项加-specs=nano.specs, 能省一点点
-flto, 链接时跨文件优化, 能再小一点快一点, 不过编译链接速度慢一点
【 在 spadger (echo) 的大作中提到: 】
我其实不大关心性能,8M开始,不够就提高一点,大多数应用频率都远低于器件的最高
频率。
我比较在意的是代码密度,毕竟代码越小就能用更便宜的器件。
顺便请教如何在GCC下进一步减小代码尺寸。
【 在 feiy (null) 的大作中提到: 】
: 相差7成这么大? 一般相差1-2成,我就受不了了。
: 毕竟两个编译器的优化等级,并不完全等效,即使都是等同的-O3,也不一定完全等效,
: 所以,得到的性能表现可能会有一些差异。我的经验认为这种差异(这种因为编译选项
: ...................
--
FROM 107.6.246.*