C Language, Optimisation

Optimisation

Author	Message
Ben Bree #1 / 10	Optimisation I need to highly optimise a large piece of code and maintain ANSI compatibility. I know that I can use 'inline' on small functions, and use the '?' to replace certain 'if' blocks. What other general things can I do? (I know it's hard to answer without seeing the code). Thanks for any help!!!
Mon, 11 Aug 2003 04:35:00 GMT

-hs- #2 / 10	Optimisation Quote: >I need to highly optimise a large piece of code and maintain ANSI >compatibility. >I know that I can use 'inline' on small functions, and use the '?' to >replace certain 'if' blocks. What other general things can I do? (I know >it's hard to answer without seeing the code). Let your compiler do micro optimisations. Try to profile you code to measure where is the time eaten. Once you know, work on a better algorithm. -- -hs- Tabs out, spaces in. CLC-FAQ: http://www.eskimo.com/~scs/C-faq/top.html ISO-C Library: http://www.dinkum.com/htm_cl FAQ de FCLC : http://www.isty-info.uvsq.fr/~rumeau/fclc
Mon, 11 Aug 2003 05:31:10 GMT

Gergo Bara #3 / 10	Optimisation Quote: > I need to highly optimise a large piece of code and maintain ANSI > compatibility. > I know that I can use 'inline' on small functions, and use the '?' to > replace certain 'if' blocks. What other general things can I do? (I know > it's hard to answer without seeing the code). See http://www.ontek.com/mikey/optimization.html for optimizing tips after you've determined if and where it is too slow. Gergo -- Include me out.
Mon, 11 Aug 2003 06:57:49 GMT

Chris Ke #4 / 10	Optimisation On Wed, 21 Feb 2001 20:35:00 -0000, "Ben Breen" Quote: >I need to highly optimise a large piece of code and maintain ANSI >compatibility. You need to pick a better algorithm. I would recommend tracing the code in your head and see which parts are likely to cause bottleneck (profiling software can be useful, but cross-platform results may be different). Replace cumbersome data structures with faster ones (i.e. a list with a binary search tree), and make sure you're not doing unnecessary access to memory or (especially) disks. Quote: >I know that I can use 'inline' on small functions, and use the '?' to >replace certain 'if' blocks. Declaring certain variables as "register" could improve performance, but likely not by much. "inline" is C99 and may not be supported on all platforms (but a close equivalent can be obtained by using preprocessor macros). Some compilers will automatically inline functions for you. "?" instead of "if" is not likely to produce any speed improvements, and theoretically it could even slow down the program (you never know what a compiler will do). It's best to let the compiler fuss with those small details and concentrate on the algorithms and data structures. -Chris
Mon, 11 Aug 2003 06:39:36 GMT

Dan P #5 / 10	Optimisation Quote: >I need to highly optimise a large piece of code and maintain ANSI >compatibility. >I know that I can use 'inline' on small functions, The currently implemented ANSI C standard does NOT support "inline". Quote: >and use the '?' to replace certain 'if' blocks. The only thing this is likely to buy you is less readable source code. There is no good reason for the conditional operator to result in faster code than an if statement. Quote: >What other general things can I do? (I know >it's hard to answer without seeing the code). Optimise your algorithms, be as cache-friendly as possible, learn how to use the optimisation options of your compiler(s). Dan -- Dan Pop CERN, IT Division Mail: CERN - IT, Bat. 31 1-014, CH-1211 Geneve 23, Switzerland
Mon, 11 Aug 2003 08:53:10 GMT

Willam Hughe #6 / 10	Optimisation Quote: > I need to highly optimise a large piece of code and maintain ANSI > compatibility. Be warned that what you are trying to do may not be easy, and may not be posssible. On the other hand [1] you may be able to get considerable speed increase with very little work. Also be warned that speed and ANSI compatibility may turn out to be trade offs. Often you may have to do things like #ifdef NT_INTEL ...... #elif .... #elif SOLARIS_SPARC .... #elif LINUX_INTEL .... #elif LINUX_SPARC ...... #else <you already have something that works, it may not be fast but it works> #endif Ugly, but it can be effective. First PROFILE Even if you do not have profiling tools, a few well placed printf's (followed by fflush's) can often pinpoint where a program spends its time. It is very important to profile, because quite often a program will spend most of its time in only a small percentage of the code (and where a program spends its time is often very surprising). If you don't profile, you can waste a lot of time speeding up code that has no practical impact on the run time. Make sure you have an optimizing compiler. Make sure you are using the riight level of optimization (Try using a different compiler (get gcc for your platform, it can be faster than comercial compilers) ) If you can, set up a tool so you can watch the CPU usage while your program runs. This can be a great help in determining whether the program is held up by the CPU (CPU bound) or held up by something else, usually I/O (i/o bound). See up a test run. Whenever you try something, test to make sure you still get the same answer, and to see if it actually helps. Quote: > I know that I can use 'inline' on small functions, Wel, if you want to be ansi (C89) compatible, then you can't use inline. Even if you have a compiler that recognizes inline, there may be no guaratees that adding "inline" will do anything. What you can do is wirte macros in place of functions, in effect forcing inlining. Don't bother unless your profile indicates that the function is called a lot, by functions that use appreciable time. Quote: > and use the '?' to > replace certain 'if' blocks. Unless you have a brain-dead compiler, this will make no difference at all (except perhaps making the code harder to read). If you do have a brain- dead compiler, you should be working on replacing the compiler, not tweaking the code. Quote: > What other general things can I do? (I know > it's hard to answer without seeing the code). I will second the advice to look at http://www.ontek.com/mikey/optimization.html -William Hughes [1] Go not to the elves for advice, for they will say both no and yes.
Sat, 16 Aug 2003 09:42:27 GMT

Tor Rusta #7 / 10	Optimisation Quote: > > I need to highly optimise a large piece of code and maintain ANSI > > compatibility. > Be warned that what you are trying to do may not be > easy, and may not be posssible. On the other hand [1] Give me a large piece of code which I can't optimize on my plattform/compiler... I bet you can't. :-) Quote: > you may be able to get considerable speed increase > with very little work. > Also be warned that speed and ANSI compatibility > may turn out to be trade offs. > Often you may have to do things like > #ifdef NT_INTEL > ...... > #elif [...] Quote: > #endif > Ugly, but it can be effective. No this is terrible! This is something people use for e.g. inline assembler, not recommended at all. Quote: > First > PROFILE > Even if you do not have profiling tools, a few > well placed printf's (followed by fflush's) can > often pinpoint where a program spends its time. > It is very important to profile, because quite often > a program will spend most of its time in only > a small percentage of the code (and where > a program spends its time is often very > surprising). Not at all surprising to somebody... Quote: > If you don't profile, you can > waste a lot of time speeding up code > that has no practical impact on the run time. Yes, remove the bottlenecks, finally I agree on something here. :-) Quote: > Make sure you have an optimizing compiler. > Make sure you are using the riight level of optimization > (Try using a different compiler (get gcc for your platform, > it can be faster than comercial compilers) ) Really? Quote: > If you can, set up a tool so you can watch the CPU > usage while your program runs. This can be > a great help in determining whether the program > is held up by the CPU (CPU bound) or > held up by something else, usually > I/O (i/o bound). More measurements, yes that is good. Quote: > See up a test run. Whenever you try > something, test to make sure you > still get the same answer, and to > see if it actually helps. Yes, testing is important... Quote: > > I know that I can use 'inline' on small functions, > Wel, if you want to be ansi (C89) compatible, then > you can't use inline. Even if you have a compiler > that recognizes inline, there may be no > guaratees that adding "inline" will do anything. > What you can do is wirte macros in > place of functions, in effect forcing > inlining. Don't bother unless your > profile indicates that the function is called a lot, > by functions that use appreciable time. No. Focus on algorithms instead. Replacing functions with #define macro, is not a good advice, debugging and analyzing crash dumps gets hard. -- Tor <torust AT online DOT no>
Sat, 16 Aug 2003 07:04:38 GMT

Willam Hughe #8 / 10	Optimisation Quote: > > First > > PROFILE > > Even if you do not have profiling tools, a few > > well placed printf's (followed by fflush's) can > > often pinpoint where a program spends its time. > > It is very important to profile, because quite often > > a program will spend most of its time in only > > a small percentage of the code (and where > > a program spends its time is often very > > surprising). > Not at all surprising to somebody... Maybe. However, I have sometimes found the results of a profile surprising. If you are good enough to look at a program and spot the bottlenecks without profiling you certainly don't need my advice!! Quote: > > (Try using a different compiler (get gcc for your platform, > > it can be faster than comercial compilers) ) > Really? I once went to some trouble to replace gcc by a commercial compiler. The program slowed down by 10% (I have no idea how common this is, on the other hand if gcc is available for the target platform, it may be worth trying, if only to rule out compiler problems). Quote: > > Wel, if you want to be ansi (C89) compatible, then > > you can't use inline. Even if you have a compiler > > that recognizes inline, there may be no > > guaratees that adding "inline" will do anything. > > What you can do is wirte macros in > > place of functions, in effect forcing > > inlining. Don't bother unless your > > profile indicates that the function is called a lot, > > by functions that use appreciable time. > No. Focus on algorithms instead. Replacing functions with #define macro, is not > a good advice, debugging and analyzing crash dumps gets hard. Focus on algorithms first is good advice. This is where the big speed improvements are often found. However, the algorithms used may already be optimal (or near optimal) or the person doing the analysis may not have sufficient knowledge to assess the algorithms used. On the other hand, scanning a profile to find a function that may be usefully inlined, can be done even if you don't understand all of the code. Sometimes you have to inline, and depending on the compiler, you may have to use macros (using macros is the only way to force "inlining"). As for debugging, a good trick here is to keep the original function as well as the macro, then #undef the macro when you want/need to debug (this won't help in analyzing a crash dump from optimized code, but personally I rarely look at one) I note that I rarely use a macro in place of a function (partly because I usually find little difference in performance). But the few times when it does improve things, it can improve things a lot (e.g. address calculations). -William Hughes
Sat, 16 Aug 2003 13:52:49 GMT

Tim Princ #9 / 10	Optimisation Quote: > > > First > > > PROFILE > > > (Try using a different compiler (get gcc for your platform, > > > it can be faster than comercial compilers) ) > > Really? gcc does have a reasonable basic profiling capability. If your release compiler has a comparable profiling capability (few other Windows compilers do -- what are they hiding?), you should learn something by comparing them on the same work load. Quote: > I once went to some trouble to replace gcc by a commercial > compiler. The program slowed down by 10% > (I have no idea how common this is, on the > other hand if gcc is available for the > target platform, it may be worth trying, if > only to rule out compiler problems). What target platform doesn't have gcc available? I can think of a few where I wouldn't expect gcc to be competitive until more people have a chance at them, or I could admit I don't know of a gcc for native mode in XP beta 2 on IA-64, although there is one for several linux distros on IA-64.
Sat, 16 Aug 2003 11:32:30 GMT

Tor Rusta #10 / 10	Optimisation Quote: > > > First > > > PROFILE > > > Even if you do not have profiling tools, a few > > > well placed printf's (followed by fflush's) can > > > often pinpoint where a program spends its time. > > > It is very important to profile, because quite often > > > a program will spend most of its time in only > > > a small percentage of the code (and where > > > a program spends its time is often very > > > surprising). > > Not at all surprising to somebody... > Maybe. However, I have sometimes > found the results of a profile surprising. > If you are good enough to look at a program > and spot the bottlenecks without profiling > you certainly don't need my advice!! By reading through a program, many are able to spot bottlenecks. Such an ability comes with knowlege and expierence over a periode of time. If people get _very_ surprised, I think it might have to do with lack of expierence with analyzing measurements. Quote: > > > (Try using a different compiler (get gcc for your platform, > > > it can be faster than comercial compilers) ) > > Really? > I once went to some trouble to replace gcc by a commercial > compiler. The program slowed down by 10% > (I have no idea how common this is, on the > other hand if gcc is available for the > target platform, it may be worth trying, if > only to rule out compiler problems). I don't think you can generalize your expierence on this, AFAIK gcc is not the leading edge when it comes to optimized compilers. [...] Quote: > However, the algorithms used > may already be optimal (or near optimal) > or the person doing the analysis may not have sufficient > knowledge to assess the algorithms used. > On the other hand, scanning a profile > to find a function that may be usefully > inlined, can be done even if you don't > understand all of the code. If you don't understand the code and do inline through #define macro's, well then you get into even more trouble in case you need to track down bugs! Quote: > Sometimes you have to inline, > and depending on the compiler, you may have > to use macros (using macros is the only > way to force "inlining"). As for debugging, > a good trick here is to keep the original function > as well as the macro, then #undef the macro > when you want/need to debug (this won't I want to debug and test the same code that will run in production. Quote: > help in analyzing a crash dump from optimized > code, but personally I rarely look at one) Post-mortem analysis is very effective and may be the only practical method in tracking down hard to find bugs. Quote: > I note that I rarely use a macro > in place of a function (partly because > I usually find little difference in performance). > But the few times when it does improve > things, it can improve things a lot > (e.g. address calculations). Your inline method may be fine, if you are a student or have your own little private firm. However in a production environment, this tuning method should not be used. Note also that C99 add support for the inline keyword, so why not just wait? Three rules of tuning: 1. Don't do it. 2. Don't do it yet. 3. ...this was for experts only - so I forgot :-) -- Tor <torust AT online DOT no>
Sat, 16 Aug 2003 16:31:38 GMT

Page 1 of 1

[ 10 post ]