Dev.SN ♥ developers
Sections
Dev.SN
posted by
LaminatorX
on Saturday March 15 2014, @11:28PM
from the premature-optimization-is-the-root-of-all-evil dept.
from the premature-optimization-is-the-root-of-all-evil dept.
Subsentient writes:
"I've been writing C for quite some time, but I never followed good conventions I'm afraid, and I never payed much attention to the optimization tricks of the higher C programmers. Sure, I use const when I can, I use the pointer methods for manual string copying, I even use register for all the good that does with modern compilers, but now, I'm trying to write a C-string handling library for personal use, but I need speed, and I really don't want to use inline ASM. So, I am wondering, what would other Soylenters do to write efficient, pure, standards-compliant C?"
This discussion has been archived.
No new comments can be posted.
Writing Efficient C Code?
|
Log In/Create an Account
| Top
| 1000 moderator points
| 75 comments
| Search Discussion
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
I'm not a robot like you. I don't like having disks crammed into me... unless they're Oreos, and then only in the mouth.
-- Fry
(Score: 1) by fnj on Sunday March 16 2014, @02:07PM
Worst possible advice. Yes, SOME of it had SOME validity in the 1980s. It is all bunk now.
1) For compilers on the order of gcc and clang, and probably even Visual C++, the compiler writers know more than you could possibly imagine about creating efficient machine code.
2) For the 8088 you could do a lot with hand optimization. For CPUs of the last 20 years, you will only make the performance worse.
3) Do not fixate on optimization. Straightforward C code on today's CPUs is orders of magnitude better in performance than you will ever need or notice for almost all tasks, and the benefits of trickery and cleverness, if any, will be miniscule and far exceeded by a few months of CPU tech progress.
4) If the time comes that you ever do need to optimize, remember the 99%/1% rule. 99% of potential speed gains can be harvested by optimizing the critical 1% of the code.
5) Write for human comprehension and maintenance. Do not waste time trying to "help" the compiler be "smarter", and do not show off by using obscure tricks no one else is going to understand.
6) Staring at assembly level compiler output isn't going to do crap for code efficiency. The days when a table of individual instruction timing values told you anything of value, or was even possible to create, are long gone. Pipelining, out of order execution, speculative branch prediction, and the like are the order of the day.
7) Leverage existing libraries. They have been through more debugging using more distributed brain power than anything you write is ever going to get.
(Score: 0) by Anonymous Coward on Sunday March 16 2014, @02:34PM
Citation needed. Who are these superhuman compiler gods who have powers of logic comprehension beyond mere mortals like us?
(Score: 1) by smellotron on Sunday March 16 2014, @04:30PM
When optimizing, a large part of the value in inspecting the compiler-generated object code is in identifying pessimizations that the compiler was forced to make to follow the language standard. It is very common in code that I write (not games, but still latency-sensitive) that some trivial reordering of operations in the C code will reduce or remove stack usage, or replace a nested function call with a tail call. Especially because compiler writers tend to be the sharpest optimizers in the room, there is value in double-checking their output to detect data-dependency/optimization bugs in your code.