C Language, Optimisation In C and Algorithm Develpment

Optimisation In C and Algorithm Develpment

Author	Message
Gary Maso #1 / 6	Optimisation In C and Algorithm Develpment Hi there, I am interested in Optimisation techniques for C language and am after literature or Web Sites, I am an applications programmer working on financial db systems, but I understand that Optimisation should not really be playing a major role in my development process, but the following are some techniques that i may apply, contact me if this also interests you or i have missed something. A) Use I nteger and long data types wherever possible for math computations B) Avoid Real data types C) Keep Struct size <= Cache Size D) Inline functions E) Loop Unrolling F) Jamming I am also interested in how developers first conduct problem solving - when they are formulating a solution to a problem, I cannot tell how fast a module is until i see it run, is this the same for you or different. I normally code the first solution that pops into my mind - then if it is slow once it works then I just code it, is this the same for you, is it possible that some of you can tell while the solution is being created in our minds that it will be inefficient the algo - or do we all need to test it thoroughly by running a working prog ? For applications programmers is Structure more important then speed efficiency - and should we really worry about speed when hardware speeds are doubling so quickly - what do you think ?? Thanks
Fri, 16 Feb 2001 03:00:00 GMT

Mike Smit #2 / 6	Optimisation In C and Algorithm Develpment Quote: > A) Use I nteger and long data types wherever possible for math >computations > B) Avoid Real data types This used to be more of an issue than it is today. Modern CPUs are nearly as fast with floating-point as with integer operations. Divides are still slower, but even this is often not too much of an issue with multi-execution-unit CPUs, if you can pair the divide with some other operation. -- Mike Smith. No, the other one.
Fri, 16 Feb 2001 03:00:00 GMT

Dann Corbi #3 / 6	Optimisation In C and Algorithm Develpment [snip] Patience please. Usenet posts may take a while to appear on your news server. -- Hypertext C-FAQ: http://www.eskimo.com/~scs/C-faq/top.html C-FAQ ftp: ftp://rtfm.mit.edu, C-FAQ Book: ISBN 0-201-84519-9 Try "C Programming: A Modern Approach" ISBN 0-393-96945-2 Want Software? Algorithms? Pubs? http://www.infoseek.com
Fri, 16 Feb 2001 03:00:00 GMT

Melk #4 / 6	Optimisation In C and Algorithm Develpment Mike Smith schreef: Quote: > > A) Use I nteger and long data types wherever possible for math > >computations > > B) Avoid Real data types > This used to be more of an issue than it is today. Modern CPUs are nearly > as fast with floating-point as with integer operations. Divides are still > slower, but even this is often not too much of an issue with > multi-execution-unit CPUs, if you can pair the divide with some other > operation. Ofcourse, even more modern cpu's have an out-of-order core so pairing isn't so much of an issue anymore (just mix all kind of different operations so all EU's/ports/whatever are kept busy all the time).
Sat, 17 Feb 2001 03:00:00 GMT

Mike Smit #5 / 6	Optimisation In C and Algorithm Develpment Quote: >Mike Smith schreef: >> This used to be more of an issue than it is today. Modern CPUs are nearly >> as fast with floating-point as with integer operations. Divides are still >> slower, but even this is often not too much of an issue with >> multi-execution-unit CPUs, if you can pair the divide with some other >> operation. >Ofcourse, even more modern cpu's have an out-of-order core so pairing >isn't so much of an issue anymore (just mix all kind of different >operations so all EU's/ports/whatever are kept busy all the time). Touch. ;-) -- Mike Smith. No, the other one.
Sun, 18 Feb 2001 03:00:00 GMT

Praveen Sreeniva #6 / 6	Optimisation In C and Algorithm Develpment I think it may be apt to quote Michael Jackson (not the singer) regarding optimization. He says, Novices : don't do it. Experts : don't do it, yet. Since it is commonly agreed that a program is read many more times than it is written, I think it is worthwhile making it more readable and fool-proof than to despair about its efficiency. Once a program is written, there are tools (profilers) that enable you to determine the most exercised parts of a program. This lets you focus on sections of code that may be improved. Once you have learnt how to improve a section, you must still keep the earlier version because performance improvements often lead to a loss of readability. I think there is a book called, "Writing efficient programs in C" by Bentley (?). You may want to read it. Also, take a look at "Programming Pearls". You may also find Michael Jackson's book on program design for insights regarding optimization and efficiency Quote: > Hi there, > I am interested in Optimisation techniques for C language and am after > literature or > Web Sites, I am an applications programmer working on financial db systems, > but I understand that Optimisation should not really be playing a major role > in my development process, but the following are some techniques that i may > apply, contact me if this also interests you or i have missed something. > A) Use I nteger and long data types wherever possible for math > computations > B) Avoid Real data types > C) Keep Struct size <= Cache Size > D) Inline functions > E) Loop Unrolling > F) Jamming > I am also interested in how developers first conduct problem solving - when > they are formulating a solution to a problem, I cannot tell how fast a > module is until i see it run, is this the same for you or different. > I normally code the first solution that pops into my mind - then if it is > slow once it works then I just code it, is this the same for you, is it > possible that some of you can tell while the solution is being created in > our minds that it will be inefficient the algo - or do we all need to test > it thoroughly by running a working prog ? > For applications programmers is Structure more important then speed > efficiency - and should we really worry about speed when hardware speeds are > doubling so quickly - what do you think ?? > Thanks
Sun, 18 Feb 2001 03:00:00 GMT

Page 1 of 1

[ 6 post ]