Is C faster than C++

[zhaoyandong]

In one of my interview, some people asked me why C is faster C++, and tell
me to illustrate at least two reasons.

I can't find the answer in the web.

I'll appreciate any suggestion on this.
Thank you.

[Dave Rahardja]

On Sun, 2 Oct 2005 13:47:10 -0400, "P.J. Plauger" <pj*@dinkumware.com> wrote:

The fundamental issue is whether programming in C++ yields
programs that are larger and slower than comparable programs
written in C. In my extensive experience, the simple answer
is yes. The most prudent course for a project manager is to
assume 5 to 15 per cent overheads, and take for granted that
the benefits of C++ will justify the extra costs. I went
through a similar period with C a few decades ago, selling
it against assembly language. I agree the overheads can be
managed, often significantly reduced; and it's worth teaching
people how to do so. But pretending that the problem doesn't
exist at all does not help our credibility with a rightly
critical audience of potential new users.

Now this I can agree with. Let's leave it at that, shall we?

-dr

[Branimir Maksimovic]

Dave Rahardja wrote:

On Fri, 30 Sep 2005 17:49:09 +0200, "Branimir Maksimovic" <bm***@eunet.yu>
wrote:

If
exception
handling is not required, we can properly declare non-throwing functions
with
the throw() specification, or resort to compiler switches. I also imagine
that
a C++ compiler can assume that C functions declared extern "C" do not
throw.
throw() wouldn't help.
To quote part of 15.5.1:
"An implementation is not permitted to finish stack unwinding prematurely
based on a determination that the unwind process will eventually cause
a call to terminate()."

[snip]

I've just investigated further. Exception specification makes run time
overhead to function
only if function throws or calls function that does not have throw()
specification.

This has also been my experience. The overhead of non-throwing functions is
exactly ZERO, both in run time code and in data space.

........ With that quick exercise it is easy to see that exception handling overhead is
exactly _zero_ with MSVC++ .NET when functions are properly declared throw().
Furthermore, MSVC is smart enough to figure out that extern "C" functions do
not throw.
My experience with the embedded compiler that I use daily has been the same:
the exception handling overhead for properly-declared code is not only
trivial, it is _zero_.

However, I will admit again that the decision to assume that functions with no
throw clause can "throw anything" instead of "throw nothing" makes it very
difficult for compilers to automatically elide the generation of exception
handling infrastructure. Declaring functions throw() when it really doesn't
throw anything is good practice whenever resources are at a premium.

Yes, throw() specification seems to be the best practice, because
it completely eliminates exception code and data both on linux and
windows with gcc, too. Without them even C compiled as C++ has overhead
on linux. One thing more , for gcc extern "C" functions have to be
declared throw() as well. On windows && gcc,every function that have
destructor(s) (and there are almost no C++ programs that doesn't have
auto objects in functions)executed has big run time overhead
(entry/exit exception code added).
So, mister P.J.Plauger is generaly right, we have to put lot's of
throw()
specifications in order to avoid either code bloat(linux) or run time
penalty
and code bloat(windows), even with same compiler on different
platforms.

Greetings, Bane.

[Greg]

Branimir Maksimovic wrote:

Dave Rahardja wrote:

On Fri, 30 Sep 2005 17:49:09 +0200, "Branimir Maksimovic" <bm***@eunet.yu>
wrote:

>> If
>> exception
>> handling is not required, we can properly declare non-throwing functions
>> with
>> the throw() specification, or resort to compiler switches. I also imagine
>> that
>> a C++ compiler can assume that C functions declared extern "C" do not
>> throw.
>>
>
> throw() wouldn't help.
> To quote part of 15.5.1:
> "An implementation is not permitted to finish stack unwinding prematurely
> based on a determination that the unwind process will eventually cause
> a call to terminate()."

[snip]

I've just investigated further. Exception specification makes run time
overhead to function
only if function throws or calls function that does not have throw()
specification.

This has also been my experience. The overhead of non-throwing functions is
exactly ZERO, both in run time code and in data space.

.......

With that quick exercise it is easy to see that exception handling overhead is
exactly _zero_ with MSVC++ .NET when functions are properly declared throw().
Furthermore, MSVC is smart enough to figure out that extern "C" functions do
not throw.
My experience with the embedded compiler that I use daily has been the same:
the exception handling overhead for properly-declared code is not only
trivial, it is _zero_.

However, I will admit again that the decision to assume that functions with no
throw clause can "throw anything" instead of "throw nothing" makes it very
difficult for compilers to automatically elide the generation of exception
handling infrastructure. Declaring functions throw() when it really doesn't
throw anything is good practice whenever resources are at a premium.

Yes, throw() specification seems to be the best practice, because
it completely eliminates exception code and data both on linux and
windows with gcc, too. Without them even C compiled as C++ has overhead
on linux. One thing more , for gcc extern "C" functions have to be
declared throw() as well. On windows && gcc,every function that have
destructor(s) (and there are almost no C++ programs that doesn't have
auto objects in functions)executed has big run time overhead
(entry/exit exception code added).
So, mister P.J.Plauger is generaly right, we have to put lot's of
throw()
specifications in order to avoid either code bloat(linux) or run time
penalty
and code bloat(windows), even with same compiler on different
platforms.

Greetings, Bane.

There are some compilers that have "zero runtime overhead" exception
handling; but the tradeoff they make is in size. Exception support can
add significantly to the size of compiled code.

I don't see how a throw() specification would be likely to eliminate
any exception processing overhead. After all, a throw() specification
is no guarantee that the function will not throw an exception. It only
guarantees that a caller will never be able to catch an exception
thrown during a call to that routine [because the program will have
stopped running]. And in order to provide this guarantee the compiler
must add exception processing logic to a function with a throw()
specification just to make sure that no thrown exceptions are allowed
to escape.

In short, to eliminate exception overhead really requires going outside
the syntax defined by the language and to use use a pragma or an other
compiler-dependent way to disable the feature.

Greg

[Branimir Maksimovic]

Greg wrote:

Branimir Maksimovic wrote:

Dave Rahardja wrote:

On Fri, 30 Sep 2005 17:49:09 +0200, "Branimir Maksimovic" <bm***@eunet.yu>
wrote:

>>> If
>>> exception
>>> handling is not required, we can properly declare non-throwing functions
>>> with
>>> the throw() specification, or resort to compiler switches. I also imagine
>>> that
>>> a C++ compiler can assume that C functions declared extern "C" do not
>>> throw.
>>>
>>
>> throw() wouldn't help.
>> To quote part of 15.5.1:
>> "An implementation is not permitted to finish stack unwinding prematurely
>> based on a determination that the unwind process will eventually cause
>> a call to terminate()."

[snip]

>I've just investigated further. Exception specification makes run time
>overhead to function
>only if function throws or calls function that does not have throw()
>specification.

This has also been my experience. The overhead of non-throwing functions is
exactly ZERO, both in run time code and in data space.
.......

With that quick exercise it is easy to see that exception handling overhead is
exactly _zero_ with MSVC++ .NET when functions are properly declared throw().
Furthermore, MSVC is smart enough to figure out that extern "C" functions do
not throw.
My experience with the embedded compiler that I use daily has been the same:
the exception handling overhead for properly-declared code is not only
trivial, it is _zero_.

However, I will admit again that the decision to assume that functions with no
throw clause can "throw anything" instead of "throw nothing" makes it very
difficult for compilers to automatically elide the generation of exception
handling infrastructure. Declaring functions throw() when it really doesn't
throw anything is good practice whenever resources are at a premium.

Yes, throw() specification seems to be the best practice, because
it completely eliminates exception code and data both on linux and
windows with gcc, too. Without them even C compiled as C++ has overhead
on linux. One thing more , for gcc extern "C" functions have to be
declared throw() as well. On windows && gcc,every function that have
destructor(s) (and there are almost no C++ programs that doesn't have
auto objects in functions)executed has big run time overhead
(entry/exit exception code added).
So, mister P.J.Plauger is generaly right, we have to put lot's of
throw()
specifications in order to avoid either code bloat(linux) or run time
penalty
and code bloat(windows), even with same compiler on different
platforms.

Greetings, Bane.

There are some compilers that have "zero runtime overhead" exception
handling; but the tradeoff they make is in size. Exception support can
add significantly to the size of compiled code.

I don't see how a throw() specification would be likely to eliminate
any exception processing overhead. After all, a throw() specification
is no guarantee that the function will not throw an exception. It only
guarantees that a caller will never be able to catch an exception
thrown during a call to that routine [because the program will have
stopped running].

Well if you look at my previous post that is what I thought about
throw().
But, it simply elliminates any trace of exception handling code and
data in gcc object files. I guess compiler knows that
eh code is not needed if every single function used in compilation unit
(declared or defined) has throw() specification.

And in order to provide this guarantee the compiler must add exception processing logic to a function with a throw()
specification just to make sure that no thrown exceptions are allowed
to escape.

I looked at generated assembly and this is not the case.
If function has throw() specification (with or without auto objects
with destructors)and does not calls something that
can throw (it is good practice that destructors have throw()
anyway) no eh code or data is generated for that function.
It seems that that is the case with VC too (according to Dave).
So, finally this thread gaved me a good knowledge about exception
specs, and when they should be used - in functions that actually
don't throw exceptions :)
I was rather carelless about specs, but now, I know that compilers
can optimise unnedded eh code and data out when they see them.
They won't heart anyway.

Greetings, Bane.

[Dave Rahardja]

On 3 Oct 2005 15:03:55 -0700, "Greg" <gr****@pacbell.net> wrote:

There are some compilers that have "zero runtime overhead" exception
handling; but the tradeoff they make is in size. Exception support can
add significantly to the size of compiled code.
Yes, I've seen at least one implementation that uses a static table of "throw
ranges" or "call sites" to deduce the objects that need to be destructed if an
exception were to be thrown at that point. Such implementations have literally
zero execution overhead (using no additional stack space and no additional
instructions in the stream). When exceptions are thrown control is passed to a
global exception handler, along with the current exception-thrower's address
and stack pointer and does the unwinding based on the tables.

The cost is obviously the substantial tables that need to be linked in
(although in most OS implementations this can be done so that the tables do
not get paged into physical memory until an exception actually occurs).
I don't see how a throw() specification would be likely to eliminate
any exception processing overhead. After all, a throw() specification
is no guarantee that the function will not throw an exception.
Actually it does (see 15.4.11), or at least /should/. However, the throw()
specification does not become part of the function type, so a function
declared throw() in one module looks identical to the linker as the function
defined without the throw-specification.

MSVC at least does give a compile-time warning if you declare a function
throw() and then proceed to throw an exception in it.

I guess the secret is to use the same declaration (i.e. header file) for the
declaration of a function everywhere in the program.
In short, to eliminate exception overhead really requires going outside
the syntax defined by the language and to use use a pragma or an other
compiler-dependent way to disable the feature.

To completely eradicate exception handling overhead once and for all you
probably need to use a compiler switch. I wonder what this does to library
functions that are specified to throw exceptions though, such as operator
new().

-dr