Re: performance

Inline ***

Partly trimmed.

Willy.

"bjarne" <bjarne@xxxxxxxxx> wrote in message
news:1125668764.784221.226630@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

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)

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


.

Relevant Pages

  • 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: 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: [announcement] SYSAPI and SYSSVC for Windows
    ... Ada has its own concept. ... I know no language which ... But there are also numerous problems with exceptions in Ada. ... > supporting such languages as Ada. ...
    (comp.lang.ada)
  • Re: Ada exception block does NOT work?
    ... >> Ada has had exceptions, well integrated with the rest of the language, ... >> since Ada 80. ... > language that has no history issue like this. ... An exception at is handled by the handler, ...
    (comp.lang.ada)