GCC -O2 optimization ~3% lower performance than Keil for motor control application

[Xsl_01]

Subject: Performance difference between GCC (-O2) and Keil ARM Compiler in motor control application

Description:

I am currently developing a motor control application using STM32F303 and comparing the performance of two development environments: STM32CubeIDE (GCC ARM toolchain) and Keil µVision (ARM Compiler).

Hardware & Software Environment:

• MCU: STM32F303

• STM32CubeIDE Version:2.1.1

• Keil MDK Version: v5

• Motor Control SDK Version: X-CUBE-MCSDK v6.4.2

• Optimization Level: -O2 for both compilers

• FOC Algorithm: [hall FOC]

• PWM Frequency: [16 kHz]

Test Methodology:
I have ported the exact same motor control source code to both environments. Performance is measured by:

1. I noticed that the .hex file generated by Keil （100 KB） is smaller than the one generated by STM32CubeIDE （103 KB）. Does this come from the compiler difference?
2. Has anyone performed similar benchmarks between GCC and ARM Compiler for motor control and found strategies to close the gap?

[Peter BENSCH]

Welcome @Xsl_01, to the community!

The small code size difference you observe (about 3%) between the Keil ARM Compiler and GNU GCC / STM32CubeIDE is expected and mainly due to different optimisation strategies in the two toolchains.

Commercial compilers such as the ARM Compiler are typically tuned for slightly better code size and performance in embedded use-cases, which explains their remaining advantage, even though GNU GCC has improved a lot over the last years. In many motor-control projects this gap can be reduced further by carefully adjusting GCC options (e.g. -Os or -O3, LTO with -flto, -fdata-sections/-ffunction-sections plus --gc-sections, and the correct -mcpu/FPU settings).

Whether the commercial compiler is worth it usually depends less on a few kilobytes of code size and more on your overall constraints (timing margin, safety/certification, tooling and support) - not to forget the price you are willing to pay for it.

Does this answer your questions?

Regards
/Peter

[Andrew Neil]

---

@Xsl_01 wrote:

1. I noticed that the .hex file generated by Keil （100 KB） is smaller than the one generated by STM32CubeIDE （103 KB）. Does this come from the compiler difference?

---

The size of the Hex file is not a great indication of the size of the actual executable code.

There's a lot of overhead in the Hex format, and lot of choices in how to represent the data.

Such a small difference could easily just be down to formatting & overhead.

---

@Xsl_01 wrote:

2. Has anyone performed similar benchmarks between GCC and ARM Compiler for motor control and found strategies to close the gap?

---

Keil did used to have some - you'd have to ask them about that.

But, as @Peter BENSCH suggested, it really shouldn't come as a surprise to find that a commercial compiler costing over a thousand pounds out-performs a free one!

If you've paid for a Keil licence, you would certainly hope that would be the case!

[Xsl_01]

I'm very sorry, my unclear explanation may have caused a misunderstanding. My question is: using the same MC_SDK project, when generating the program with Keil and Cube IDE respectively, and testing the same motor under otherwise identical conditions, the efficiency measured with the program generated by Keil is 3% higher than that generated by Cube IDE.

[Ozone]

Not sure how you define "efficiency" in this case.
But for code size or runtime of certain routines, a difference of 3% is really minor.
In other instances and architectures, 20 to 50% difference are not uncommon.

By the way ...

>  -  Optimization Level: -O2 for both compilers

This is not necessarily an exact match.
You would need to investigate the individual optimisation settings both compilers implicitly enable with "-O2".
And you can trim any optimisation towards either code size or speed.

[Xsl_01]

The "efficiency" I refer to is output power ÷ input power × 100%. In the MC_SDK, using the same project but different compilers (IDE vs. Keil), the resulting programs are downloaded to the same controller. Using the same dynamometer, the same motor, and under the same torque, the efficiency obtained with Keil is 3% higher than that with the IDE (e.g., at 5 Nm, the Keil compiler gives 78% efficiency, while the IDE compiler gives 75% efficiency).

[Andrew Neil]

---

@Ozone wrote:

>  -  Optimization Level: -O2 for both compilers

This is not necessarily an exact match.

---

Indeed - this is a very important point!

The optimisations are the "Secret Sauce" which really distinguishes one compiler from another.

As @Peter BENSCH already said, GCC is very much a general-purpose compiler covering a vast range of different architectures, and a vast range of different application domains - it is not focussed on embedded microcontrollers. 

Keil, on the other hand, is very much focussed on one architecture, and one application domain - so you would expect it to perform "better" than GCC.

Similarly IAR, et al.

[Ozone]

> The "efficiency" I refer to is output power ÷ input power × 100%.

As I understand this, you mean the physical efficiency of the motor here.
That makes sense as a statement.

> In the MC_SDK, using the same project but different compilers (IDE vs. Keil), the resulting programs are downloaded to the same controller.

Your firmware is a high-level representation of your algorithms and models, formulated in an abstract and formal language (C/C++).
How your choosen toolchain (Keil or GCC) translates this 'model' into a sequence of machine-executable instructions is another matter. To which you can apply "efficiency" criteria as well, by the way.

And if it is worth the time and/or money to investigate the differences between both firmware artifacts in detail is really up to you.

[Andrew Neil]

---

@Ozone wrote:

And if it is worth the time and/or money to investigate the differences between both firmware artifacts in detail is really up to you.

---

Indeed.

@Xsl_01 while you're at it, perhaps you could also evaluate Keil vs IAR ...

[Andrew Neil]

---

@Xsl_01 wrote:

• STM32CubeIDE Version:2.1.1

• Keil MDK Version: v5

---

Note that the current version of Keil MDK seems to be 6 ...