Thread: fast code?

> Apparently this type is optimized for floating point stuff.
But unless all your program does is floating point to excess, it's not likely to help you.

> but there must be more info about this stuff. Like having the compiler unroll loops...
For those not reading the manual, it's -funroll-loops
gcc has a vast number of options, and many of them are a two-edged sword. Sometimes, they make things worse.

> (I compile with gcc on Mac OS X and I plan on always using the -std=c99 flag.)
Then you should also check out the -pg option and the gprof program

When you have a completed program, and a representative set of input data, then you can start to tackle the optimisation problem. Trying to do anything before then is really a waste of time, because all you do is make guesses. For all you know, the program could be quick enough when you've finished anyway so there would be no real point.

You make real measurements with a real program and real data, and analyse where the time is being spent (this is what gprof will tell you).

You then look at the busy areas of the code and decide what (if anything) can be done about it. Then you can make a controlled change and rerun the tests, and compare the results to see if your change had any positive effect.

http://win32.planet-d.net/opti/opti_c.htm
If you manage to take care of the first two points, various gcc options will take care of the rest.
Read the gotcha's at the end to determine how much of your time you should spend optimising.

Here's another example, if your program is a big number cruncher which takes an hour to run, and you can save 5 minutes, its probably not worth optimising. Sure 5 mins sounds a lot, but users are just going to run it and goto lunch knowing that it will take about an hour.