why Compiling for Cortex M7 is painfully slow - Page 1
Forum section: electronics / general

author: ali_asadzadeh
author_rank: Super Contributor
timestamp: August 01, 2020, 12:10:01 pm
content: Hi,This is the first time moving to M7, it's a STM32H750 and I'm using keil,The compilation is painfully very slow, is something wrong? any Ideas?

author: brucehoult
author_rank: Super Contributor
timestamp: August 01, 2020, 12:25:06 pm
content: I've got a board (Teensy 4.0) with a Cortex M7. gcc seems to compile good optimized code for it just as quickly as for anything else. (I've never seen keil).The CPU really flies too.

author: unitedatoms
author_rank: Frequent Contributor
timestamp: August 01, 2020, 12:30:34 pm
content: On Cortex M0 Keil Compiler 5 is slower than Compiler 6 for my projects. I recently migrated to Compiler 6 to have more warnings to learn C. It is possibly LLVM making compilation faster.Do you have latest Compiler in KEIL project settings ?

author: Siwastaja
author_rank: Super Contributor
timestamp: August 01, 2020, 01:30:31 pm
content: At least for me, GCC has no problem whatsoever. For example, a 25000 LoC project of about 40 files for Cortex-M7 with arm-none-eabi toolchain seems to take 3 seconds on single thread, single sequential make process, on a el-cheapo Asus laptop with Intel Core i3-8130U CPU @ 2.20GHz. Partially -O3, partially -Os.Maybe the problem is with Keil.

author: hansd
author_rank: Contributor
timestamp: August 01, 2020, 01:38:53 pm
content: Check also the exploit protections in your virus scan. You might have to exclude Keil and your project directory. I saw this with STM32CubeMX. After exclusion it reduced the build time from 90 seconds to a few seconds.

author: newbrain
author_rank: Super Contributor
timestamp: August 01, 2020, 03:41:50 pm
content: Another sample point, still arm-none-eabi-gcc, 200 kLOC over about 330 .c and .h files:less than 7 s after a make clean, "make -j 16 all" on an AMD 2700X.

author: mikerj
author_rank: Super Contributor
timestamp: August 01, 2020, 07:12:08 pm
content: Have you configured Keil to generate all the various debug type files, e.g. pre-processor, list etc? That can really slow things down IME, especially when combined with a sluggish realtime virus scanner (corporate, so have to jump through hoops to get folders excluded).

author: Nominal Animal
author_rank: Super Contributor
timestamp: August 02, 2020, 12:36:52 am
content: Cortex-M7 is not that different from Cortex-M4 from the compiler point of view – they're both ARMv7E-M –, so it's not Cortex M7 that is the issue here, it's the compiler.(According toARM Cortex-M7 docs, binaries that do not use floating-point compiled for Cortex-M3 or Cortex-M4 can run as-is on Cortex-M7.)

author: brucehoult
author_rank: Super Contributor
timestamp: August 02, 2020, 12:47:33 am
content: Quote from: Nominal Animal on August 02, 2020, 12:36:52 amThey won't be optimally scheduled for the dual-issue M7.That is something a compiler *could* spend some time on optimizing. It would have to be using really bad algorithms to be noticeable though.

author: westfw
author_rank: Super Contributor
timestamp: August 02, 2020, 02:15:13 am
content: Is it compiler, or "upload" that is slow?I've noticed that there's a wide variation in the efficiency of the upload algorithms for CMSIS-DAP devices."Early", they seem to get flash controller registers defined, and programming proceeds by issuing individual commands to the registers, updating RAM one word at a time, and so on. "Later" someone implements higher-level code where a "helper" routine is loaded into RAM, and it does something more like block-based programming (faster!) Or something like that.

author: lucazader
author_rank: Regular Contributor
timestamp: August 02, 2020, 04:33:57 am
content: i had noticed that the keil compiler was very slow with m7 core's in the past.It was one of the may reasons that i move over to using gcc.

author: ali_asadzadeh
author_rank: Super Contributor
timestamp: August 02, 2020, 10:16:31 am
content: Thanks for your feedback, this is the settings for my simple Test project, everything is generated by Cube, and I just have added a few files to the project, I'm very early in development.Also I have disabled the windows defender for now, Nothing changedThe project files are very huge, around 500MB! I will just upload the Cube file, If you are interested just generate the project with Cube and make the project, it will take 3 minutes to build and complie the projectI have a core I7 cpu and 8GB ram and 1TB SSDThe Graphic cube project is attached and you can play with

author: hans
author_rank: Super Contributor
timestamp: August 02, 2020, 11:40:14 am
content: I loaded your .ioc file. Generated code for toolchain SW4STM32. Loaded folder (.ioc + source) in CLion with embedded project type.Build using ARM GCC 9.2 on Manjaro Linux on 8 threads (Intel i7 6700HQ Thinkpad laptop): 1.695sec, no optimizer -O0QuoteWith optimizer -Os: 2.495secQuoteWith SW4STM32 target the project folder is only 11MB. I think the other type is much larger, as it includes various math libraries..Anyway, do you have a parallel compilation option for Keil? IME Keil isn't the fastest toolchain, but 3min is very slow and IMO unusable (even with incremental compilation).

author: ali_asadzadeh
author_rank: Super Contributor
timestamp: August 02, 2020, 01:23:53 pm
content: Thanks, I have switched the compiler to version 6, now it compiles around 5 seconds.