Reading from Memory vs Performing an Operation [closed]

Question

Closed. This question is opinion-based. It is not currently accepting answers.

---

Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.

Closed 5 years ago.

Improve this question

I'm learning to program microcontrollers and am trying to develop good habits:

Suppose I have a set of values which can be calculated based on what is already in memory. As a general rule, is it always better to calculate the data once, and save it in memory, or is it always better to calculate it each time it's needed?

My guess would be that since reading and writing to memory is slower than processor operations, it would always be better to calculate something each time it's needed rather than storing the value in memory, provided the calculation is somewhat trivial.

Am I correct in my thinking?

Answer 1

Suppose I have a set of values which can be calculated based on what is already in memory.

What's faster - reading from memory, or reading from memory and performing a calculation?

What you're thinking of is true, some calculations are quicker than a memory read and so, if you're concerned about your CPU cache hits or memory usage, re-calculating may well be a good thing, but in the general case, caching is never a bad choice. Even when you save no time, you at least have implemented a mechanism that can be used later on when you do have a complex value that requires caching.

The only time you really want to avoid caching is when you're controlling what memory gets loaded into the CPU. Having to chuck all that out to load a block of memory just so you can read a value, and then refill the cache with the original memory can be very expensive (relatively speaking). 99% of programs don't do this though, reading memory is one of those things they do all the time so a cache makes no difference to execution time. YMMV if you're writing for a microcontroller with very limited memory.

Answer 2

When building the very first version of your software, always recalculate everything. You see, calculating stuff and storing them in memory is caching, and caching is an optimization, and any optimization before you have a complete product is a premature optimization, and premature optimization is the root of all evil.

Then, you have to consider that in embedded systems you may have many considerations which you might not have in non-embedded systems.

• Do you actually have enough memory to spare for caching stuff?

• Is this memory infinitely writable or does it wear down with each write?

• Is your memory writable fast enough? Some weird (mostly old) memories are far slower to write than to read, so calculating, writing once, and reading multiple times might have a comparable performance to recalculating multiple times.

• Your code will already be complex enough and hard enough to debug due to peculiarities of the embedded system, do you really need to complicate your life even more by adding caching?

In short, unfortunately no, there is no general rule which says that it is always better to do this or always better to do that.

Answer 3

"Always" is always wrong. There are no general rules. Every case is different.

First, there's characteristics of your processor. The relative speed of reading/writing memory vs. performing operations is hugely different between processors. Enough different that it affects the decision.

Second, there is the question how often a result that was calculated once is used. If you calculate a*b a thousand times (with the same values a and b) then storing the result and loading when used is most likely to be a win; if you do it twice then this is much more dubious.

Third, there is correctness. If you recalculate a*b after a or b has changed then you get the correct result. If you rely on a stored result a * b after a change, then one of three things happens: 1. You get an old, stale result that is incorrect. 2. You check whether a or b has changed and recalculate the product if needed, which will eat up all or most of your advantage, or 3. you recalculate a * b in each place where you change a or b. Neither of these is much fun and hard to get correct.