Reply-To:	<arfa AT clara DOT net>
From:	"Arthur" <arfa AT clara DOT net>
To:	"DJGPP Mailing List" <djgpp AT delorie DOT com>
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
In-Reply-To:	<Pine.SUN.3.91.980809155933.29413A-100000@is>
Importance:	Normal

> > 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

- Raw text -