Re: C++ programmer and assembly
Francis Glassborow wrote:
Walter Bright wrote:
For example, which is faster -
virtual function dispatch, or switch statements?
Oh, and you know the answer without testing? Then the chances are that
you are sometimes mistaken.
I was pretty clear (see below) in advocating profiling.
How does the order and
density of case statements affect performance?
Which very largely depends on details that are platform/compiler
specific.
Of course. And you cannot determine those details without looking at the
output of the compiler, which requires knowledge of assembler.
The best advice is 'Do not try to hand optimise a switch
statement just put the cases in order. Either it does not matter or
ordering will help the compiler.'
There's more to getting the most out of switch statements than that -
much more. Most compilers have a palette of strategies to use to
implement switches - which one is your particular switch statement
getting? I can elucidate if you wish.
In addition do not dream of trying to
optimise unless you have forst measured and found a bottleneck.
That's why I wrote previously in this thread:
-----------------------
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.
-------------------------
Write code that is easy to follow and maintain.
That's good advice. But it has its limits. You won't need to maintain
software that isn't fast enough to please your customer. I once had a
big contract where the *contractual* requirement was that my code ran
faster than the competitor's code. I delivered a 2x result, and years
later, it's still faster. One of the enduring advantages I've enjoyed as
a C++ compiler vendor is my compilers execute considerably faster than
the competition. My customers like that a lot.
How do pointer dereferences affect things?
You are joking?
Not in the least. Consider that C++ compilers aren't able to cache and
enregister pointer dereferences very well, because of the aliasing
problem in C++ semantics.
Perhaps not, but this is the kind of low level detail
which should hardly ever be of concern to the working programmer.
To the average programmer writing average code, perhaps not. I don't get
paid to write average code, though.
How about locality of data in a virtual
memory system? Locality of code?
Yes, but that requires an understanding of caching rather than machine
code.
It's all part of knowing the machine.
How do you get good I/O performance?
What are the relative costs of operators +,-,&,<<,/,%,* ?
On the current hardware? These days if you care you should probably be
looking at your algorithms. Many modern compilers do excellent
optimisation as long as the programmer does not write tricky code.
I don't know any compiler that is able to retype signed types to
unsigned ones so that / can be performed more efficiently. There are
also floating point optimizations of this sort that cannot be done by
the compiler because they subtly change the semantics, but an advanced
programmer can do them manually.
What are
register variables?
In what sense. If you mean variables that are enregistered, leave it to
the compiler it will almost invariably do a better job.
As I wrote previously, knowing the rules about what can and cannot be
enregistered, and why, enables one to help the compiler do its job. And
if you don't know assembler, you cannot figure those rules out.
How do I write my function so that the variables
that should be enregistered are?
FOFL.
Should I make a function inline or not?
Again, these days almost certainly leave it to the compiler but if you
want to tweak measure first.
So let's say I suspect that inlining foo() will make it go faster. I
measure, slap 'inline' on, and measure again. No difference. What does
that mean? Did inlining have no effect, or did foo() even get inlined at
all? Is there a way to modify foo() so it *will* get inlined? Can't tell
without looking at the assembler output.
You can profile all you want, but your ability to effectively use the
output of the profiler to improve your code is seriously hampered if you
don't know assembler.
What are my app's memory allocation patterns and is a custom allocator
justified?
What are the costs of using RAII? Is it better to use RTTI or
a 'dope' member?
When you get to that stage you are very far past being a novice
programmer.
Sure. And if you don't know this stuff, you'll never be an advanced
programmer.
Sure, you can get by and get your C++ programs to work without knowing
anything about that stuff. But not knowing assembly is like an engineer
not knowing calculus - he'll be forever second rate.
Sorry, with respect, nonsense.
And I respectfully disagree. My career has been writing code that runs
faster than others.
I guess you write excellent assembler but
does that require that you know how your cpu is microcoded.
I don't know microcode (it's not published by the cpu makers), but I do
carefully read the documents they put out about how to write fast assembler.
Going the other direction and learning a little Lisp can give valuable
perspective, too.
No learning Lips properly from an authoritative source (too many are
still think procedurally and doing naive conversion to Lisp.
Of course. I wouldn't suggest that writing FORTRAN code in C++ would
teach one OOP, either.
But what's with the resistance to learning assembler, anyway? It ain't
that hard. Does anyone really have a problem understanding what:
mov EAX, 3
means? C++ is ten or a hundred times harder to learn.
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]