Manual optimization in the past (C Language) [closed] - c

Question

Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 8 years ago.
Improve this question
Back in the 70s when C just started, I guess compiler level optimization wasn't that advanced like modern compilers (clang, gcc, etc...) and the computers themselves were limited hardware-wise, was it common to prefer optimizations at the source code level over readability?
Example:
int arrayOfItems[30]; // Global variable
int GetItemAt(int index)
{
return globalArrayOfThings[index];
}
int main()
{
// Code
// ... arrayOfItems intialized somewhere
// More code
GetSomethingByItem(GetItemAt(4)); // Get at index 4
return 0;
}
Now this can be optimized to this:
int arrayOfItems[30]; // Global variable
int main()
{
// Code
// ... arrayOfItems intialized somewhere
// More code
GetSomethingByItem(arrayOfItems[4]); // Get at index 4
return 0;
}
Completely omitting the functionGetItemAt and thus saving time by accessing the value straight from it's address instead of entering a function, creating a stack frame, accessing the value and pushing the result to some register. Do people used to prefer to write the second, 'optimized' version straight into the source code or use the first version so the code would be more readable?
I know that in this example you can use a processor to "mimic" this optimization (e.g #define GetItemAt(x) arrayOfItems[x]), but you get my point.
Also, maybe this exact optimization feature was present from the start, if so, I should find another example, suggestions are welcome.
TL;DR -
Was it common in the past to prefer optimizations at the source code level over readability?
Bonus question:
Are there optimizations that are included only so the source code can be more readable?

Answer 1

I don't think many developers have ever prefered optimization over readability, but sometimes it might be argued that there were optimizations that harmed readability but were necessary for performance. Something like Duff's Device (a loop unrolling optimization)
From
do { /* count > 0 assumed */
*to = *from++; /* "to" pointer is NOT incremented, see explanation below */
} while(--count > 0);
to
register n = (count + 7) / 8;
switch(count % 8) {
case 0: do { *to = *from++;
case 7: *to = *from++;
case 6: *to = *from++;
case 5: *to = *from++;
case 4: *to = *from++;
case 3: *to = *from++;
case 2: *to = *from++;
case 1: *to = *from++;
} while(--n > 0);
}
Of course, it turns out that compilers got smarter and it has been reported on the LKML that removing Duff's Device improved performance and reduced memory usage. From the linked wikipedia,
For the purpose of memory-to-memory copies (which was not the original use of Duff's device, although it can be modified to serve this purpose as described in section below), the standard C library provides function memcpy; it will not perform worse than a memory-to-memory copy version of this code, and may contain architecture-specific optimizations that will make it significantly faster
and from the LKML (in 2000)
... this effect in the X server.
It turns out that with branch predictions and the relative speed of CPU
vs. memory changing over the past decade, loop unrolling is pretty much
pointless. In fact, by eliminating all instances of Duff's Device from
the XFree86 4.0 server, the server shrunk in size by half a megabyte, and was faster to boot, because the elimination of all
that excess code meant that the X server wasn't thrashing the cache
lines as much.
As for optimizations that only improve readability, it would require that your code first be unreadable. Then anything that makes it more readable would seem to qualify. Finally, remember that premature optimization is the root of all evil.