useful tips on how to write your C codes more efficiently

[eyh5]

Hi,

I'm writing some C codes to run simulations.
I'm wondering if there is a website that may contain useful information
on how to make one's code run more efficiently and in a
computational-time-saving manner. Specifically, what I'd like to know
is if there're any useful tips about writing your codes more
efficiently. One such useful tip is that we can use the "switch"
statement instead of multiple "if-else" statements; another is that if
you wish to put some information in an array, and that you foresee the
array is not going to be too big, then it probably pays to just define
a fixed size array instead of using "malloc."

So, I'm wondering if anybody knows of a website that may contain
such helpful tips to help a mid-level programmer like me write codes
better.

Thanks.

-Ed

 

[junky_fellow]

Hi,

I'm writing some C codes to run simulations.
I'm wondering if there is a website that may contain useful information
on how to make one's code run more efficiently and in a
computational-time-saving manner. Specifically, what I'd like to know
is if there're any useful tips about writing your codes more
efficiently. One such useful tip is that we can use the "switch"
statement instead of multiple "if-else" statements; another is that if
you wish to put some information in an array, and that you foresee the
array is not going to be too big, then it probably pays to just define
a fixed size array instead of using "malloc."

So, I'm wondering if anybody knows of a website that may contain
such helpful tips to help a mid-level programmer like me write codes
better.

Thanks.

-Ed

Have a look at the following link:
http://www.eventhelix.com/RealtimeMantra/Basics/OptimizingCAndCPPCode.htm

In fact I also asked this question on this newsgroup and most of them
suggested that "profiling is the best technique".

 

[Mark F. Haigh]

Hi,

I'm writing some C codes to run simulations.
I'm wondering if there is a website that may contain useful information
on how to make one's code run more efficiently and in a
computational-time-saving manner. Specifically, what I'd like to know
is if there're any useful tips about writing your codes more
efficiently.

1. Choose algorithms with appropriate complexity for the task at hand.
2. Code the algorithms simply and portably.
3. Compile the code with the appropriate optimization flags. Run it.

Is it fast enough? Probably. If it's not, then:

4. Profile the code. Identify the main bottlenecks.
5. Refactor the bottleneck code. Repeat #4 until no further gains are
made.

If it's still not fast enough, then:

6. Take advantage of platform-specific features. Isolate
platform-specific code.

7. Take advantage of CPU-specific instructions via inline assembly
code (which itself is not part of C, but a common extension). Again
isolate as much as possible.

One such useful tip is that we can use the "switch"
statement instead of multiple "if-else" statements; another is that if
you wish to put some information in an array, and that you foresee the
array is not going to be too big, then it probably pays to just define
a fixed size array instead of using "malloc."

You'd be surprised. On many fast modern machines, it won't make as big
of a difference as you think, unless you're executing it in a tight
loop. Write simple and idiomatic C code.

So, I'm wondering if anybody knows of a website that may contain
such helpful tips to help a mid-level programmer like me write codes
better.

If your goal is to write C code better, simply read comp.lang.c daily,
code actively, and refactor relentlessly.



Mark F. Haigh
(e-mail address removed)

 

[Paul Mesken]

Hi,

I'm writing some C codes to run simulations.
I'm wondering if there is a website that may contain useful information
on how to make one's code run more efficiently and in a
computational-time-saving manner. Specifically, what I'd like to know
is if there're any useful tips about writing your codes more
efficiently. One such useful tip is that we can use the "switch"
statement instead of multiple "if-else" statements; another is that if
you wish to put some information in an array, and that you foresee the
array is not going to be too big, then it probably pays to just define
a fixed size array instead of using "malloc."

So, I'm wondering if anybody knows of a website that may contain
such helpful tips to help a mid-level programmer like me write codes
better.

The following document contains some helpfull tips :

http://www.agner.org/assem/pentopt.pdf

Chapter 3 is about optimizing C++ (but lots of it also goes for C).
Chapter 2 is also quite helpfull.

Of course, it's important to use the best algorithm before tweaking it
but in order to tweak one needs to know some basics of computer
architecture (knowing about how caches work, branch prediction,
pipelines and the relative costs of instructions).

In the end, you might need to resort to Assembly programming for the
hotspots in your program (of course, it isn't portable).

 

[Anonymous 7843]

5. Refactor the bottleneck code. Repeat #4 until no further gains are
made.

You are using the word refactor in an odd way. Unless I am sadly
misinformed, refactoring is more about changing source code
to improve readability and maintainability, and to remove multiple
implementations of the same idea throughout a large project.

The wiki for refactoring, http://en.wikipedia.org/wiki/Refactor
has a list of useful kinds of refactoring and none of them specify
efficiency, speed, or execution time as benefits.

I admire your drive to refactor ("it's a good thing"), but moving
code around in and of itself will not make anything run faster. Some
optimizations are infact unfactoring--loop unrolling, manual inlining,
and grouping functions or data for cache friendliness for example.

The rest of your advice was quite good, so I'm just nitpicking.

 

[Christian Bau]

You are using the word refactor in an odd way. Unless I am sadly
misinformed, refactoring is more about changing source code
to improve readability and maintainability, and to remove multiple
implementations of the same idea throughout a large project.

The term "refactoring" is generally used for _anything_ that rearranges
the code in any way without changing its meaning. Refactoring should
obviously only used when it improves _something_ (even if it only
improves job security), but the thing that is improved may very well be
performance at the cost of readability and maintainability.

 

[Paul Mesken]

I admire your drive to refactor ("it's a good thing"), but moving
code around in and of itself will not make anything run faster. Some
optimizations are infact unfactoring--loop unrolling, manual inlining,
and grouping functions or data for cache friendliness for example.

Actually, moving code around may improve performance if it breaks up
dependancy chains. In today's pipelined architectures, this can speed
up things considerably.

Of course, breaking up dependancy chains has a way to make code less
readable

 

[Malcolm]

One such useful tip is that we can use the "switch"
statement instead of multiple "if-else" statements; another is that if
you wish to put some information in an array, and that you foresee the
array is not going to be too big, then it probably pays to just define
a fixed size array instead of using "malloc."

These sorts of tips are of limited use. In the inner loop of a
computationally intensive program, it might be the case that you can get a
worthwhile performance increase by replacing an if .. else ladder by a
switch, or a call to malloc() by a fixed size array. It depends on the
compiler.

The first thing you should do is look at the algorithm. Sometimes you can
reduce the big O running time of the algorithm - the classic case is
replacing bubble sort which is O(N^2) with qsort() which is O(Nlog N). In
other cases you can get rid of big constant factors, for instance
calculating the length of string once and storing it rather than calling
strlen() twice.

The main reason most real programs run too slowly, however, is time spent
reformatting data and going through layers of indirection. Here there is a
tradeoff between readability and testability, and perfomance. For instnace,
to calculate a standard deviation, the natural thing would be to write a
function called stdev() which takes an array of doubles as an argument.
However you might want the standard deviation of some numbers which are low
integers, and members of a bigger structure. So calling malloc() to allocate
a temporary array, passing through to convert the integers to doubles,
calling stdev(), and then calling free() to get rid of the array, is a big
overhead. By writing a customised routine, you can probably double
performance.

A related issue is hardware interaction. It is less of a problem these days,
but in the old MS DOS days you weren't supposed to write directly to screen
memory, but everyone did, because using the conio functions was just too
slow. There is often a compromise between going through layers of
indirection so that your program works well with other programs, and
accessing things directly for speed.