Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!overload!dillon From: dillon@overload.Berkeley.CA.US (Matthew Dillon) Newsgroups: comp.sys.amiga.programmer Subject: Re: Lemmings - a tutorial Part V (last) Message-ID: Date: 1 Apr 91 19:57:15 GMT Organization: Not an Organization Lines: 103 >In article <1991Apr1.020748.26863@mintaka.lcs.mit.edu> rjc@geech.gnu.ai.mit.edu (Ray Cromwell) writes: >_main: ; (cycles) > lea _buf,a1 ; 8 > lea LC0,a0 ; 8 > tstb a0@ ; 8 > jeq L5 ; 8 >L4: > moveb a0@+,a1@+ ; 14*12 > tstb a0@ ; 14*8 > jne L4 ; 13*10+1*8 >L5: > rts ; 16 >.comm _buf,20 > > >;/* test.s produced by me */ ; (cycles) > lea text(pc),a0 ; 8 > lea buf(pc),a1 ; 8 >.loop move.b (a0)+,(a1)+ ; 14*12 > bne.s .loop ; 13*10+1*8 > rts ; 16 >text dc.b 'This is a test',10,0 >buf ds.b 20 > >NO COMPARISON DUDE! GCC makes 3 totally wasted instructions, and one of >them is inside your loop. Try an example with nested loops and your >wasted clock cycles become a geometric progression. Multiply the kind YOU ARE MISSING THE #@%$#!% POINT Of *COURSE* you can write faster assembly by hand... but your routine is ONLY 28% faster than GCC compiled code? Do you understand the point we are trying to make? Perhaps it isn't clear.... the point is that in C you have a LOT MORE TIME to think about and redo the algorithms you originally chose -- using a better algorithm can yield an order of magnitude increase in performance, turning that 28% deficit into an 800% surplus, all because you can write the C code much faster and make *major* changes to it, like completely replacing core algorithms, much faster than you could do in assembly. How much time do you spend on one piddling 50 line assembly routine to optimize it? Quite a long time I would expect. Now, of *COURSE* a tight loop should be done in assembly... even C programmers will write really tight loops in assembly because that is where the compiler usually screws up in terms of outputting efficient code... where one instruction can make the difference. It's everything ELSE that can be written in C without loosing performance. You can count cycles all day but in the end its the algorithm that counts, because you can always optimize tight items in assembly... maybe 5% of your program would be in assembly while the rest would be in C, EASILY have the same performance, and take much less time to write, debug, tweak, reorganize, and get out the door. >Just think, the OS ROM routines are written in 'C' and compiled with >a lesser compiler than gcc (5 years ago). The 1.3 OS was compiled with greenhills, I believe, which is a pretty good compiler. Would you rather the OS not have come out at all? Do you know how many YEARS it would take to write all that stuff in hand assembly? much less debug it and enhance it. Can you image doing arbitrary layers clipping entirely in assembly? What a waste of time! >> Also, it's not the language but the algorithm that is responsible for >>how fast a routine runs. Compare a C coded Boyer-Moore string search >>with an Assembly coded brute-force byte by byte search, the C code would >>probably win without optimizations turned on. >> > >You should compare apples to apples. Compare your Boyer-Moore string search >in assembler language with the one in 'C' on the Amiga. How about comparing >an assembler coded Boyer-Moore string search against a 'C' coded brute-force >byte by byte search? You'd complain it's not fair either. Again, you are missing the point... he IS comparing apples to apples. Not perhaps with that specific example, but in the more general sense. You only have so much time to write your game.. what you can do in a month with C would take a year in assembly, so you have a lot more time to think about the algorithms you choose writing the complex parts in C than you have writing it all in assembly.. a LOT more time. The foregone conclusion is that you would have time to develop some really hot algorithms writing in C an order of magnitude better than the algorithm you never had time to change written entirely in assembly. 28% is nothing compared to finding an algorithm that gives you an order of magnitude better performance, and the chance of finding such an algorithm is incredibly high when you have the time to think about it. -Matt -- Matthew Dillon dillon@Overload.Berkeley.CA.US 891 Regal Rd. uunet.uu.net!overload!dillon Berkeley, Ca. 94708 USA