[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Asm or C (was: Re: New Web browser for MiNT)
Well,
reading latest postings I've noticed that this discuss in fact changed the
topic from "Asm or C" to "Asm vs C". Initially Kristoffer had written that
many people write stuff in assembler "because it is cool or something" and
"it is a problem". My reply was intended to explain, that there are *some*
reasons to use assembler instead of C or anything and that it is not any
problem. At least, not for C programmers. But this gave me occasion to
notice once more that C programmers become nervous when you prefer other
stuff (speed, compactness) over portability and if you use the magic
phrase "pure assembler". OK. Perhaps assembler is not the One and Only
Programming Language, but C is neither, is it?
The fact is that the development time for asembler programs is longer,
because of hand optimization. But it is also a fact, that assembler
programs are faster than anything else, and no sophisticated argumentation
can change this fact. If C compilers would be really so good in
optimizations, as you argue, the demoscene would use C. But they all use
assembler for some strange reason (let me guess: speed?).
> > For larger programs I noticed that the time of development
for asm
> > programs is really much longer than for C programs. But I also noticed,
> > that the most of this time is spent on optimization, which part is mostly
> > missing for C development.
>
> Yeah, because we trust that to be done by the compiler ;-)
You trust :) Very well said.
>> Yes, right. Slight speed gain that breaks portability is quite bad
>>usage
>> of assembler. But if you have a portable C program and a non-portable
>> assembly based equivalent is say 5-6 times faster on a particular
>> machine
>5-6 times faster?
>I can't see that happening for _anything_, assuming a good C compiler.
>Even a factor of two is not common, IME.
I can give an example. With C source code. If you will be able to make it
at least two times slower, than my asm equivalent, I will be pleased to
give all honours back. :)
>Demo programmers knowing the 'optimal structures for data processing'?
>In what reality?
>I'm not picking on the demo programmers, but I can assure you that they
>would never have any need for most of the algorithms/structures you'd
>find
>in a normal textbook on such things.
Hmm, I am not a demo coder, but have you actually seen a modern demo for
Falcon? Do you think that the machine is really able to draw all this
vector animations and stuff in realtime using standard mathematic
algorithms? If so, try to code it in C. Just for a test.
>Compilers have no more problems with complicated data structures than
>with
>simple ones. If you mean that you would use a less complicated scheme in
>assembly, there's nothing stopping you from doing the same in C.
Sure. But high level language doesn't teach you what a structure is
"simple". You'd be surprised how many people don't even realize that the
memory is unidimensional.
>> problem to this (compilers usually do the same, but according to
>>your own
>> words, they can't optimize optimally, so they don't do it perfectly),
>No human does either, for anything except very simple things.
Sure again. But anyways, you have more possibilities to optimize stuff in
asm, where you deal with single instructions and can always know timing
tables (esp. head/tail stuff) better than gcc or code generator author.
>Before you complain about C compilers, try GCC with something like:
> -S -O2 -fomit-frame-pointer
I tried that. Even with O3. The code I saw usually wasn't the best I had
ever seen before.
>If you find it so difficult to push a few values on the stack, why don't
>you write a macro for it?
I didn't mean that it is hard. It just wastes the CPU time (stack is in
the memory, so push/pull operation is a superfluous memory access).
Besides, I don't doubt if it is very important to use a well optimized
algorithm to code stuff. But with assembler you can go one step further,
because you can *additionally* optimize the program itself :) And you
aren't dependent on language limitations at all, and you may be dependent
on compiler bugs, but in definitely null extent in comparison with the C
or anything else.
Of course, I easily believe, that C compiler is able to create a
reasonable good code, if you use proper syntax in your source file. But do
you all think that, following Andreas' example:
a = ((i << 8) | (i >> (8)));
is really easier and less cryptic than rol.w d0 ?
Konrad M.Kokoszkiewicz
mail:draco@bl.pg.gda.pl
http://www.orient.uw.edu.pl/~conradus/
** Quem Iuppiter vult perdere, dementat prius.
*******************************************************
** Kogo Jowisz chce zgubic, temu wpierw rozum odbiera.