3 ms·
I'm not really a crack at micro-optimizing C code, so can anyone here explain to me why the given function was written in the form it was? Why not something li
by ginko 14y ago
I'm not really a crack at micro-optimizing C code, so can anyone here explain to me why the given function was written in the form it was?
Why not something like this:
int d[16];
int SATD (void)
{
int satd = 0, dd, k;
for (k=0; k<16; ++k) {
dd = d[k];
satd += (dd < 0 ? -dd : dd);
}
return satd;
}
Does this generate slower code?
- cygx 14y agoDoes this generate slower code? No, or at least not with an optimizing compiler. It was probably more about writing compact code. Personally, I'd have used abs() and gotten rid of the temporary variable dd altogether: int SATD (void) { int satd = 0, k; for (k = 0; k < sizeof d / sizeof *d; ++k) satd += abs(d[k]); return satd; }
- mansr 14y agoGood thinking. Most modern compilers will recognise abs() and generate efficient code.
- Someone 14y agoMy guess would be: yes, that generated slower code, at the time the code was written. A C compiler from the 1970's was almost little more than a glorified pattern matcher. It easily could emit different code for "i += 1" vs "++i" vs "i++" (and that would not be a problem, as the C programmers used C as a replacement for assembly, and there, "INC R" is different from "ADD #1,R") To check whether that theory holds water, one would have to check older SPEC benchmarks, to see where this fragments came from.
- mansr 14y agoThe code in question comes from the reference implementation of the H.264 video codec. What scraps of code this was cobbled together from is anyone's guess.
- cygx 14y agoI tracked it down to http://iphome.hhi.de/suehring/tml/download/old_jm/ http://iphome.hhi.de/suehring/tml/download/old_jm/ The bug is in version 9.3 used by SPEC CPU2006, but no longer in version 9.5. The current version is 18.4...