Re: ASSEMBLY vs C(++)

W!cked (nop05288@mail.telepac.pt) wrote:
: I think if u succefly
: wrote a program in assembly, and as long as it was a good coder, the
: game/application would b much faster, also different versions could be
: optimized for different CPU's (ie: DX Pentium, Cyrix, whatever!).


One should not over-estimate the amount of time one can get by
hand-coding routines in assembly. Current compilers have quite
efficient optimizers, and the way they allocate CPU registers is
usually quite efficient.


To me, hand-writing assembler is only justified when you need to write
very fast routines (such as polygon filling routines, encryption
routines...) that access data in ways that are not well handled by
compilers (such as tweaking bits or playing neat tricks with the carry
bit of the state register...).


Assembler IS indeed a must for such tasks.


: [This is an ancient argument. You can usually tweak small routines so
: they're faster in assembler than in other languages, but large
: programs rarely turn out better, both because assembler programs are
: longer and so harder to write and debug, and because assemblers offer
: little support for sophisticated data structures so you have trouble
: using faster but more complicated data structures and
: algorithms. -John]


I full agree with our moderator. Programming in assembler is highly
tedious. As it was discussed here, even programming in C is tedious
compared to some other languages, such as O'Caml, especially in tasks
involving big data structures.


What are the problems of tedious programming?
a) The cost of such programming is high, compared to the relatively low
      performance increase.
b) Tediousness tire programmers, which can't have their attention fixed
      on their task. As a result, errors get in.
c) Tediousness encourages the use of simple data structures, even if
      they are inefficient.
      This is especially true of languages like assembler where you spend
      more time worrying about where you pointers go than about the actual
      processing of data.
d) Low level languages don't allow for much reusability, which reduces
      the amount of work and thus improves efficiency.


c) is an important point. As you may know, for many common tasks
performed inside programs, there have been analyses of methods
(algorithms, data structures) that fulfill that task. Most often, the
most simple methods to implement are inefficient compared to subtler
ones when the size of the problem to handle increases.


Using assembler instead of C, or C instead of, say, O'Caml, may
increase speed by a constant factor, if you use the same
algorithm. The problem is that programming advanced algorithms in
low-level languages tends to be hellish. As a result, most people
revert to simple schemes... which get inefficient.


For example, if you program a priority queue in assembler (that sort
of things is used in many contexts... we use one in our compiler, for
instance, to know which variables to store into registers first),
you're likely to choose the most trivial way to do that. The problem
is that such a method is less efficient than the most advanced
binomial heaps. But programming binomial heaps in assembler, though
not the ultimate hell, is really tedious.


d) is also an important point. Reusability means that if you have
programmed an useful but tedious library, you're likely to be able to
use it in many contexts.


--
Computer science student at ENS, Lyon, France
http://www.ens-lyon.fr/~dmonniau
--

Return to the comp.compilers page.
Search the comp.compilers archives again.