bairds@eecs.cs.pdx.edu (Shawn L. Baird) (04/05/91)
I think jumping into assembly code where not needed can be a treacherous mistake. One method of avoiding wasting time on unnecesaary (who said comp. science majors had to be able to spell?) optimizations is to profile your code. Write some timer routines and throw it in with Forbid()/Disable() or whatever works for your project. Then go look at the slower code and see what you can do to speed it up. If you're lucky, you get to the point where you don't need more speed because the hardware or the user is slowing you down. And that's everything you'll ever need to know about optimization, and you heard it here first. ;) Seriously though, profile, profile, profile. Don't assume which part of your code is slowing you down. It's easy to get it wrong. --- Shawn L. Baird, bairds@eecs.ee.pdx.edu, Wraith on DikuMUD The above message is not licensed by AT&T, or at least, not yet.
barrett@jhunix.HCF.JHU.EDU (Dan Barrett) (04/06/91)
In article <2243@pdxgate.UUCP> bairds@eecs.cs.pdx.edu (Shawn L. Baird) writes: >Seriously though, profile, profile, >profile. Don't assume which part of your code is slowing you down. It's >easy to get it wrong. Naah, it's easy to get it right. It's always scanf(). :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) Dan //////////////////////////////////////\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\ | Dan Barrett, Department of Computer Science Johns Hopkins University | | INTERNET: barrett@cs.jhu.edu | | | COMPUSERVE: >internet:barrett@cs.jhu.edu | UUCP: barrett@jhunix.UUCP | \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\/////////////////////////////////////
nsw@cbnewsm.att.com (Neil Weinstock) (04/06/91)
In article <2243@pdxgate.UUCP> bairds@eecs.cs.pdx.edu (Shawn L. Baird) writes: [ ... ] >And that's everything you'll ever need to know about optimization, and >you heard it here first. ;) Seriously though, profile, profile, >profile. Don't assume which part of your code is slowing you down. It's >easy to get it wrong. I agree 100%. Now please find me a profiler that works with Manx 5.0! - Neil --==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==-- Neil Weinstock @ AT&T Bell Labs // What was sliced bread att!edsel!nsw or nsw@edsel.att.com \X/ the greatest thing since?
mcmahan@netcom.COM (Dave Mc Mahan) (04/10/91)
In a previous article, bairds@eecs.cs.pdx.edu (Shawn L. Baird) writes: >I think jumping into assembly code where not needed can be a treacherous >mistake. Yes, it can be. Once you have taken the leap you usually can't go back and future modifications are difficult, especially when they have to be performed by others. > One method of avoiding wasting time on unnecesaary optimizations is to >profile your code. Write some timer routines and throw it in with >Forbid()/Disable() or whatever works for your project. Then go look at >the slower code and see what you can do to speed it up. This is an excellent technique and should always be tried first. However, it is not the be-all/end-all when some types of optimizations are needed. There are certain operations that are just plain math or compute intensive and just plain require at least some feedback from the assembly language output of a compiler to get right. I try to use a profiling method as much as possible and stop when I get it good enough, but there are times when I KNOW due to the operation being performed that code just can't go any faster without some kind of examination of compiler output and possibly jumping in to assembly language to save a few critical cycles of time. I am currently implmenting a low pass smoothing filter for ECG's at work on a 68000. The operation is going to consume at least 25% of the total CPU cycles on the processor and other things need to be done in addition to that one operation. I did manage to write the code in 'C', but I was seriously concerned about having enough CPU time left over. There just aren't that many ways to do intensive integer multiplication besides the use of the muls instruction. I had to cut down overhead in other portions of the code to allow enough time. Examining the assembler output from my compiler was of great help in selecting the methods I used. I guess the bottom line is: Keep it simple, but know what is going on. If you need the cycles, avoid writing actual assembler code before you have exhausted all other approaches. Profiling is a big help, but just directs you in where to start thinking about different algorithms. Sometimes you just have to do what you've got to do. > If you're >lucky, you get to the point where you don't need more speed because the >hardware or the user is slowing you down. Luck has little to do with it. If you have a task that can be done and you are smart enough, the result is deterministic: it will work. If the task is just impossible or you aren't smart enough, again the result is deterministic: it won't work. >Seriously though, profile, profile, >profile. Don't assume which part of your code is slowing you down. It's >easy to get it wrong. Quite correct!!! It's amazing how wasteful some simple little line can be if it is in the wrong loop! > Shawn L. Baird, bairds@eecs.ee.pdx.edu, Wraith on DikuMUD -dave -- Dave McMahan mcmahan@netcom.com {apple,amdahl,claris}!netcom!mcmahan
mwm@pa.dec.com (Mike (My Watch Has Windows) Meyer) (04/10/91)
In article <1991Apr10.060055.2829@netcom.COM> mcmahan@netcom.COM (Dave Mc Mahan) writes: > One method of avoiding wasting time on unnecesaary optimizations is to >profile your code. Write some timer routines and throw it in with >Forbid()/Disable() or whatever works for your project. Then go look at >the slower code and see what you can do to speed it up. This is an excellent technique and should always be tried first. However, it is not the be-all/end-all when some types of optimizations are needed. Actually, it's should be the first step of _any_ optimization. Even if you KNOW what operations are taking to much time, you should stop and prove it. Your intuition is frequently wrong. There are certain operations that are just plain math or compute intensive and just plain require at least some feedback from the assembly language output of a compiler to get right. Actually, once you know that's what's going on, you should see how big a table of precomputed values would be. Don't forget that interpolating intermediate values can save you orders of magnitude on the table size. No amount of assembler tweaking will make calculating values faster than an indexed move. I guess the bottom line is: Keep it simple, but know what is going on. No - keeping it simple may not be the way to make it fast; some algorithms are inherently complex. Making a simple algorithm complex is bad, as those tend to be the assembler-tweaking type wins, not the wins you get from going to a faster algorithm. Of course, to know what is going on, you need to profile the code, and know the behavior of the algorithms involved. <mike -- He was your reason for living Mike Meyer So you once said mwm@pa.dec.com Now your reason for living decwrl!mwm Has left you half dead