What is the optimum hardware for speeding up the linking and compiling process?

[Markus Spiekermann]

HI everybody,

we're are trying to build up a few more work spaces for developing STM32CubeIDE

applications and we're unsure in what kind of laptop / desktop hardware we should invest.

Can somebody point out the most important parts responsible in speeding up linking

and compiling processes? CPU type, number of cores, RAM size, type of storage, etc..

Maybe it's possible to recommend a certain system that is optimised in supporting

embedded programming.

Thanks and best regards

Markus Spiekermann

[KnarfB]

Few thoughts: STM32CubeIDE uses "make -j" for building which uses all cores for parallel compilations. The more cores the faster. When my Win10 machine is idle, it uses 14GB of RAM, so 16GB seems tight, I'm on 32GB. The gcc compiler and linker are IO intensive -> one or two fast SSDs come handy.

A clean build of a "typical" F7 project (96 .c files) in Debug configuration takes about 15 seconds. I'm happy with that.

hth

KnarfB

[TDK]

Certainly a fast SSD would be the best bang for the buck here since compiling often uses so many different files at once.

I don't think you really need a specialized system though. General CPU benchmarks should be applicable. Compiling can be easily parallelized, so more cores are better. Linking not as much.

[Markus Spiekermann]

Thank you for your thougths and comments. I'll keep them in mind by setting up the hardware.

[Louis Cloete work]

1. Go for more cores rather than faster cores. If you have a choice between e.g. 6 cores @ 4GHz or 8 cores @ 3.7GHz go for the 8 cores.
2. Definitely get an SSD. This will probably cause the most noticeable gain in performance.
3. Go for more RAM rather than faster RAM. I.e. rather 32 GB 2666 MHz than 16 GB 3600 MHz.

Hope this helps.

[Uwe Bonnes]

Consider also flashing time of the resulting executable.

[Louis Cloete work]

I'm not 100% sure about this, but I think the bottleneck on flashing time will be the ST-LINK and the USB2.0 link, not some component on the PC. It seems like the ST-LINK is making the PC wait instead of the other way around.

[Markus Spiekermann]

Flashing time: Good point too. Well I believe that boundnaries are set by the programming hardware. St-LINK in combination how fast the DUT flash memory allows to be written to. And here embedded developers can't do much to optimize.

[Markus GIRDLAND]

Hello!

One thing that's not related to hardware but is one of the absolute biggest performance boosts is using Linux and/or macOS.

The file system in Windows makes CubeIDE kind of slow.

For reference, when we test the GNU tools toolchain which implies compiling and executing several thousands of tests across Linux/mac/windows.

Then Windows is always way slower than the other two operating systems.

I could imagine that you could set up a RAM disk and check out your workspace/project to be compiled from RAM instead of the hard drive to boost the performance on Windows.