Beginning C++ in FreeBSD

[Chris Ashlee]

DoubleF wrote:
> [When I say `moving to chat@', I mean it]
> 
> On Tue, Apr 20, 2004 at 09:39:53PM +0000,
>  Daniela probably wrote:
>>[assembly language-related stuff and etc]
>>And if I want it to be fast ...
> 
> 
> Undoubtedly, today you can hand-optimize your code to run faster. But
> there are certain problems (I'm not touching compatibility problems
> here, they're known to you):
> 
> 1) what you have written to be optimal for an AMD processor may be
> suboptimal for an Intel processor, and vice versa, and Intel and AMD
> aren't the only companies out there;
> 
> 2) what you have written to be optimal for a Pentium P54C (read: Pentium
> 1; that's what I'm sitting in front of now) processor may be suboptimal
> even for a P6 (Pentium Pro) processor, because their architectures are
> different;
> 
> 3) (a bit more serious) it's not difficult to manage the 8 basic 32-bit
> registers (okay, maybe 7:)) efficiently, but do you think you can do the
> same with 16 64-bit registers of the AMD 64-bit processor? not sure
> about you, but I wouldn't bet I can outoptimize a good compiler there;
> 
> 4) it's not difficult to write instructions one by one, but it's not
> easy for the processor to process them that way , so Intel's 64-bit
> architecture wants you to pack 3-s of instructions into chunks. I think
> 3 is an odd number of instructions to have in a 128-bit chunk:). This
> definitely doesn't make assembly programmer's life easier either.
> 
> (3 and 4: just look at the manuals of the respective architectures and
> see, for instance, how the 3-convention makes IA-64 assembly
> unreadable --- just MHO).

All of these are good points, and debunk assembly's supposed advantages. 
But the difficulty of writing fast assembly code on any decent 
architecture (ie. not x86) is really the least of its problems. The 
worst of its problems:

1) It takes longer to write,
2) It takes longer to debug,
3) It's much harder for others to understand,
4) It's MUCH harder to change,
5) It limits you to one CPU architecture.

All these disadvantages, for only a *chance* at faster code in return. 
Why such an emphasis on speed before anything's even written, let alone 
profiled?

> 
> 
>>I'd give up all the comforts of a high-level language even for no particular 
>>reason. Every programming language is fun and easy in it's own way. For me, 
>>ASM in not just a last resort.
>>

Fair enough. That's your choice. And there is a certain measure of fun 
in it. At my school, they make us all take a class in assembly language 
programming, albeit on 68HC11 microcontrollers, and it is a lot of fun. 
But more importantly, it teaches us what's going on in the machine, 
which can be useful for debugging, and writing code that is likely to be 
compiled to run fast. And of course, a good knowledge of assembly is 
essential if you want to write compilers.

But writing *everything* in assembly is not the way of good software 
engineering, for all the reasons I mentioned above. While you write your 
programs in assembly language, everyone else is writing code in half the 
time, debugging it in a quarter the time, and it can be changed more 
easily to add new features or adapt to changing requirements. And it 
runs just as fast, too!

The focus in software engineering these days is not on more performance: 
we've already solved that problem. The focus is on developing things on 
time, on budget, that meet the ever-changing requirements. Assembly is a 
poor choice for all of these needs. Daniela, if you ever want to 
collaborate on software projects with other programmers, you're not 
going to be able to do it in assembly language. Bear this in mind as you 
continue to learn as a programmer.


Chris