I want to write a program that performs heavy computations and I want it to be as fast as possible, so I choose C to be the language. Nevertheless, I was told that in spite of its simplicity and high efficiency one can easily make things slow instead of fast AND get himself absolutely nailed into his feet.

Okay, so if I do not want my feet to be shot off I can consider adding extra static checks inside my code as well as using code tools, static analyzers and such (no one wants bugs). On the other hand, checking codes eat processor time. How do I reach proper balance?

  • "checking codes eat processor time" Are you thinking static checks degrade runtime performance? If so, you haven't understood static checks. Besides, how to write performant code is too broad, let alone how to avoid bugs. You should have a look out for branch prediction and cache locality, those might bite you when you least expect it. And of course, be aware of the runtime performance cost of your abstractions and the complexity of the algorithm and data structures you choose. Always profile. If you can do less and get the same result do that. And caching is hard. Now, can you narrow this? – Theraot Apr 29 at 22:46
  • Mentioning cache locality and branch predictions gives some pivots to start searching. I expected something like that, mentioning general crucial concepts. How to squeeze performance out of some given code blocks is a narrower question, but not too useful for me now. – StaticZero Apr 29 at 22:55
  • 3
    The first rule of performance optimization: You don't need it. The second rule of performance optimization: You don't need it (yet). The third rule of performance optimization: Measure first, then optimize. – Robert Harvey Apr 30 at 0:13
  • 1
    Hi Static Zero, askers on this site are expected to make some research before they ask, show us what they found and why it did not suit their needs. I entered just "C optimization strategies" at Google and got several results, top result was this one: Optimization of Computer Programs in C. So assuming you did the same: why exactly does this article not fully answer your question? – Doc Brown Apr 30 at 5:56

You don’t get faster code by choosing a language. You get faster code by making an implementation, finding what makes it slow, improving it, letting it inspire better algorithms, and repeating. I’ve had cases where I managed to improve what I thought was a good approach by a factor 100,000. Choosing a worse language would have prevented that.

| improve this answer | |

Profiling and Optimisation

Write a program in any language.

Use a profiler to identify the sections of code which have the most time spent in them, or to identify objects most frequently interacted with.

Consider how to reduce the amount of time being spent there:

  • change the algorithm to something that uses less brute force
  • change the algorithm to trade memory for speed. (using caches, etc...)
  • change the algorithm to take advantage of the many processors cores, or even offload to a specialist circuit such as the gpu, or fpga.
  • change the data structure to align it the cpu cache line and size.
  • change the data structure to remove unused space
    • by using smaller fields,
    • by packing the struct more suitable,
    • by using nan tagging and pointer tagging techniques.
  • change the language to something with few layers of interpretation between what you write and what is executed. (for c this would be assembly)
    • This avoids many compilers/jits/interpreters but also avoids the tricks inside them to squeeze out performance, and tends to sacrifice portability across machines.
    • If you do go with assembly for a given optimisation, always have a non-assembly version of this code available to baseline against and for portability.
    • Similar advice goes for offloading to the gpu/fpga, keep a cpu version for baselining/portability (not every machine has a gpu/fpga).

Ensure that you run the program before and after each alteration to ensure that speed is improving in the section you are considering.

Rinse and repeat.

| improve this answer | |

Not the answer you're looking for? Browse other questions tagged or ask your own question.