Code Optimization
in [C++]
|
Prev: extern versus #include
Next: comparing iterators
From: Bartosz Wiklak on 20 Dec 2009 21:59 On 20 Gru, 15:47, "Bo Persson" <b...(a)gmb.dk> wrote: > Mathias Gaunard wrote: > > On 19 d�c, 14:45, ramblex <alexdul...(a)googlemail.com> wrote: > > >> You'd probably be better off searching for this sort of thing on > >> google. For example from 'C++ optimisation', the first result is > >>http://www.tantalon.com/pete/cppopt/main.htmseems to be roughly > >> what you're looking for. > > > This particular website looks more a list of bad ideas (two-phase > > initialization, limit exception handling, disable RTTI) than > > optimization techniques though. > > It starts by saying that the results are valid for VC++ 6.0 running > Windows 95 on a Pentium II. > > If you happen to have another configuration :-), you may have to run > the tests again to get the results for your platform. They would > probably be quite different. > > Bo Persson > Hi, take a look at http://www.linux-kongress.org/2009/slides/compiler_survey_felix_von_leitner.pdf >From Abstract: (citation) "People often write less readable code because they think it will produce faster code. Unfortunately, in most cases, the code will not be faster." -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: A. McKenney on 23 Dec 2009 15:58 On Dec 19, 9:44 am, Francis Glassborow <francis.glassbo...(a)btinternet.com> wrote: > Sadanand wrote: > > hi all, > > Can anybody please let me know how compiler optimize a C++ code? can > > you give me a simple example? which will help me to write more > > optimized code in all my working projects. > > Stop worrying about it. The chance that you can write code in such a way > that a compiler will optimise it better is too small to concern > yourself. Just write good readable code. Now if the performance is > inadequate profile it to find the bottlenecks and then address those. In > fact most of the time it is a matter of finding a better algorithm. > > Modern compilers can do quite extraordinary things when they optimise a > program (and that depends on whether you want a small program or a fast > one.) However, there are still things you can do to improve performance that don't amount to inventing a new algorithm. Mostly, they involve simplifying the code or not using features if you don't really need them. If there's a fancy, complicated way and a simpler way to do the same thing, prefer the simpler way unless you can justify using the fancier way. Some things I look for: 1. Avoid new and delete. If you can make an object a local (stack) variable or a member variable without making the code more complicated, do it. Believe it or not, I've seen stuff like { T *tp = new T; // code that uses *tp ... delete tp; } And stuff like class T { T2 *tp; ... T() : tp( new T), ... {} ~T() { delete tp; ... } ... }; is pretty common when class T { T2 t2; ... }; would be perfectly good. In my experience, new and delete (or malloc and free) are expensive, often expensive enough that memory pools are worth the trouble. A fortiori, if new/delete can be replaced with nothing at all, it's even better. 2. Avoid pointers. Use them if necessary, but keep in mind that pointers (and references) introduce aliasing issues. This makes debugging and (compiler) optimization harder. Keep in mind, for built-in types, copying is faster than using a reference. Probably also true for some classes. Anybody have other suggestions? -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Walter Bright on 31 Dec 2009 02:06 A. McKenney wrote: > Anybody have other suggestions? Yes: 1. Rule of thumb: less code executed == faster code. 2. Use a profiler. 3. Have a look at the assembler output of your compiler for the hot spots. My experience is if you're not willing to do (2) and (3), all the internet optimization advice will not help your code get faster. =========================================== Walter Bright Digital Mars http://www.digitalmars.com Free C, C++, Javascript, D programming language compilers -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Dave Harris on 31 Dec 2009 22:58 newshound1(a)digitalmars.com (Walter Bright) wrote (abridged): > 1. Rule of thumb: less code executed == faster code. > > 2. Use a profiler. > > 3. Have a look at the assembler output of your compiler for the hot > spots. I'd add, be aware of what operations cost, and especially the effect of the cache architecture. It's worth viewing the talk by Herb Sutter at: http://www.nwcpp.org/Meetings/2007/09.html He claims, for example, memory access times: L1 cache (32KB): 3 cycles L2 cache (4MB): 14 cycles DRAM (2GB): 200 cycles So memory that's not in cache can take 66 times longer to access than memory that is. How you organise your data may swamp any micro-optimisations the compiler may make. Eg a vector may be much faster than a linked list because it is more cache-friendly. These effects may not be obvious from looking at assembler output, or the nominal amount of code being executed. -- Dave Harris, Nottingham, UK. -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: tf on 4 Jan 2010 09:31
Dave Harris <brangdon(a)cix.co.uk> wrote: > I'd add, be aware of what operations cost, and especially the effect of > the cache architecture. It's worth viewing the talk by Herb Sutter at: > http://www.nwcpp.org/Meetings/2007/09.html > > He claims, for example, memory access times: > L1 cache (32KB): 3 cycles > L2 cache (4MB): 14 cycles > DRAM (2GB): 200 cycles On that note, Ulrich Drepper has an excellent article, "What Every Programmer Should Know About Memory". A quick google brings it up here: http://people.redhat.com/drepper/cpumemory.pdf -tom -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] |