Re: performance


Willy Denoyette [MVP] wrote:
> "bjarne" <bjarne@xxxxxxxxx> wrote in message
> news:1125606788.482057.29490@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
>
> Willy Denoyette [MVP] wrote:
> > "bjarne" <bjarne@xxxxxxxxx> wrote in message
> > news:1125581099.904428.309450@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
> > > Willy Denoyette [MVP] wrote;
> > >
> > >> ... it
> > >> was not the intention of StrousTrup to the achieve the level of
> > >> efficiency
> > >> of C when he invented C++, ...
> > >
> > > Ahmmm. It was my aim to match the performance of C and I achieved that
> > > aim very early on. See, for example "The Design and Evolution of C++".
> > >
> > > -- Bjarne Stroustrup; http://www.research.att.com/~bs
> >
> > Hmm.. "match" is a word that say's a lot, but it doesn't say "the same"
> > performance, note that Hejlsberg, would probably use the same wording when
> > talking about "The design and Evolution of C#" ;-)
>
> I didn't mean to use weaselwording. I mean "the same performance or
> better". Clear enough? Once (in 1982 or so), I found a systematic run-time
> speed
> reduction of 3% caused by a slighly less efficient function return
> mechanism. That was promptly fixed.
>
> ***'Weaselwording' nice word, I should remember this one. But you didnt
> answer the question, was it a major goal to make C++ as efficient
> (performance wise - and here I mean in space and time) as C

I thought I was pretty clear about that: Yes the aim of C++ was to
provide the same performace in time and space as C for identical code
(most C code is also C++ code) and for equivalent code (e.g., a class
member function call compared to a free standing function with a
pointer argument)

> or should I read the book to get the answer :-)?

Reading "The Design and Evolution" might indeed be a good idea. It
answers most common questions about why C++ is the way it is. After
that, the "Performance Technical report" (link on my C++ page)
specifically discusses performance in the context of modern C++.

> Great to have you here b.t.w
> Don't get me wrong, I like C++, it's one of my favorite languages, I know
> (well, I should) it's strengths and it's weakenesses, but I know other
> languages too and I know how to choose one over the other. C++ can be used
> for many tasks at hand, but that doesn't mean its the silver bullet, nor is
> C# or the CLR or VB etc...

and I never claimed C++ to be a silver bullit, but I claim it to be
pretty good at a variety things, and performance of the basic
individual operations is one of them.

>
> But talking about performance, you know that MS earliest version of NT was
> almost completely written in C++ (using OO idioms!), little by little they
> have to switch back to pure C for reasons of performance and reliability.
> The result is that most recent versions of Windows (New code bases you know
> ;-)) still use plain C code for some kernel stuff and some parts are still
> stand-alone assembly or embedded, why?.

Actually, I don't know that. I have heard a lot of stories about the
development of NT, but they contradict each other. Given what I know I
doubt your version, but I'm willing to assume - just for an argument -
that you are right because there has been other examples of that
phenomenon. For example, the Taliget system was designed and designed
to be 100% OO and implemented in C++. It was beautiful according to
some lights, but useless because it ran like a pig: The average simple
operation involved aout 70 virtual function calls. IMO that's not good
design eventhough it may be OO and you can implement it in the most
efficient language (C++) and still have an inefficient system. The real
problem in such systems is that every decision is made at run time (for
flexibility) and re-evaluating the multitude of choices repeatedly
slows down even a modern CPU.

> When I say performance I mean both in terms of memory space and service
> time, some parts where to slow and the base working set was too high, and
> this was at the end of the eighties (1989 -90), sure you can blame the
> compiler and library implementations, but you know that Dave Cutler ain't
> that stupid (at least he wasn't when he left the company where we both
> worked for) but he and his team learned a lesson, now they what can be done
> in C++ and what shouldn't be done in C++. Sure times have changed, CPU's
> have spare cycles these day's and you might think they would do it all over
> in C++ by now, but no they don't.

You are making a lot of assumptions. I'm not. It was not an issue of
time and space costs of the C++ language features.

> So what I see is that the latest versions of W2K3 (both 32 and 64 bit) still
> use C code for ntdll and ntoskrnl, the same assembly API's for the kernel
> loader code, the same C and assembly code for the HAL's and the same C code
> for kernel mode device drivers, while it's much easier to use C++ they must
> have a good reason for this isn't it?

Not really, they may be reflecting experiences with a bad compiler 10
years ago - people tend not to reevaluate their assumptions - or refuse
to acknowledge that the problem was their design rather than the
language. It's ever popular to blame the tools for failures.

> Even on these super performant silicons, some kernel code and device drivers
> don't have that much cycles to waste and memory is still an issue each byte
> counts when dealing with high performance devices like disks and high
> performance network drivers, even on an HP superdome with 64 CPU's and 1TB
> memory.
>
> > You can write "equal efficient" code in terms of performance using C++ as
> > you would in C, but once you start using C++ idioms you are loosing on
> > performance (this is not saying on efficiency)?
>
> No. That's not so. If you use C++ facilities and idioms well, you can't
> hand-code them any better in C. A common example is C++ sort() vs C
> qsort().
>
> ** This was not my point, I wouldn't implement OO idioms using C and I did
> not suggest something like this too.

But people do (incorrectly) say "C is more efficient than C++" and
proceed to write messy C code where equivalent C++ code would be at
least as efficient and much cleaner.

>
> I recommend the standards commottees technical report on performance
> (link on my C++ page) for details - probably more details than you want.
> ** I'm a regular reader, the more details the more I like it, but with due
> respect, I don't believe (and don't understand) everything I read, I'm way
> too long in this business for this ;-).

You are very close to saying "I don't believe you" without bothering to
look at the recommend source of information.

> The most common objection to claims about performance is "but what
> about exceptions?" That of course depends on the exception
> implementation, but several are below 5% overhead for the normal case
> and 0% has been done. Note that this is the unfair comparison of
> exception based code against code without error detection tests - real
> code does better.
>
> ** You know that as user you don't have that much choice, for instance the
> (MS Visual) C++ exception model is based on the Windows SEH, that's it you
> have no choice (the same goes for the CLR's exception model which sits in
> top of SEH too) I can tell you that the overhead is larger than 0%.
> Fair enough the overhead is low and for most user applications it can be
> ignored, but for some high frequency code paths the costs are too high and
> you need to switch to error code checking.
> Talking about the CLR here (after all it's a MS .NET NG) the next version
> has included some reliability features that make the set-up of the exception
> frame records more expensive but you gain on reliablity because you know for
> sure that your "finally" clauses will run in the face of asynchronous
> exceptions (something C++ doesn't have to care about).
> This is a trade off we all have to accept, for most applications the extra
> cost doesn't matter, for others like libraries we must consider the cost in
> the design, and we should not say exceptions are free (and I'm not talking
> about throwing).
> Those who can't accept or don't understand such trade-off may have to go
> back to something more efficient like native C++.

I think you're off on what to me is a tangent, but I'd just point out
that RTTI ("Resource Acquisition is Initialization") is a far simpler
and more reliable technique for resource management than littering your
code with "finally" clauses.

>
> > if you really are Bjarne,
> > you sure know this better than anyone else and you won't be posting here
> > :-).
>
> > C++ code, and here I mean programs making use of C++ OO idioms like
> > classes,
> > inheritance, encapsulation, exception safety etc. are less performing (not
> > that much) than pure C, these 'features' come at a cost, but that doesn't
> > mean the language is less "efficient" as a whole - au contraire mon chère,
> > you just loose a tiny bit on efficiency in terms of performance, and it's
> > that bit we shouldn't care about (I for one I don't), instead look at what
> > you won.
>
> I make the stronger claim that what you use those features, you get as
> much performance as you would with equivalent functionality using plain
> C.
>
> For example, classes and non-virtual member functions exactly match
> free-standing function as structs, classes with virtual functions equal
> or beat equivalent code expressed using pointers to functions or switch
> statements.
>
> ** Going back to C to mimic C++ virtual calls or other idioms, would be a
> mistake, you should only go back to C if you realy know that something can't
> be done as efficiently in C++, I know, you said there is no such thing, I
> say with due respect 'it depends'.

ok. Give one example that can be done efficiently in C and not in C++.
Obviously, you can't because C is very close to a subset of C++. As I
said before, the only point of discussion here is exceptions.

> > In cases that you don't need or can't or may not use these OO idioms and
> > language features or you need to save on every cycle ( think about device
> > drivers and some high performance kernel function), you will have to go
> > down, closer to the machine level, that is go to C (a higher level machine
> > code) or assembly language.
>
> No. I have seen cases where people had to go to C++ using templates to
> gain performance that had been unattainable with C because of the
> complexity of expressing the best solutions. For example, see the
> hardware access section of the performance TR.
>
> *** Agreed, I have the same experience. However, all depends on the task,
> for instance All (Windows) kernel mode device drivers are written in plain
> C, C++ is not advised and STL is a defenitive NO NO in driver land, you have
> to tweak the DDK to be able to use the VS tools.

Please don't confure Microsoft policy with language-technical facts.
C++ is widely used for device drivers: The most popular framework for
device drivers on Apple machines (NI's) is in C++ and use templates (I
do not know if they actually use the STL).

> Even the standard C library must not be used, there is a special C library
> in the DDK. I know this is not strongly related to the C++ language, it
> relates to the efficiency/performance of the libraries (STL and C library)
> which both contain functions you never need in driver development, they make
> the working set grow and the less "efficient functions" ( fi. buffer overrun
> checks etc.) are replaced by the minimal code, buffer management is the
> responsabilty of the library user (make you buffers large enough but not
> larger).
> Structured exceptions and C++ exceptions should not be used also, note this
> is more a reliability issue than a performance issue, anyway it makes C++
> less attractive in this domain.

Hard-real time embedded systems programming and device drivers are
different from applications programming. You tend to use different
libraries and avoid certail language features (free store and
exceptions are common examples). However, that does not affect the
C/C++ language choice. Again, have a look at the Performance TR, which
discusses these issues.

> One of the design requirements of the CLR is NOT to use C++ template
> libraries nor the ATL libraries for the COM interfaces, Exceptions and OO
> idioms were allowed, no multiple inheritance however. The same is true for
> the core of the high performance services like SQL and exchange, you know
> probably someone at MS to explain the rationale of this decision.

Yes, performance wasn't among those.

> Of course not all C++ code performs well - you can write awful code in
> any language - but if you need seriously optimized code (as in embedded
> systems or for high-end computing) you can use C++. If you need to beat
> C++ in that game, you have to start using machine instructions not
> supported by the available optimizers - and even then inlined embedded
> assembler is usuall an option.
>
> ** Agreed, but it's not always an option see above.
>
> And of course, such serious performance concerns are not relevant for
> every piece of code.
>
> *** Sure not.
>
> Willy.

.

Relevant Pages

  • Re: performance
    ... > for kernel mode device drivers, while it's much easier to use C++ they ... > exceptions. ... ** I don't confuse language and policies, ... template libraries and no C++ exceptions. ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: dynamic type checking - a pauline conversion?
    ... In general I love as much static typecheck as I can in a language - since ... After all, most good java ... libraries with partially overlapping functionality ("cant do with, ... > Handling Exceptions in a consistent and convenient way is near to ...
    (comp.object)
  • Re: Please explain the meaning of stealing a ref
    ... points of connotation as well as denotation in phrasing, and language ... clearer to _other_ readers, ... No, the use of the word 'exceptions' is anything but unreasonable, ... "Owning a reference" means being ...
    (comp.lang.python)
  • Re: performance
    ... ;-)) still use plain C code for some kernel stuff and some parts are still ... Even on these super performant silicons, some kernel code and device drivers ... exceptions. ... relates to the efficiency/performance of the libraries ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: When to introduce exception safety
    ... | context of exceptions because it lacks exception safety -- well it might ... I'm sure libraries like this exist, and we have to somehow work ... | If a dtor throws all bets are off. ... But how do you guarantee that a given destructor will not throw? ...
    (alt.comp.lang.learn.c-cpp)