Timeline for Should I refactor my C code to optimise it for an embedded microcontroller?
Current License: CC BY-SA 3.0
11 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Nov 23, 2013 at 1:35 | comment | added | Scott Seidman | An engineer who consistently exceeds specs is wasting time and money | |
| Nov 22, 2013 at 23:29 | comment | added | darron | @supercat Well, I sure wish he had said it your way. Your whole paragraph, really. You're saying it better than I am. :) | |
| Nov 22, 2013 at 23:23 | comment | added | supercat | @darron: I interpret Knuth's statement as "Optimizing before one knows where it's needed will often lead to wasting time optimizing things that don't matter rather than things [not necessarily just performance] that do. I don't think profiling is always needed; when picking between a simple O(N^3) algorithm or a complex O(NlgN) one, for example, knowing that N might reach 1000 would be a pretty strong argument against the former even without profiling, and knowing that N would seldom exceed 3 and never exceed 5 would be a strong argument against the latter. | |
| Nov 22, 2013 at 23:16 | comment | added | darron | @supercat notice that RedGrittyBrick's rule statement don't mention the word "premature". At least it appears afterwards... but MANY people just leave that word out entirely. I guess my main peeve here is that I believe this "optimize only when you need to" logic more generally leads to crappy architecture... because a lot of performance problems are architectural and it's really painful to change that later. I think Knuth was assuming a basic level of competence that is sadly not reflected in reality these days. | |
| Nov 22, 2013 at 23:16 | comment | added | supercat | ...almost everything else in C. I didn't even bother trying to write the math routines in C. The assembly-code portion of the math processing probably took about 5% of overall CPU time, and C would have been at least 3-5x as slow. CPU utilization with fixed-point math in C might have been below 100%, but it's a lot easier to reason about timings when loading is low than when it is high. | |
| Nov 22, 2013 at 23:10 | comment | added | supercat | @darron: The key word is premature optimization, especially in cases where paying too much attention to optimizing one piece of a program may cause one to neglect a more important piece which poses a major bottleneck (e.g. I remember taking over a program someone wrote for a fixed-point DSP. Everything was written in assembly code except the math, which was written in C using floating-point, and IIRC required about 60ms to process each 25ms worth of audio). I think my rewrite ended up with a few hundred lines of assembly code for interrupt handlers, a few dozen for math, and... | |
| Nov 22, 2013 at 23:03 | comment | added | darron | a CRC routine on an 8 bit processor might not need to be efficient at all, or it could be absolutely critical. Without more specifics, this is NOT a good example for the OP's "generic proof" for or against optimizing it. | |
| Nov 22, 2013 at 23:01 | comment | added | darron | I really hate how far people take that Knuth comment. You should at least pay attention while you're writing code to make it reasonably efficient to start with. People quote Knuth as an excuse for their sloppy code, and get all righteous about it too. You should develop good programming practices that help you right good code. I'm not saying to disassemble and pipeline analyze everything... but as @supercat says if you're at all paying attention to your problem you would likely realize how much work your CRC algorithm is going to do. In many situations it will absolutely matter. | |
| Nov 22, 2013 at 22:19 | comment | added | Nick Alexeev | To Brick's point. "[...] premature optimization is the root of all evil" per Donald Knuth. | |
| Nov 22, 2013 at 22:14 | comment | added | supercat | Buffer CRC routines can often a bottleneck on 8-bit micros, even when written optimally. Further, an many 8-bit micros something like the quoted code is probably many slower than would be optimal code. For many purposes, C code can get close enough to assembly to not be worth further optimization, but certain kinds of loop constructs require optimizations no compiler I know of can possibly make. | |
| Nov 22, 2013 at 21:54 | history | answered | RedGrittyBrick | CC BY-SA 3.0 |