performance

[bjarne]

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

[Tim Haughton]

"bjarne" <bj****@gmail.com> wrote in message
news:11**********************@z14g2000cwz.googlegr oups.com...

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

Hi Bjarne, I suspect it is people's experience with certain compilers that
leads them into thinking C++ can't compete with C. Often I find that a
developer's desire to optimise is misguided, particularly when there's a
notion of 'fast enough'.

--
Regards,

Tim Haughton

Agitek
http://agitek.co.uk
http://blogitek.com/timhaughton

[Willy Denoyette [MVP]]

"bjarne" <bj****@gmail.com> wrote in message
news:11**********************@z14g2000cwz.googlegr oups.com...

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#" ;-)

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

[bjarne]

Tim Haughton wrote:

"bjarne" <bj****@gmail.com> wrote in message
news:11**********************@z14g2000cwz.googlegr oups.com...

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

Hi Bjarne, I suspect it is people's experience with certain compilers that
leads them into thinking C++ can't compete with C.

I have never seen a C/C++ compiler system (e.g. GNU, Microsoftm ...)
where the C++ compiler didn't equal the C compiler for code in the
common subset. Most examples that claim to show the opposite can be
tracked down to non-language factors such as dynamic vs. static linking
of standard libraries or differences in default optimization options.
Often I find that a
developer's desire to optimise is misguided, particularly when there's a
notion of 'fast enough'.
That certainly matters a lot. Performance can be important, though, and
then the issue becomes how to find appropriate things to optimize (e.g.
algorithms) as opposed to blindly filliding with language features.
--
Regards,

Tim Haughton

Agitek
http://agitek.co.uk
http://blogitek.com/timhaughton

[herr]

By the way Bjarne, How Are You?
"bjarne" <bj****@gmail.com> wrote in message
news:11**********************@z14g2000cwz.googlegr oups.com...

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

[bjarne]

Willy Denoyette [MVP] wrote:

"bjarne" <bj****@gmail.com> wrote in message
news:11**********************@z14g2000cwz.googlegr oups.com...

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

I recommend the standards commottees technical report on performance
(link on my C++ page) for details - probably more details thanyou want.

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

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.

And of course, such serious performance concerns are not relevant for
every piece of code.


Willy.

[Willy Denoyette [MVP]]

"bjarne" <bj****@gmail.com> wrote in message
news:11*********************@g14g2000cwa.googlegro ups.com...

Willy Denoyette [MVP] wrote:

"bjarne" <bj****@gmail.com> wrote in message
news:11**********************@z14g2000cwz.googlegr oups.com...

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.

[bjarne]

Willy Denoyette [MVP] wrote:

"bjarne" <bj****@gmail.com> wrote in message
news:11*********************@g14g2000cwa.googlegro ups.com...

Willy Denoyette [MVP] wrote:

"bjarne" <bj****@gmail.com> wrote in message
news:11**********************@z14g2000cwz.googlegr oups.com...

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.

[Andrew]

On 2 Sep 2005 06:46:04 -0700, bjarne wrote:

I thought I was pretty clear about that: Yes the aim of C++ was to

I have to say - I was kinda thinking - huh? How could he have been any
clearer?

[Willy Denoyette [MVP]]

Inline ***

Partly trimmed.

Willy.

"bjarne" <bj****@gmail.com> wrote in message
news:11**********************@g14g2000cwa.googlegr oups.com...

Willy Denoyette [MVP] wrote:

"bjarne" <bj****@gmail.com> wrote in message
news:11*********************@g14g2000cwa.googlegro ups.com...

Willy Denoyette [MVP] wrote:

"bjarne" <bj****@gmail.com> wrote in message
news:11**********************@z14g2000cwz.googlegr oups.com...

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)

** Ok, got it.
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

** I can't comment that much on this in a public forum, I know this from
experience when DEC started the port to Apha AXP.
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.

** Don't know, the same compiler is used for the whole code base, a large
part is C++ a smaller part is C code a tiny part is asm, can't give more
details in public, sorry.
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.

** Agreed. But I know people who have been writing messy C are now writing
messy C++, be it harder to don't stop them.
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.

** Sorry if you feel insulted , if I had this intention I would have said
so, I said I don't believe everything I read, but maybe it's because I don't
understand everything, and rest assured I read the TR, and I also read other
company internal reports.
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.

** True, I guess it's easier said than done in a system where destructors
are left with very little support, where you have to share the runtime with
other languages it's not enough to have C++ do it and all the others ignore
the problem, and where you have to deal with the possibility to be
interupted by asynchronous exceptions.
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.
** The point is that sometimes you don't need or don't want the features and
you can restrict yourself to the "subset of C++" and this is what I call go
back to C.

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

** I don't confuse language and policies, I understand the Microsoft's
policy I know things may change in the near future. I know a number U*xes
that don't use C++ frameworks (they apply the same policy), that is no
template libraries and no C++ exceptions.

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.

** Agreed, but that a fact of life, unless you build your own toolset, you
have to use the compilers and libraries that are available on a platform and
respect the guidelines outlined for the platform, it's true it doesn't
affect the language choice, but it restricts you to a subset of the
language.

Willy.

[Willy Denoyette [MVP]]

"Andrew" <no******************@earth.universe> wrote in message
news:fw*****************************@40tude.net...

On 2 Sep 2005 06:46:04 -0700, bjarne wrote:

I thought I was pretty clear about that: Yes the aim of C++ was to

I have to say - I was kinda thinking - huh? How could he have been any
clearer?

Maybe I'm not that smart as you are :-)

Willy.

[Andrew]

On Fri, 2 Sep 2005 19:28:21 +0200, Willy Denoyette [MVP] wrote:

"Andrew" <no******************@earth.universe> wrote in message
news:fw*****************************@40tude.net...

On 2 Sep 2005 06:46:04 -0700, bjarne wrote:

I thought I was pretty clear about that: Yes the aim of C++ was to

I have to say - I was kinda thinking - huh? How could he have been any
clearer?

Maybe I'm not that smart as you are :-)

Actually, you seem to be very intelligent - I'm just not sure where you got
the idea he hadn't answered your question after he seemed to put it so
straight forward (to me..)

Cheers

- Andrew

[Cool Guy]

"Willy Denoyette [MVP]" <wi*************@telenet.be> wrote:

[snip]

No offense intended, but why not get a newsreader that actually quotes
correctly?

It's not very easy to determine which words are yours and which are quoted
in some of your posts.

[Willy Denoyette [MVP]]

"Cool Guy" <co*****@abc.xyz> wrote in message
news:h8**************@cool.guy.abc.xyz...

"Willy Denoyette [MVP]" <wi*************@telenet.be> wrote:

[snip]

No offense intended, but why not get a newsreader that actually quotes
correctly?

It's not very easy to determine which words are yours and which are quoted
in some of your posts.

My newsreader is set to indent the original message with a >. I noticed that
this was not longer done when replying to Bjarne's replies, that's why I
explicitely added ** to my replies.

Willy.