Re: performance


"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 or should I read
the book to get the answer :-)? 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...

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?.
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.
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?
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.

I recommend the standards commottees technical report on performance
(link on my C++ page) for details - probably more details thanyou 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 ;-).

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++.


> 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'.

> 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.
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.
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.

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: Can we use cpp to write WDM driver ?
    ... restrictions most class libraries and other things do not work. ... C++ runtime library won't work in kernel mode, but then kernel drivers don't ...
    (microsoft.public.development.device.drivers)
  • Re: Termination of the Philips Webcam Driver (pwc)
    ... >> inside the kernel. ... Probing routines, interrupt support, etc. would be handled by ... libraries, which may or may not be closed-source, would be loaded from ... Linux distributions will typically come with certain drivers ...
    (Linux-Kernel)
  • Re: performance
    ... efficient language and still have an inefficient system. ... > 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)
  • Re: Compiling C++ modules
    ... Without exceptions (which are fragile in a kernel), the former can't return an error instead of initializing the Foo. ... Foo item1, item2; ...
    (Linux-Kernel)