Float arithmetic vs. int arithmetic - is there any power penalty?

Question

It is widely known that float arithmetic takes longer (that is, eats more cycles) than fixed-point (or integer, or bitwise arithmetic), and that surely is something to consider for speed- and time-critical applications.

My question is: supposing I don't have any time-critical need (and I have enough program and RAM memory), should I be worried by any other disadvantage of using float?

Specifically, I wonder if the processor would be more power-hungry because of those extra CPU cycles.

---

UPDATE: What will my application do meanwhile?

The only goal of the application is to turn lights on and off (lots of them) based on push-button input. I am using float to apply filtering to button inputs, in order to debounce the buttons simulating a RC filter + schmitt-trigger. So the loop in pseudo-code would be:

1. Read all inputs (digitalRead or direct port access);
2. Filter the readings and decide if a button action has been detected;
3. Set some control flags that determine which part of the cycle the lights are in;
4. Check for elapsed time to actually turn blinkers on and off.

So, since I plan to react to button input as realtime as possible, most time would be spent filtering (that is, performing floating point operations), since direct port access and flag-setting are supposed to be nearly instantaneous, right?

Answer 1

It depends on what your processor is doing while it has no real work to do:

• If you put it to sleep, then yes, using floats will keep the CPU awake for a longer time and burn more energy.
• If you are instead doing busy-waits (e.g. with delay()) it should make no difference, since the CPU is busy 100% of the time anyway.

Update: According to your update, it seems your program never sleeps. Then I would expect no substantial difference in power consumption between using floats or ints. As Majenko said, there can theoretically be some small difference depending on the number of transistor transitions involved in each instruction (and, I would add, the capacitive loading of the involved transistors), but I do not expect this to be very significant.

If you are really concerned about the consumption of your Arduino, I would suggest you use it only for prototyping, then move your code to a bare ATmega (or maybe even an ATtiny) chip. Also, add at least one call to sleep_mode() inside your main loop. Each such call will put your CPU to sleep until the next timer interrupt, which typically happens every 1024 µs. There is a lot more to say about power savings, see for example this excellent writeup by Nick Gammon.

Edit: When trying to minimize power consumption, one of the very first things to do is figure out how much work has to be done, and make sure your program never does more work than required. In your case, this means you have to know how often your main loop should execute, and prevent it from running more often than needed. For example:

#include <avr/sleep.h>

const unsigned long loop_period = 5;  // run the loop every 5 ms.

void loop() {

    /* Sleep while waiting for the next time slot. */
    static unsigned long last_time;
    while (millis() - last_time < loop_period)
        sleep_mode();
    last_time += loop_period;

    /* Actual work goes here... */
}

If the actual loop work takes significantly less time than the loop period, your CPU will sleep most of the time, leading to significant power savings. Then you can start digging into more advanced power-saving techniques like those mentioned in the article linked above.

Answer 2

The only goal of the application is to turn lights on and off (lots of them) based on push-button input. I am using float to apply filtering to button inputs, in order to debounce the buttons simulating a RC filter + schmitt-trigger.

Using floats is way overkill here. To debounce all you need to do is note when the switch changed state, and ignore further state changes during a certain interval, say 10 ms. It is even quite feasible to sleep during that debounce period. One of the watchdog timer intervals is 16 ms which would be about right for that.

In any case, an application that turns lights on is hardly going to be one where you are worried about how much power floating point operations take. I would be 1000 times more worried about how much power the lights use.

Answer 3

Yes, more power will (theoretically) be consumed. That is, compared to doing nothing.

Float operations will require more mathematical operations to perform compared with integer or fixed point. That will mean more gates are being activated and deactivated etc, compared to doing nothing.

Would that increase in power be noticeable? Probably not. It'll be so tiny as to be negligible. As Edgar Bonet has mentioned, if you are making use of sleep modes then the extra time taken to perform the float operations will impact the ratio of running to sleep time, but if all you are doing is a set of mathematical operations a few times a second and using the millis() or delay() functions to control the timing then the difference will be so minimal you'll never notice it.

The effect is more noticeable on a PC when you perform very complex operations (like 3D rendering) and the CPU gets hotter and the fan speeds up. In this situation the CPU is entering an idle state (like sleep, but less so) when it's not needing to perform any tasks which reduces both power consumption and heat dissipation. When performing heavy tasks it has less time to be idle and so generates more heat. The more complex the operations the more transistors need to switch and so the more heat is dissipated.

Unfortunately the power dissipation per op-code is not documented, but it should be possible to write some assembly code to execute a single instruction in a tight loop (start with NOP) and measure the current, then change that instruction for a different one and compare the current. Using NOP as a baseline you should then be able to calculate the increase in current for each op-code. Of course, the actual data the op-codes are operating on will also have a bearing on the power consumption.

But that would be pretty pointless unless you are budgeting for every single femtowatt of power.

Answer 4

If you are interested in power saving, I think it would be more important to check that the standard Arduino library doesn't turn on HW blocks that you do not need.

From an engineering perspective, though, the filter you are pursuing seems a bit overkill, if you only worry about bounces. Waiting for a reasonable amount of time after the first transition should be sufficient and would keep the code simpler to write, test and debug.

The mechanical switch is already a dampened system with its own intrinsic time constant.