比较IAR，MDK的AC5和AC6以及Embedded Studio的CLANG和GCC编译HAL库性能

Eric2013 · 发表于 2019-3-28 19:24:11

本帖最后由 Eric2013 于 2019-3-30 14:44 编辑

MDK AC5(ARM Compiler5)编译STM32H7的HAL库带Browse Info时速度巨卡，电脑性能稍差点，编译个大点的工程能编译出几十分钟。

测试条件：
1、IAR8.30开最高等级的最小代码优化
2、MDK5.27正式版使用AC5开最高等级优化3
3、MDK5.27正式版使用AC6开最小代码优化
4、Embedded Studio4.15 beta版使用GCC开最高等级代码大小优化
5、Embedded Studio4.15 beta版使用CLANG开最高等级代码大小优化
6、全部开启多核并行编译
7、电脑配置是i3-3220，机械硬盘
8、暂未测试芯片实际执行性能。

注意，现在MDK的AC6和IAR打开后都会主动创建Browse Info，在窗口的最下方正中间有个提示。
MDK标识，要等待标识消失才可以使用go to def

IAR标识，要等到进度条到头才可以使用go to def

提供一个STM32H7的例程供大家测评：

先测试编译时间：
MDK5使用AC5带Browse Info
耗时8分51秒

MDK5使用AC6带Browse Info
耗时1分07秒

IAR带Browse Info（IAR的编译速度很快，等Browse Info时间较长）
耗时2分03秒

Embedded Studio4.15使用GCC带Browse Info
耗时38秒

Embedded Studio4.15使用CLANG带Browse Info
耗时21秒

总结，Embedded Studio使用CLANG完胜其它方式。

生成代码大小
MDK5使用AC5：
Total RO  Size (Code + RO Data)                   17060 (16.66kB)
Total RW  Size (RW Data + ZI Data)                6536 (  6.38kB)
Total ROM Size (Code + RO Data + RW Data)  17120 (16.72kB)

MDK5使用AC6：
Total RO  Size (Code + RO Data)                   15960 (15.59kB)
Total RW  Size (RW Data + ZI Data)                6544 (  6.39kB)
Total ROM Size (Code + RO Data + RW Data)  15980 (15.61kB)

MDK5使用AC6，开启Link-Time优化（2019-03-29，晚11点）。
Total RO  Size (Code + RO Data)             11476 (  11.21kB)
Total RW  Size (RW Data + ZI Data)             6512 ( 6.36kB)
Total ROM Size (Code + RO Data + RW Data) 11484 (  11.21kB)

IAR（printf选择full）：
20 290 bytes of readonly  code memory
142 bytes of readonly  data memory
6 677 bytes of readwrite data memory

IAR（开Link优化，printf选择small，新增small测试，2019-03-29，晚10点）：
16 734 bytes of readonly  code memory
   90 bytes of readonly  data memory
  6 621 bytes of readwrite data memory

Embedded Studio4.15使用GCC

Embedded Studio4.15使用CLANG

Embedded Studio4.15使用CLANG开Link-Time优化，效果明显（2019-03-30新增测试）

总结，MDK的AC6生成的代码最小。

现在MDK5的AC6也是用的CLANG，总的来说，无论是编译速度还是生成代码大小，CLANG都表现出巨大优势。

当前HAL库使用AC6编译的警告有点多，可以选择使用AC5的警告临时屏蔽，提供的测试例子是采用的这种方式。

另外使用中文也会有很多警告，所以干脆使用UTF-8编码，就没有警告了，不过程序中的打印有中文的话，串口助手要使用支持UTF-8的，比如SecureCRT即可。

Excellence · 发表于 2019-3-28 20:58:08

大傻师 · 发表于 2019-3-28 22:38:26

CLANG是专门的版本还是就是CLANG官网下的通用的版本？

security · 发表于 2019-3-28 23:16:48

这种比较，不错，谢谢分享！

hexenzhou · 发表于 2019-3-28 23:37:39

楼主又出神作了！！

zhcj66 · 发表于 2019-3-29 08:07:22

硬汉顶一下你的持之以恒的精神

altim_li · 发表于 2019-3-29 08:21:41

很不错的评测

xiaomu · 发表于 2019-3-29 08:26:54

clang看来是大趋势！

jiaowoxiaolu · 发表于 2019-3-29 08:43:48

AC6编译ST的旧外设库一堆报错，无奈啊，没有动力换HAL，感觉旧库用得习惯又顺手

XIVN1987 · 发表于 2019-3-29 09:03:16

一直听人说IAR编译生成的代码小，，没想到MDK强这么多，，之前都被误导了

感谢楼主这么详细的测评

jameszxj · 发表于 2019-3-29 10:20:52

AC5确实很慢，但AC6要消除一堆告警也挺麻烦的。
可能优化上还有一些坑要填，我就遇到过AC5编译能正常运行，换了AC6就挂的问题，后来把读写寄存器的函数换成了内嵌汇编就好了。

caixiuwen · 发表于 2019-3-29 21:17:46

总结，MDK的AC6生成的代码最小。

这个总结怕是有问题。我试了楼主提供的工程。MDK选用了MicroLIB，而IAR工程的库选项都是Full，IAR的链接器优化也没开。用的不同的库，怎么好直接比较最终生成的程序大小呢。这比的恐怕不是编译器吧。

应该直接看map文件比较
MDK AC6的结果：

Image component sizes
Code (inc. data) RO Data RW Data ZI Data Debug Object Name
426 16 0 0 0 6299 bsp.o
436 64 0 0 4 7210 bsp_fmc_io.o
634 20 64 0 173 7458 bsp_key.o
136 12 16 0 0 1308 bsp_led.o
612 68 63 0 76 15163 bsp_timer.o
978 80 35 0 2092 17140 bsp_uart_fifo.o
18 0 0 0 0 308 hardfaulthandler.o
720 284 1045 0 0 1503 main.o
248 56 0 0 68 3458 segger_hardfaulthandler.o
36 8 664 0 4096 960 startup_stm32h743xx.o
138 12 0 8 4 14390 stm32h7xx_hal.o
324 32 0 0 0 11816 stm32h7xx_hal_cortex.o
388 20 0 0 0 6601 stm32h7xx_hal_gpio.o
1796 48 0 0 0 9521 stm32h7xx_hal_rcc.o
2964 154 0 0 0 15072 stm32h7xx_hal_rcc_ex.o
102 4 0 0 0 8008 stm32h7xx_hal_sram.o
330 32 0 0 0 36501 stm32h7xx_hal_tim.o
1776 154 24 0 0 21172 stm32h7xx_hal_uart.o
14 0 0 0 0 862 stm32h7xx_it.o
320 12 0 0 0 9235 stm32h7xx_ll_fmc.o
100 16 16 8 0 4389 system_stm32h7xx.o
----------------------------------------------------------------------
12520 1092 1964 16 6524 198374 Object Totals
0 0 32 0 0 0 (incl. Generated)
24 0 5 0 11 0 (incl. Padding)

复制代码

IAR的结果

Module ro code ro data rw data
------ ------- ------- -------
HardFaultHandler.o 18
SEGGER_HardFaultHandler.o 32
bsp.o 482
bsp_fmc_io.o 472 4
bsp_key.o 680 176
bsp_led.o 148
bsp_timer.o 712 77
bsp_uart_fifo.o 1 024 2 092
main.o 1 756
startup_stm32h743xx.o 1 224
stm32h7xx_hal.o 142 7 12
stm32h7xx_hal_cortex.o 328
stm32h7xx_hal_gpio.o 504
stm32h7xx_hal_rcc.o 1 860
stm32h7xx_hal_rcc_ex.o 2 768
stm32h7xx_hal_sram.o 102
stm32h7xx_hal_tim.o 290
stm32h7xx_hal_uart.o 1 758
stm32h7xx_it.o 14
stm32h7xx_ll_fmc.o 272
system_stm32h7xx.o 120 5 8
----------------------------------------------------
Total: 14 706 12 2 369

复制代码

其中startup_stm32h743xx是汇编，应该去除（IAR开启连接器优化后，startup_stm32h743xx会变小）。
如果只比较这些代码的结果，RO Code和Data加在一起算的话，MDK是13784，IAR是13494。RW Data的话，MDK是2428，IAR是2369。
当然，这个例子也不能说明IAR生成的代码就小，仔细看每个文件的话，可以发现有的大有的小。。。但是差距不会很大。

caixiuwen · 发表于 2019-3-29 21:19:14

XIVN1987 发表于 2019-3-29 09:03
一直听人说IAR编译生成的代码小，，没想到MDK强这么多，，之前都被误导了

感谢楼主这么详细的测 ...

说不定现在也是被误导呢

Eric2013 · 发表于 2019-3-29 21:33:56

caixiuwen 发表于 2019-3-29 21:17
这个总结怕是有问题。我试了楼主提供的工程。MDK选用了MicroLIB，而IAR工程的库选项都是Full，IAR的链接 ...

谢谢，把full这茬给忘了。

IAR也还不错

boboo · 发表于 2019-3-29 21:39:55

一直是用IAT 批处理编译 + qzone调试

Eric2013 · 发表于 2019-3-29 22:00:46

修正下IAR的测试，修改如下三个地方

大小变为：
HardFaultHandler.o             18
SEGGER_HardFaultHandler.o    32
bsp.o                         480
bsp_fmc_io.o                476                4
bsp_key.o                   680             176
bsp_led.o                   148
bsp_timer.o                   712             77
bsp_uart_fifo.o             1 024          2 092
main.o                      1 756
startup_stm32h743xx.o       684
stm32h7xx_hal.o             140       7    12
stm32h7xx_hal_cortex.o       328
stm32h7xx_hal_gpio.o          504
stm32h7xx_hal_rcc.o       1 860
stm32h7xx_hal_rcc_ex.o    2 768
stm32h7xx_hal_sram.o          100
stm32h7xx_hal_tim.o          288
stm32h7xx_hal_uart.o       1 758
stm32h7xx_it.o                14
stm32h7xx_ll_fmc.o          272
system_stm32h7xx.o          120       5       8
----------------------------------------------------
Total:                   14 162    12 2 369

  16 734 bytes of readonly  code memory
   90 bytes of readonly  data memory
6 621 bytes of readwrite data memory

Eric2013 · 发表于 2019-3-29 23:01:55

boboo 发表于 2019-3-29 21:39
一直是用IAT 批处理编译 + qzone调试

你说的是SEGGER的Ozone吧，这个小软件挺牛。

Eric2013 · 发表于 2019-3-29 23:42:26

继续开启MDK5中AC6的Link-Time优化，大小巨减

Eric2013 · 发表于 2019-3-29 23:44:07

继续开启MDK5中AC6的Link-Time优化，大小巨减。

Total RO  Size (Code + RO Data)             11476 (  11.21kB)
Total RW  Size (RW Data + ZI Data)             6512 ( 6.36kB)
Total ROM Size (Code + RO Data + RW Data) 11484 (  11.21kB)

Eric2013 · 发表于 2019-3-29 23:50:34

大傻师发表于 2019-3-28 22:38
CLANG是专门的版本还是就是CLANG官网下的通用的版本？

专用的，估计他们自己都做优化了。

大傻师 · 发表于 2019-3-29 23:57:00

Eric2013 发表于 2019-3-29 23:50
专用的，估计他们自己都做优化了。

就是MDK带的哪个吗？还是从其他哪里下的？

Eric2013 · 发表于 2019-3-30 00:00:15

大傻师发表于 2019-3-29 23:57
就是MDK带的哪个吗？还是从其他哪里下的？

是MDK带的，集成到IDE里面了，在安装目录里面有相关文件。

大傻师 · 发表于 2019-3-30 10:29:30

MDK自带的CLang就是AC6咯？结果相差有点大，估计时编译参数或者库的原因。

Eric2013 · 发表于 2019-3-30 11:30:26

大傻师发表于 2019-3-30 10:29
MDK自带的CLang就是AC6咯？结果相差有点大，估计时编译参数或者库的原因。

MDK5中AC6的Link-Time优化有点厉害。

Embedded Studio里面有个SEGGER Linker，优化也很强，一直没有测试成功，现在暂时用的GCC Linker

大傻师 · 发表于 2019-3-30 14:18:01

本帖最后由大傻师于 2019-3-30 14:22 编辑

Eric2013 发表于 2019-3-30 11:30
MDK5中AC6的Link-Time优化有点厉害。

Embedded Studio里面有个SEGGER Linker，优化也很强，一直没有测试 ...

GCC开了Link-Time optimization（LTO）之后也很厉害，无论是运行时间还是还是HEX的尺寸都会大幅下降，不过调试的时候会恶心点。最新的GCC8.2强化了LTO后的调试功能，但是有BUG不能用，我试了一下老是链接失败，新版应该会修复，现在还是用的GCC 7.3。之前由于FLASH空间很紧张，试过对比AC5，AC6，IAR跟GCC编译我同一个项目，都打开优化尺寸跟LTO，总HEX大概32K的情况下，不同编译器结果差异不是很大，只有几百字节。gcc开了lfto跟Os，AC6开了lfto跟Oz，gcc的HEX31.5k，AC6的HEX32K出头。

Eric2013 · 发表于 2019-3-30 14:29:15

大傻师发表于 2019-3-30 14:18
GCC开了Link-Time optimization（LTO）之后也很厉害，无论是运行时间还是还是HEX的尺寸都会大幅下降，不 ...

我这个例子到时差异很大，你方便的话，可以对比下。

Embedded Studio的话，使用GCC也有Link-Time优化，就是编译不通过，暂时不知道怎么解决

大傻师 · 发表于 2019-3-30 14:31:17

本帖最后由大傻师于 2019-3-30 14:36 编辑

Eric2013 发表于 2019-3-30 14:29
我这个例子到时差异很大，你方便的话，可以对比下。

Embedded Studio的话，使用GCC也有Link-Time优化， ...

你用的是最新的gcc么？最新的8.2的有bug，开不了LTO，这个bug是官方确认过了的，改用老一点的7.3就可以。

大傻师 · 发表于 2019-3-30 14:32:29

我当时用AC6的时候没注意用的什么库，可能用的库不对，导致clang编译出来尺寸偏大

Eric2013 · 发表于 2019-3-30 14:41:58

大傻师发表于 2019-3-30 14:31
你用的是最新的gcc么？最新的8.2的有bug，开不了LTO，这个bug是官方确认过了的，改用老一点的7.3就可以。 ...

GCC和CLANG的版本

GCC开不了，测试了下CLANG可以LTO，效果明显

大傻师 · 发表于 2019-3-30 14:47:32

本帖最后由大傻师于 2019-3-30 14:48 编辑

Eric2013 发表于 2019-3-30 14:41
GCC和CLANG的版本

2018-q4是gcc8.2，用2018-q2的gcc7.3是可以开LTO的
https://developer.arm.com/tools- ... in/gnu-rm/downloads

Eric2013 · 发表于 2019-3-30 16:15:57

大傻师发表于 2019-3-30 14:47
2018-q4是gcc8.2，用2018-q2的gcc7.3是可以开LTO的
https://developer.arm.com/tools-and-software/open- ...

感谢，看来GCC8.2开LTO真是有问题。

清新怡人 · 发表于 2019-4-2 18:03:51

很喜欢这种测试风格，不过我关心的是代码效率，跑benchmark才能见真功夫。IAR在效率方面绝对是顶尖的，特别适合强迫症患者。当然AC6也很牛了，错误提示比AC5友善很多，编译速度也很快，缺点是调试不友善。

Eric2013 · 发表于 2019-4-2 19:18:56

清新怡人发表于 2019-4-2 18:03
很喜欢这种测试风格，不过我关心的是代码效率，跑benchmark才能见真功夫。IAR在效率方面绝对是顶尖的，特别 ...

IAR的确比较溜，所以我们现在一直保持制作IAR版本的例子。

等后面制作二代DSP教程的时候会再次制作一期，分享下。

AC6的调试挺好用的，最近刚发现AC6使用中文路径问题稍多，所以不可使用中文

qwert1213131 · 发表于 2019-4-2 20:08:13

对比做的很不错，非常清晰

Eric2013 · 发表于 2019-4-6 01:44:10

大傻师发表于 2019-3-30 14:47
2018-q4是gcc8.2，用2018-q2的gcc7.3是可以开LTO的
https://developer.arm.com/tools-and-software/open- ...

Embedded Studio刚发布的4.16正式版修正了GCC做Link-Time优化，可以正常使用了，GCC貌似还是之前的版本

advarx21ic · 发表于 2019-4-7 22:41:03

Eric2013大神,我在您的博客http://blog.sina.com.cn/s/blog_98ee3a930102w4gf.html上看到"SEGGER发布的可以在Cortex-A8上面运行的emWin工程（TI的AM335X入门套件）",请问您有下载到相关的工程吗?如果有能发一份给我吗?谢谢!147880150@qq.com

Eric2013 · 发表于 2019-4-8 01:10:29

advarx21ic 发表于 2019-4-7 22:41
Eric2013大神,我在您的博客http://blog.sina.com.cn/s/blog_98ee3a930102w4gf.html上看到"SEGGER发布的可以 ...

他们网站没有改版前是可以下载的，升级后不行了。

之前申请没有回复我，帮你刚刚又申请了一次，如果回复了，我回复你

advarx21ic · 发表于 2019-4-8 08:42:30

Eric2013 发表于 2019-4-8 01:10
他们网站没有改版前是可以下载的，升级后不行了。

之前申请没有回复我，帮你刚刚又申请了一次，如果回复 ...

谢谢你，大神。准备入手你们的示波器开发板。

huangrui · 发表于 2019-4-8 08:46:51

我感觉HAL库比标准库编译器起来要慢很多，不是一点、两点。
好像同样是HAL库，F103,F030,编译的速度要比F407要快很多。楼主没有测试过？

Eric2013 · 发表于 2019-4-8 11:47:03

huangrui 发表于 2019-4-8 08:46
我感觉HAL库比标准库编译器起来要慢很多，不是一点、两点。
好像同样是HAL库，F103,F030,编译的速度要比F40 ...

其它系列的HAL库还没有试过，后面我试试。

Eric2013 · 发表于 2019-4-8 11:47:58

advarx21ic 发表于 2019-4-8 08:42
谢谢你，大神。准备入手你们的示波器开发板。

截止到现在，还没有回复我，估计跟上一次一样了。

advarx21ic · 发表于 2019-4-8 18:02:24

Eric2013 发表于 2019-4-8 11:47
截止到现在，还没有回复我，估计跟上一次一样了。

嗯,不知道segger的用意,开放不好吗?多人用才会买产品呢.

Eric2013 · 发表于 2019-4-9 12:37:43

advarx21ic 发表于 2019-4-8 18:02
嗯,不知道segger的用意,开放不好吗?多人用才会买产品呢.

今天还是没有回复，看来真跟上次一样了。

advarx21ic · 发表于 2019-4-9 18:50:34

Eric2013 发表于 2019-4-9 12:37
今天还是没有回复，看来真跟上次一样了。

我自己也申请了，也没有回复。

cnshibo · 发表于 2019-5-9 16:47:13

huangrui 发表于 2019-4-8 08:46
我感觉HAL库比标准库编译器起来要慢很多，不是一点、两点。
好像同样是HAL库，F103,F030,编译的速度要比F40 ...

HAL 适合用来配置各种外设，如果要周期性操作的地方可以考虑直接寄存器操作。

Gorgon_Meducer · 发表于 2019-5-10 23:10:24

LLVM Clang目前在Coremark上还是落后gcc, ac6和iar一大截……

Gorgon_Meducer · 发表于 2019-5-10 23:14:22

LLVM自己的linker也有bug……首先是不知道自己选库，其次是生成的elf不能正确的被很多loader正确使用（有静态变量未被正确初始化的问题，注意不是静态变量没有被初始化，而是初始化的值是错的）。受影响的loader有MDK的debugger , DS-5的debugger ，这个已经很要命了。这个问题可以通过用objcopy把elf转化为hex或者bin来绕开。

Eric2013 · 发表于 2019-5-10 23:23:55

Gorgon_Meducer 发表于 2019-5-10 23:10
LLVM Clang目前在Coremark上还是落后gcc, ac6和iar一大截……

AC6就是基于CLANG的。

Eric2013 · 发表于 2019-5-10 23:25:15

Gorgon_Meducer 发表于 2019-5-10 23:14
LLVM自己的linker也有bug……首先是不知道自己选库，其次是生成的elf不能正确的被很多loader正确使用（有静 ...

非常谢谢告知这个问题

Gorgon_Meducer · 发表于 2019-5-13 18:17:50

Eric2013 发表于 2019-5-10 23:23
AC6就是基于CLANG的。

我当然知道arm compiler 6是基于llvm的。但arm compiler 6的很多优化是要经过一段时间验证才会上传到社区的，是不是会被社区接受加入主干是另说了。真是的例子就是，一年前很多arm compiler 6的优化就被提交到开源社区了，结果到了LLVM8/9，还是没能体现出来。

Eric2013 · 发表于 2019-5-13 18:26:16

Gorgon_Meducer 发表于 2019-5-13 18:17
我当然知道arm compiler 6是基于llvm的。但arm compiler 6的很多优化是要经过一段时间验证才会上传到社区 ...

优化问题我专门做了两个大点的综合Demo在H7上测试AC5开三级优化，并且开时间优化，而AC6开最高速度优化。

性能提升了一丢丢，稳定性也不错，稳定运行一周后停止测试了。

Eric2013 · 发表于 2019-5-13 18:29:13

从当前的情况来看AC5被取代只是时间问题了，编译个HAL库待Browse Info，完全没法用，而生成代码大小和性能跟AC6比，也处于下风。

最后就是稳定性，实测还是可以的，后面开几个板子，长期测试一段时间看看。

Gorgon_Meducer · 发表于 2019-5-13 19:31:45

Eric2013 发表于 2019-5-13 18:26
优化问题我专门做了两个大点的综合Demo在H7上测试AC5开三级优化，并且开时间优化，而AC6开最高速度优化。 ...

最高的速度优化是-Omax，不是-Ofast。

Eric2013 · 发表于 2019-5-13 19:35:08

Gorgon_Meducer 发表于 2019-5-13 19:31
最高的速度优化是-Omax，不是-Ofast。

感谢告知，我说怎么只提高了一丢丢，稳定性还是可以的

Gorgon_Meducer · 发表于 2019-5-13 19:40:38

Eric2013 发表于 2019-5-13 19:35
感谢告知，我说怎么只提高了一丢丢，稳定性还是可以的

-Omax 会默认打开 LTO。记得在 MDK里勾选Link-Time-Optimisation。否则linker会报告错误。
-Omax无法通过下拉列表获得，只能通过在 Misc Control的文本框里添加。在这里添加的选项会覆盖其它通过GUI配置的选项（因为在命令行中更靠后）。

另外MDK也是原生态就支持GCC的。

Eric2013 · 发表于 2019-5-13 19:41:32

Gorgon_Meducer · 发表于 2019-5-13 19:42:32

Eric2013 发表于 2019-5-13 19:41

不要全信文档说的……-Omax是很激进的，他还会比-Ofast额外做很多其他优化的。

Eric2013 · 发表于 2019-5-13 19:53:29

Gorgon_Meducer 发表于 2019-5-13 19:42
不要全信文档说的……-Omax是很激进的，他还会比-Ofast额外做很多其他优化的。 ...

太感谢了，之前一直没注意过还有-Omax这种优化选项，我说怎么下拉列表里面没。

Gorgon_Meducer · 发表于 2019-5-14 18:12:16

Eric2013 发表于 2019-5-13 19:53
太感谢了，之前一直没注意过还有-Omax这种优化选项，我说怎么下拉列表里面没。

...

另外，开-short enum也会对性能有一点点影响（有时候感觉不到）
One ELF Section Per-Function对性能也有影响（但是对size很有帮助）

Eric2013 · 发表于 2019-5-14 18:13:43

Gorgon_Meducer 发表于 2019-5-14 18:12
另外，开-short enum也会对性能有一点点影响（有时候感觉不到）
One ELF Section Per-Function对性能也有 ...

谢谢，这种基本忽略了

Eric2013 · 发表于 2019-5-14 18:26:35

Gorgon_Meducer 发表于 2019-5-14 18:12
另外，开-short enum也会对性能有一点点影响（有时候感觉不到）
One ELF Section Per-Function对性能也有 ...

今天实际测试-Omax和-Ofast，带RTOS和各种中间件的，测试性能基本没区别。

反倒代码大了一些。后再做个复杂些的DSP工程测试下。

xu84404351 · 发表于 2019-5-14 18:56:15

MDK5.27正式版使用AC6编译HAL库那些警告处理起来还是很麻烦，等等hal库适配ac6再试试

Gorgon_Meducer · 发表于 2019-5-14 21:42:02

本帖最后由 Gorgon_Meducer 于 2019-5-14 21:45 编辑

Eric2013 发表于 2019-5-14 18:26
今天实际测试-Omax和-Ofast，带RTOS和各种中间件的，测试性能基本没区别。

反倒代码大了一些。后再做个 ...

DSP最好用 CMSIS-DSP，依靠编译器是不靠谱的。j
想要性能，就要用IAR，开最高speed优化，开multiple-file-compilation。依靠armclang是不靠谱的。另外尺寸问题上，我觉得你没用好IAR，IAR开multiple-file-compilation，并且打开discard-unused-publics，结果绝对不会让你失望。
在linker里，Optimisation要打开 Merge Dulicated sections.

Eric2013 · 发表于 2019-5-14 21:45:19

Gorgon_Meducer 发表于 2019-5-14 21:42
DSP最好用 CMSIS-DSP，依靠编译器是不靠谱的。
想要性能，就要用IAR，开最高speed优化，开multiple-file- ...

编译器还可以，之前用AC5开时间优化做JPEG软解，性能提升不少，还是比较给力的。

Eric2013 · 发表于 2019-5-14 21:46:06

xu84404351 发表于 2019-5-14 18:56
MDK5.27正式版使用AC6编译HAL库那些警告处理起来还是很麻烦，等等hal库适配ac6再试试 ...

AC6编译HAL可以的，当前测试了F4和H7的，都没问题，其它的系列还没有测试过。

Gorgon_Meducer · 发表于 2019-5-14 21:46:21

Eric2013 发表于 2019-5-14 21:45
编译器还可以，之前用AC5开时间优化做JPEG软解，性能提升不少，还是比较给力的。 ...

我只能说你还没有发挥最大性能。

Eric2013 · 发表于 2019-5-14 21:49:43

Gorgon_Meducer 发表于 2019-5-14 21:46
我只能说你还没有发挥最大性能。

编译器能开的全开了，而需要手动开的，没整。

大部分应用场合，编译器还是非常给力的，而有些应用场景就不那么给力了，就像前面那个-Ofast和-Omax的测试。

Gorgon_Meducer · 发表于 2019-5-14 22:14:33

Eric2013 发表于 2019-5-14 21:49
编译器能开的全开了，而需要手动开的，没整。

大部分应用场合，编译器还是非常给力的，而有些应用场景就 ...

一般也不需要把编译器榨干到这种程度。很多时候还是要依靠编码技巧的。比如如何尽可能减少volatile的使用，
减少静态变量的使用，尽可能使用结构体，尽可能使用指针来访问变量，尽可能使用局部变量——这都是arm
环境下给编译器更多优化机会的举措。

Eric2013 · 发表于 2019-5-29 22:33:09

gamethink 发表于 2019-5-29 17:09
刚刚试了一次V6，吓人，好多不明的警告。。勉勉强强修改适应后可以编译通过，性能感觉比V5要快点，但是ROM ...

开启LTO优化，flash和ram变化就大了。

unnormal · 发表于 2019-5-30 09:19:35

谢谢分享

了解一下

Eric2013 · 发表于 2019-5-30 10:57:46

gamethink 发表于 2019-5-30 09:13
刚实施，用了你说的LTO，编译后运行也是有点问题，不知道是语法不够严谨还是怎样 ...

可以先用一些简单的程序做测试。

abutter · 发表于 2019-5-30 11:02:25

一般来说 gcc 加 lto 是指会改变代码和数据的布局，本身不改变优化选项，不会出大的问题。
如果开了 lto 出了问题，多数情况下是代码本身就有问题，只是没有暴露出来。

bigwei · 发表于 2019-5-30 15:36:19

感谢分享~学习了

Eric2013 · 发表于 2019-5-30 17:12:23

gamethink 发表于 2019-5-30 15:20
初略比较一下性能，我不是用HAL库，与那个无关，是一段有部分数学运算的的算法，具体什么不重要了，看看时 ...

这个东西还没有顾上去测试，后面做第2版DSP教程了，更新下这个帖子，做个系统的比较。

W872529868 · 发表于 2019-6-18 22:36:59

本帖最后由 W872529868 于 2019-6-18 22:42 编辑

Eric2013 发表于 2019-3-30 00:00
是MDK带的，集成到IDE里面了，在安装目录里面有相关文件。

已经安装了5.27但是发现界面好像和你发的截图有点不同

这是我哪里选择错了吗？工程是以前用4.7建的。

用AC6得用UTF-8编码格式，如果要控制串口屏，它的格式是GB2312那有什么方法转换？

Eric2013 · 发表于 2019-6-19 09:21:37

W872529868 发表于 2019-6-18 22:36
已经安装了5.27但是发现界面好像和你发的截图有点不同

1、你这个是AC5的效果，你要切换到AC6就跟我上面的一样了。
2、这个只能直接发汉字的GBK编码值了

MurphyZhao · 发表于 2019-6-19 09:49:59

看完了大神们的讨论，好 NB 啊，以前都没有关注过这些，涨知识了

zxzx8059 · 发表于 2019-6-28 18:46:22

iar 8.32.2沒開優化
uint32_t * uint32_t 32~63 bit會是0，
這個bug在iar 8.40就沒了，不過我司購買的授權沒到8.40

fengyunyu · 发表于 2020-11-21 19:07:59

请教硬汉，实际项目推荐开优化么？

比较IAR，MDK的AC5和AC6以及Embedded Studio的CLANG和GCC编译HAL库性能

本帖子中包含更多资源

阿莫论坛20周年了！感谢大家的支持与爱护！！

本帖子中包含更多资源

本帖子中包含更多资源

本帖子中包含更多资源

本帖子中包含更多资源

本帖子中包含更多资源

本帖子中包含更多资源

本帖子中包含更多资源

本帖子中包含更多资源

本帖子中包含更多资源