why Compiling for Cortex M7 is painfully slow

• why Compiling for Cortex M7 is painfully slow
  Posted by ali_asadzadeh on 01 Aug, 2020 12:10
• 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?
• #1 Reply
  Posted by brucehoult on 01 Aug, 2020 12:25
• 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.
  
• #2 Reply
  Posted by unitedatoms on 01 Aug, 2020 12:30
• 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 ?
• #3 Reply
  Posted by Siwastaja on 01 Aug, 2020 13:30
• 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.
• #4 Reply
  Posted by hansd on 01 Aug, 2020 13:38
• 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.
• #5 Reply
  Posted by newbrain on 01 Aug, 2020 15:41
• 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.
• #6 Reply
  Posted by mikerj on 01 Aug, 2020 19:12
• 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).
• #7 Reply
  Posted by Nominal Animal on 02 Aug, 2020 00:36
• 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 to ARM Cortex-M7 docs, binaries that do not use floating-point compiled for Cortex-M3 or Cortex-M4 can run as-is on Cortex-M7.)
• #8 Reply
  Posted by brucehoult on 02 Aug, 2020 00:47
• Quote from: Nominal Animal on 02 Aug, 2020 00:36

  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 to ARM Cortex-M7 docs, binaries that do not use floating-point compiled for Cortex-M3 or Cortex-M4 can run as-is on Cortex-M7.)
  

  
  They 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.
  
• #9 Reply
  Posted by westfw on 02 Aug, 2020 02:15
• 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.
  
• #10 Reply
  Posted by lucazader on 02 Aug, 2020 04:33
• 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.
• #11 Reply
  Posted by ali_asadzadeh on 02 Aug, 2020 10:16
• 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 changed
  
  
  
  The 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 project
  
  I have a core I7 cpu and 8GB ram and 1TB SSD
  
  
  
  The Graphic cube project is attached and you can play with
  
  

  ---

  Graphic.zip
• #12 Reply
  Posted by hans on 02 Aug, 2020 11:40
• 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 -O0
  
  

  Quote

  [100%] Linking C executable Graphic.elf
  Memory region         Used Size  Region Size  %age Used
           DTCMRAM:        4920 B       128 KB      3.75%
            RAM_D1:          0 GB       512 KB      0.00%
            RAM_D2:          0 GB       288 KB      0.00%
            RAM_D3:          0 GB        64 KB      0.00%
           ITCMRAM:          0 GB        64 KB      0.00%
             FLASH:       51428 B       128 KB     39.24%

  
  With optimizer -Os: 2.495sec
  

  Quote

  [100%] Linking C executable Graphic.elf
  Memory region         Used Size  Region Size  %age Used
           DTCMRAM:        4920 B       128 KB      3.75%
            RAM_D1:          0 GB       512 KB      0.00%
            RAM_D2:          0 GB       288 KB      0.00%
            RAM_D3:          0 GB        64 KB      0.00%
           ITCMRAM:          0 GB        64 KB      0.00%
             FLASH:       28512 B       128 KB     21.75%

  
  With 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).
• #13 Reply
  Posted by ali_asadzadeh on 02 Aug, 2020 13:23
• Thanks, I have switched the compiler to version 6, now it compiles around 5 seconds.