Re: C++ programmer and assembly
Rune Allnor wrote:
On 11 Apr, 21:44, Walter Bright <wal...@digitalmars-nospamm.com>
wrote:
You can successfully write C++ code without knowing any assembler.
However, it's been my experience that those programmers who do know
assembler tend to write much better C++ code. The reason is
straightforward - they understand the tools much better, and
understanding them enables you to make better use of them, rather than
being mystified by them.
I've found it to be generally true that people who don't know assembler
have a lot of difficulty writing high performance C++ code. If their
code is fast, it's more based on luck rather than correct reasoning.
Could you elaborate, please?
Sure. I've watched people who don't know assembler try to go about
optimizing their code. The first thing that goes wrong is they won't
reach for a profiler. You could say that has nothing to do with
assembler, and you'd be right, but the correlation is there.
So, without a profiler, they develop theories about how to speed up
their code. They'll try things they heard about, like replacing x*2 with
x<<1, and other pointless maneuvers. They generally have no feel at all
for what the cost is of various constructs.
For example, I know one person who went on and on about how he'd used
some complicated templates to speed up a section of code (he was using a
profiler, at least). But a quick check of the generated code showed that
his speed benefit came from something else; the compiler had managed to
remove a redundant divide. All the other machinations had accomplished
nothing but obfuscation, but he never realized that.
For those that know assembler, first they'll profile. Then they'll
attempt the usual algorithmic speedups. Once all that is done, they'll
do a disassembly of the bottleneck function to see if the code is what
they expect, or if something funky is going on (with C++, there can be
so many layers of abstractions that often it is nearly impossible
looking at just the source to see if something funky is going on).
Often, there'll be a "hey, what's that destructor call doing there?" or
some such, which will lead back to reorganizing the source code.
Until recently, I have structured my C++ programs based on the
point of view that what I learned of assembler programming many
years ago is still valid. On a couple of occations I have recieved
advice here which can best be summarized as "forget everything you
knew back then, program straight-forward code and let the STL and
the compiler take care of performance issues."
The first step should be to write straight forward code. Much of the
time, that's all you need. But when that isn't delivering the crispness
you need, it's time to get the profiler and pop the hood to find out
what's really going on. Memory allocation and RAII, for example, can
slyly slip in and steal away your performance.
Besides, conventional wisdom is for average programmers. If you want to
do better than average, question it and check for yourself with
disassemblers and profilers.
What you say above seems to corroborate my point of view as of
three months ago, and contradict most advice given here, as
I percieve things.
For your information, I am not a computer programmer in my
"day job" but I have an ambision to program my own tools.
The stuff I do for a living involves data processing on the
order of tens of gigabytes per day, which means run-time
performance is an important issue.
I've found that whenever the data set size increases by a factor of 1000
or so, one has to completely rethink how one goes about getting good
performance.
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]