Why does modulo operation consume more power?

Question

I mainly use Cortex-M4F or Cortex-M0/0+ devices such as:

• STM32L4, G4
• STM32L0, G0

I sometimes see blogs like this one saying "Avoid Modulo" for lower power consumption.

Comparing these two programs, is this a proper way to avoid the modulo operation?

Assume the MCU supply voltage could be either 1.8 V or 3.3 V.

while(1) { // CODE X, I thought removing conditional statements could perform better
    my_index++;
    if (my_index >= 8) my_index = 0;
}

VS

while(1) { // CODE Y
    my_index = (my_index + 1) % 8;
}

Also, why does modulo operation consume more?

Answer 1

That set of rules makes sense, sort of. But they're limited.

Specifically, the blanket rule "don't use modulo" is somewhat misguided, and should really mean "avoid the use of code that results in a divide operation".

(My set of rules would be to understand how the hardware works, compile to assembly and inspect the result, profile your code, and benchmark, benchmark, benchmark).

If you had a line of code that said a = b % c; then (assuming that a, b, and c are integers) you're specifying to the compiler that c could be any integer value. It would have to compile in a divide operation. Divide operations take lots of either time or logic area; in either case that translates to energy consumed to perform a divide.

In your specific case, where you say my_index = (my_index + 1) % 8; then the compiler -- even with optimizations set at their lowest level -- will probably turn that into the machine language equivalent of my_index = (my_index + 1) & 0x0007;. In other words, it won't divide (way expensive), it won't even branch (less expensive), but it'll mask (least expensive on most processors today). But this will only happen if the modulo is by a power of two.

You could insure that by just using my_index = (my_index + 1) & 0x0007;, at the cost of code comprehension and thus code maintainability. Comment it well if you go down that road.

So in your specific case, as long as that % 8 doesn't change, or only ever changes to % N where N is always \$2^n\$, and the compiler knows that, the speed won't change. But if you or someone else comes along later and changes it to my_index = (my_index + 1) % 17; (or any other non power of 2) then suddenly your code will have a divide operation and it'll be more power-hungry. In that case, using the conditional statement will be less expensive.

(In C/C++, you make sure that the compiler knows the value of a constant ahead of time by using a # define statement, or (depending on the optimizer) declaring it const unsigned int or (stronger, if it's C++) declaring it constexpr int. Other compiled languages (i.e. Rust) have their own ways of making this happen.)

Note: I wouldn't be surprised if a good optimizing compiler wouldn't turn the 'if' construct into a mask -- but I wouldn't be surprised if it didn't. Ditto, a really good optimizing compiler might see the my_index = (my_index + 1) % 17; and infer the conditional construct. I don't think I'd count on that without looking at the assembly, and I don't think I'd trust it 100% -- I might use it, but I'd put a comment in the code about crossing my fingers and hoping the compiler plays nice.

Unless you're absolutely backed against the wall for power consumption, you should also be thinking about code readability and fragility. Someone will come along later and need to understand that code, and will appreciate it if it's not a minefield full of opportunities for screwing it up. That someone may be future-you, so be nice!

Answer 2

First of all, in case it isn't obvious: longer execution time means more power consumption. Though if you are mostly interested in reduced power consumption, look at the system clock before anything else.

Why does modulo operation consume more power?

It doesn't on a modern compiler. Division and modulo are heavy CPU operations for most cores, but C code generating actual div etc instructions was mostly happening up until some 15-20 years back. Modern compilers will pick the best code when you enable optimizations and avoid division when it can be avoided. Also division is a bigger problem performance-wise on low-end MCUs like 8 and 16 bitters.

However, it should be mentioned that it's somewhat common practice in embedded systems to run with all optimizations disabled. Mostly because compiler optimizers of various mediocre-quality embedded compilers rightfully built up a nasty reputation of being buggy, back in the 90s and early 2000s.

If you run with optimizations disabled, then you are of course on your own and have to perform all optimizations manually - which is definitely not recommended practice unless you have in-depth knowledge about both C and the target CPU.

---

Lets disassemble your particular code examples in gcc-arm-none-eabi, with -O3. I made these stand-alone examples:

void func1 (void)
{
  static unsigned int my_index;
  while(1) 
  { 
    my_index++;
    if (my_index >= 8) my_index = 0;

    volatile unsigned int out = my_index;
  }
}

void func2 (void)
{
  static unsigned int my_index;
  while(1) 
  { 
    my_index = (my_index + 1) % 8;
    volatile unsigned int out = my_index;
  }
}

The volatiles are needed as side-effect to block the optimizer from removing the code entirely. Now, disassembling this using Godbolt https://godbolt.org/z/bM5M5v38h, we get nearly identical machine code. No division in sight. The version with addition is actually performing ever so slightly worse because of the cmp instruction (branch).

---

I thought removing conditional statements could perform better

Yes generally, and in your case it actually does, though it's a micro-optimization. Cortex M in general do not have advanced branch prediction nor cache memories. On a M0 it's not worth the head ache to even consider. I believe some STM32x4 have some hardware support for a simple form of branch predication. Higher end M7 etc will have cache and then avoiding branches matters more.

---

In general:

You should strive to write code as readable as possible. Then optimize when there are actual performance bottlenecks in your code. Manual optimizations are highly qualified work and requires lots of experience.

In this particular case I'd say the addition/counter version is more readable so I would use that regardless of a few CPU ticks more or less.

---

As for the blog you linked, the author is not a complete rookie and make some good points, but there are some strange and even misguided things mentioned. Let me comment on that bullet list you got the modulo comment from:

• Use the “Static Const” Class as much as possible to prevent runtime copying of arrays, structures etc. that consumes power.

  I have no idea what a "Static Const" Class is supposed to mean. C is notably case-sensitive and doesn't have a class keyword. I assume the author doesn't know proper C terminology and actually means to say something like: Use static storage class specifiers and const correctness whenever possible. If that's what they meant to say, that's general good advise.

• Use Pointers. They are probably the most difficult part of the C language to understand for beginners but they are the best for accessing structures and unions efficiently.

  It's kind of like telling the construction worker to use concrete... it's mandatory, not an option. Pointers is a fundamental building block of C.

• Avoid Modulo!

  Not really good advise as proven above.

• Local variables over global variables where possible. Local variables are contained in the CPU while global variables are stored in the RAM, the CPU accesses local variables faster.

  Generally correct although file scope variables ("globals") may get temporary stored in registers too. The main reason to avoid truly global (external linkage) variables is program design, not performance.

  Also the difference between register and RAM access is not that big on most MCUs, this comment mostly applies to high-end CPUs like x86, Cortex A, Power PC etc. When manually optimizing memory access for mid-range MCUs like Cortex M you should rather consider flash vs RAM, since flash often has wait states.

  However, reducing the scope of variables is always a good thing for readability, to minimize bugs and to reduce namespace clutter.

• Unsigned data types are your best friend where possible.

  True but not because of performance, but because of implicit conversions and poorly-defined behavior of signed/negative operands when used in bitwise operations.

• Adopt “countdown” for loops where possible.

  Ok this is even worse dinosaur advise than the modulo one. The rationale for this is very well-known, that compare vs zero is faster than compare against a value. But compilers have been able to do that optimization for ages! Do not write down-counting loops, that's simply obfuscation for nothing gained. This was valid advise around year 1993, not in year 2022.

• Instead of bit fields for unsigned integers, use bit masks.

  Good advise, but not related to performance either, but portability and poorly-defined behavior.

Overall the quality of the blog post is diverse: very sound advise is mixed with plain bad advise. I would stop reading that blog. Please note how often in this answer I have to go back 20-30 years back in time when commenting on it.