On Thu, Nov 22, 2007 at 11:36:58AM +1800, Nick Apperson wrote:
> Thanks for a great read there first of all.
>
> But... and this is something I see time and again and I must admit I don't
> really understand. What makes C faster than C++? I feel like C++ is all
> about you don't pay for what you don't use.
My personal stance is that the extra cruft and basically mysterious
behaviour in some cases (I know many programmers and even some gcc
developers, and only one or maybe two who can say that they completely
understand identifier lookup mechanism in C++) is not worth the extra
features you are getting. I believe C gives you all the constructs you
really need and frequently the extra C++ constructs just reduce
readability. But this is just question of taste and many people will
like the extra C++ features and that's really ok, too.
I think C++ is much like Perl. Many oh-so-cool features and constructs,
but things can get out of hand real fast. ;-)
(And I do like Perl. Including the cool features and constructs. But
Perl and C are pretty much _the_ two languages I use and I never had too
much motivation to mix the cool features with low level code as in C++.)
> Furthermore, I feel that C++
> has at least one feature that in a one certain special case will result in
> faster code. While I generally would say avoid indirect calls where
> performance is critical (for obvious reasons) thereare certain times when it
> is faster than climbing through tons of logic. For these cases, if one
> indirect branch is reasonably likely the optimization most recent x86 chips
> take with static branch prediction is to "assume the [indirect] branch is
> not taken" which might seem wierd but makes sense since the chip can't
> easily guess this information statically. Good compilers will usually write
> the most commonly jumped to location after the indirect uncomditional jump
> instruction soooo....
>
> JMP [EBX]
> JMP default_function
>
> is output. Unfortunately, C doesnt' have a way to specify this base case.
> Trying to code this yourself won't really work either because a C compiler
> is likely to notice that the branch is unconditional and remove you branch
> that occurs after anyway.... Which would be if you were using the low level
> jumping routines anyhow. There are a couple other features as well.
This is indeed not standardized but C compilers tend to have their own
extensions for this. Many codebases have likely(a) and unlikely(a) macros
they use in conditions which are defined to expand to
__builtin_expect(!!(a), 1)
or 0 respectively in case the code is compiled by gcc. I'd expect MSVC
to have some similar way to hint this.
(gcc also supports -fprofile-generate and -fprofile-use, which is pretty
cool too - gcc will re-optimize the binary based on profiling
information gathered from a test run of the program. It can be quite a
non-trivial boost.)
However, I don't get how is this related to C vs C++? AFAIK C++ does not
have an official way to hint the compiler about branching probability
either?
--
Petr "Pasky" Baudis
We don't know who it was that discovered water, but we're pretty sure
that it wasn't a fish. -- Marshall McLuhan
_______________________________________________
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/
