right... well C++ does have this using virtual methods. I meant to add that part.
C++ also has templates which while they theoretically don't add any performance. Practically speaking they add tons because you don't have to split your optimization time between 10 or more versions of the same function. I don't buy the stuff people throw down about programmer productiveity being more important than raw speed, but if you are starting at the same speed and it is easier to optimize you will likely get a faster program. And I totally agree with you that things can get out of hand fast. I'd say C++ is probably one of the hardest languages out there. Templates can make code blazingly fast in the general case, but writing them to work well can be extremely challenging. Multiple inheritence is somewhat easier to me, but it can definately trip people up really quickly if they design their code poorly. There is a saying I think... but yeah C++ is not made for people that aren't really good programmers. No training wheels. On Nov 22, 2007 11:51 AM, Petr Baudis <[EMAIL PROTECTED]> wrote: > 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/ >
_______________________________________________ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
