Since everyone is throwing in their two cents, here's mine:
Writing assembly code is almost never the right solution anymore.
This is because processors do their own optimization. Thus, code that has
been tuned really well for a Pentium (say using instruction ordering to
maximize use of the superscalar architecture) may well be incredibly
inneficient on a Pentium II (which uses out-of-order execution) or on a
Pentium IV or Athlon (which both have lots of execution engines and
sophisticated schedulers). The compiler can be optimized to take advantage
of these things (pgcc), but it is usually bad form to try to take advantage
of these optimizations in user-written code. Writing in assembly to reduce
the number of instruction calls, fine, trying to use 'better' instructions
or place them in a certain order, bad for portability. This is not MIPS,
DLX, or embedded programming. It's IA32 where there are no gaurantees.
As for having more processor power than we can use, I sure hope it comes
to that, but evern on 1.5+GHz machines, VMWare is still very noticeably
slower than running native (and when plex86 can perform as well as well as
VMWare, we'll all be celebrating) So we certrianly want to write as
efficient code as possible (without going to the extreme mentioned above)
I won't make any comment on the C/C++ thing. It IS a religious war.
.Geoff
-----Original Message-----
From: David B.Harris [mailto:[EMAIL PROTECTED]]
Sent: Friday, January 05, 2001 5:15 PM
To: [EMAIL PROTECTED]
Subject: Re: [plex86] More on C++
To quote Mark Zealey <[EMAIL PROTECTED]>,
# personally I loath C++. it's bloated, slow, etc as people have said
# before. properly coded C will *always* beat the hell out of C++, even
if
# it does take a little bit more code
Just wanted to throw my two cents in here.
Properly written assembly will *always* beat the hell out of C. And C++.
But that's not the point, is it?
It's a tradeoff. Ease of maintaining, and ease of writing, versus speed
of execution. When someone gets too ambitious, and sacrfices everything
in favour of speed of execution, they often loose in the long not. Not
because the language is slow - but because after a certain point, they
are completely incapable of writing proper code in that language, for
that project.
In the C vs. C++ argument, talking about speed of execution alone is
useless. A few thing have to addressed:
1) Skill of original programmer. All else being equal, it's easier to
write "proper" code in C++.
2) Skill of maintainers. If your project is going to be actively
maintained for 20 years, be sure that the language you write in will
last that long. Otherwise you'll be shelling out big bucks for
specialized programmers. C has been around a real long time, and it's
likely to stay. However, C++ is also being taught everywhere these days,
so I doubt it'll go away too soon.
3) Need for execution speed.
The fact is, it all comes down to the programmers. Someone writing in
the programming language with the fastest known executable binaries, yet
who doesn't know what they're doing, isn't going to write fast code.
However, someone who does know how to use those lower-level languages
will be held back by a language that is significantly high-level(like
C++). It's a tradeoff. Clean and simple.
Since Kevin is the current maintainer(and will likely be for quite a
while), and I gather that he's proficient enough in C to really use it,
I think the choice is obvious.
Dave
