Reply-To: From: "Arthur" To: "DJGPP Mailing List" Subject: RE: should i bother learning asm?? or just learn dx? Date: Sun, 9 Aug 1998 15:44:15 +0100 Message-ID: <000101bdc3a4$2e056400$7a4d08c3@arthur> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit In-Reply-To: Importance: Normal Precedence: bulk > > GCC is good at optimising, but the way that C is structured, a fully optimised > > program will still not be as optimised as one written in ASM from scratch. For > > instance, writing a simple "hello world" program in DJGPP will produce > code ~50k in > > size with full optimisation. In ASM, you can get it down to less ahan 5k. > > IMHO, this example doesn't demonstrate anything. Moreover, I submit that > using such an example is a Bad Thing, since it tricks newbies into wrong > ideas. Here's why. > > 1) Size optimizations and speed optimizations are different and > usually conflict with each other. This thread began with talk about speed > optimizations. Actually, this thread began with programming in ASM. In general, speed and size are not the same optimisation, yes. I take your point. > 2) The size savings that you are boasting are an illusion: they are > just a constant overhead of the DJGPP startup code and library functions > called by it. In other words, a 2KB-long program and a 2MB-long one will > both suffer from the same overhead. In particular, this overhead has > nothing to do with the code generated by GCC from your C source. Exactly. I was trying to get this point across. There is very litle overhead in an ASM program. > > No it's not necessary, and on the PC it's very hard to learn. But note that > > professional programmers use hand-optimised ASM frequently - especially > in graphics > > code and interrupt routines. > > Professional programmers use the following 2 Golden Rules of Code > Optimization: > > Rule no. 1: Don't optimize. > > Rule no. 2: Don't optimize yet. > > In other words, optimizations are the *last* stage of the development > process, and they *must* be preceeded by profiling the code. It is a > well-known fact that trying to guess which part of the code is the best > candidate for optimizations by just looking at the source usually leads > to wrong guesses. The trade literature is full of stories from the > trenches about people who optimized a function only to find out that it > had no effect on the program speed because it is only responsible for 5% > of the total run time. But optimising is different to using ASM for routines, which is what this thread was about. Almost every game has some ASM in there somewhere. Anyway, isn't it about time they optimised their code? By the looks of some of today's games, they havn't thought of optimising until after their deadline. Hark back to the good old days of the C64, A500, Atari ST. Programmers then used to spend 50% of the time writing the game and 50% of the time optimising it (yes, after they'd written it). For that reason most games ran like the clappers, and pushed the hardware to the very limits. I (along with many others who have come across to the PC from these platforms) have trained myself to do this. I have no intention of considering a game finished unless I can be sure that I've got it running as efficiently as I can. It's a habit, and a good one because I frequently double or triple the speed of my programs by doing so. > Also, a conventional wisdom has it that rewriting a function in assembly > will usually speed it up by a factor of 2, sometimes up to 4. If you > need more than that, you will have to change the algorithms, data > structures, or the entire program design. Yup, exactly. I re-write my code frequently. > As to use of assembly in interrupt routines--this is mostly done not > because of speed concerns, but because some bookkeeping required from an > interrupt function cannot be done in C. Yeah, I wasn't on about speed for that part. There are also practical reasons for including ASM in your code. James Arthur jaa AT arfa DOT clara DOT net ICQ#15054819