Using throw(): to use or not to use?

Using throw(): to use or not to use?

[Maxim Dementiev]

Can you tell me, please, why using of "throw()" for static exception
function specification causes slowing down speed under gcc 3.0.2
with -O0, -O1 and -O2?

Maxim Dementiev

Re: Using throw(): to use or not to use?

[Joe Buck]

> Can you tell me, please, why using of "throw()" for static exception
> function specification causes slowing down speed under gcc 3.0.2
> with -O0, -O1 and -O2?

This seems surprising, but you haven't specified what platform you are
using and you haven't provided sample code, so it's hard to figure out
why you are seeing a slowdown.

Specififying throw() should, if anything, make it possible to generate
slightly faster code.  If the code is instead slower, I'd call it a bug,
but we'd need a full bug report.

Re: Using throw(): to use or not to use?

[Alexandre Oliva]

On Nov 29, 2001, Joe Buck <jbuck@synopsys.COM> wrote:

> Specififying throw() should, if anything, make it possible to generate
> slightly faster code.

Unless you're talking about the function marked as throw() itself,
with an EH model such as setjmp().  This would require the function to
set up handlers that would call unexpected() should the function throw
or propagate some inappropriate exception.

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                  aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist    *Please* write to mailing lists, not to me

Re: Using throw(): to use or not to use?

[Joe Buck]

> 
> On Nov 29, 2001, Joe Buck <jbuck@synopsys.COM> wrote:
> 
> > Specififying throw() should, if anything, make it possible to generate
> > slightly faster code.
> 
> Unless you're talking about the function marked as throw() itself,
> with an EH model such as setjmp().  This would require the function to
> set up handlers that would call unexpected() should the function throw
> or propagate some inappropriate exception.

Such handlers are only necessary if the function marked as throw() calls
some other function that is not marked as throw(), or operator new.
But yes, you're correct in that there can be a cost for setting up
this handler.  However, for the case of the function itself throwing
there need be no overhead for the cases where these throws are not
reached, so it is only the propagation of exceptions from other calls
that is a cost.

Re: Using throw(): to use or not to use?

[Frank Ch. Eigler]

Joe Buck <jbuck@synopsys.COM> writes:

: [...]  Specififying throw() should, if anything, make it possible to
: generate slightly faster code.  If the code is instead slower, I'd
: call it a bug, [...]

Not really.  Within the body of a function declared with throw(), the
compiler must normally emit *extra* code that asserts that there are
no exceptions thrown from it, sort of like this:

   try { BODY } catch (...) { abort(); }

The *caller* of such a function may in turn assume that no exceptions
can come back out, so the compiler may (eventually?) optimize based on
that.  So, specifying throw() allows new optimization opportunities
only at the caller.


- FChE

Re: Using throw(): to use or not to use?

[Joe Buck]

> 
> 
> Joe Buck <jbuck@synopsys.COM> writes:
> 
> : [...]  Specififying throw() should, if anything, make it possible to
> : generate slightly faster code.  If the code is instead slower, I'd
> : call it a bug, [...]
> 
> Not really.  Within the body of a function declared with throw(), the
> compiler must normally emit *extra* code that asserts that there are
> no exceptions thrown from it, sort of like this:
> 
>    try { BODY } catch (...) { abort(); }

unless the function is a leaf, or only calls throw() functions.

> The *caller* of such a function may in turn assume that no exceptions
> can come back out, so the compiler may (eventually?) optimize based on
> that.  So, specifying throw() allows new optimization opportunities
> only at the caller.

Right.

Using throw(): continue with "simple code"...

[Maxim Dementiev]

-----Original Message-----
From: Joe Buck [mailto:jbuck@synopsys.com]
Sent: Thursday, November 29, 2001 8:35 PM
To: Maxim Dementiev
Cc: gcc@gcc.gnu.org
Subject: Re: Using throw(): to use or not to use?
>
> This seems surprising, but you haven't specified what platform you are
> using and you haven't provided sample code, so it's hard to figure out
> why you are seeing a slowdown.
>
> Specififying throw() should, if anything, make it possible to generate
> slightly faster code.  If the code is instead slower, I'd call it a bug,
> but we'd need a full bug report.

Oh, I'm sorry!

Linux 2.2.19 (Slackware 8.0), Intel Celeron (Mendocino).
gcc 3.0.2 was builded with gcc 2.95.3 (from slackware).
Here is "simple code" (this is modification of
http://cpp3.virtualave.net/cpp3comm/043).
This code with "throw()". Just cancel out "throw()" and try again with same
argument.


-=-=-=-=-=-=-=-=- start -=-=-=-=-=-=-=-=-

#include <stdio.h>
#include <stdlib.h>
#include <time.h>


long Var=0, Count=0;


void some_func() throw();


class A
{
public:
    A() throw();
    ~A() throw();
};


void ACon() throw();
void ADes() throw();
void f1() throw();
void f2() throw();


int main( int argc, char** argv )
{
    if (argc>1) Count=atol(argv[1]);

    clock_t c1,c2;
    {
        c1=clock();

        for( long i=0; i<Count; i++ )
            for( long j=0; j<1000000; j++ )
                f1();

        c2=clock();

        printf( "f1(): %ld mlns calls per %.1f sec\n",
                Count,
                double(c2-c1)/CLOCKS_PER_SEC );
    }

    {
        c1=clock();

        for( long i=0; i<Count; i++ )
            for( long j=0; j<1000000; j++ )
                f2();

        c2=clock();

        printf( "f2(): %ld mlns calls per %.1f sec\n",
                Count,
                double(c2-c1)/CLOCKS_PER_SEC );
    }

    return 0;
}


void f1() throw()
{
    A a;
}


void f2() throw()
{
    ACon();
    ADes();
}


A::A() throw()
{
    some_func();
}


A::~A() throw()
{
    some_func();
}


void ACon() throw()
{
    some_func();
}


void ADes() throw()
{
    some_func();
}


void some_func() throw()
{
    Var++;
}

-=-=-=-=-=-=-=-=- end -=-=-=-=-=-=-=-=-

My test results (with 500 iteration X 1 mlns):
-----------------------------------------------------
                   -O0       -O1       -O2
-----------------------------------------------------
with
throw()  53.2/45.2  50.6/42.0  45.5/43.1
-----------------------------------------------------
without
throw()  50.9/45.5  48.8/41.2  44.4/40.8
-----------------------------------------------------

Maxim Dementiev

Using throw(): to use or not to use?

[Maxim Dementiev]

Can you tell me, please, why using of "throw()" for static exception
function specification causes slowing down speed under gcc 3.0.2
with -O0, -O1 and -O2?

Maxim Dementiev

Re: Using throw(): to use or not to use?

[Joe Buck]

> Can you tell me, please, why using of "throw()" for static exception
> function specification causes slowing down speed under gcc 3.0.2
> with -O0, -O1 and -O2?

This seems surprising, but you haven't specified what platform you are
using and you haven't provided sample code, so it's hard to figure out
why you are seeing a slowdown.

Specififying throw() should, if anything, make it possible to generate
slightly faster code.  If the code is instead slower, I'd call it a bug,
but we'd need a full bug report.

Re: Using throw(): to use or not to use?

[Alexandre Oliva]

On Nov 29, 2001, Joe Buck <jbuck@synopsys.COM> wrote:

> Specififying throw() should, if anything, make it possible to generate
> slightly faster code.

Unless you're talking about the function marked as throw() itself,
with an EH model such as setjmp().  This would require the function to
set up handlers that would call unexpected() should the function throw
or propagate some inappropriate exception.

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                  aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist    *Please* write to mailing lists, not to me

Re: Using throw(): to use or not to use?

[Joe Buck]

> 
> On Nov 29, 2001, Joe Buck <jbuck@synopsys.COM> wrote:
> 
> > Specififying throw() should, if anything, make it possible to generate
> > slightly faster code.
> 
> Unless you're talking about the function marked as throw() itself,
> with an EH model such as setjmp().  This would require the function to
> set up handlers that would call unexpected() should the function throw
> or propagate some inappropriate exception.

Such handlers are only necessary if the function marked as throw() calls
some other function that is not marked as throw(), or operator new.
But yes, you're correct in that there can be a cost for setting up
this handler.  However, for the case of the function itself throwing
there need be no overhead for the cases where these throws are not
reached, so it is only the propagation of exceptions from other calls
that is a cost.

Re: Using throw(): to use or not to use?

[Frank Ch. Eigler]

Joe Buck <jbuck@synopsys.COM> writes:

: [...]  Specififying throw() should, if anything, make it possible to
: generate slightly faster code.  If the code is instead slower, I'd
: call it a bug, [...]

Not really.  Within the body of a function declared with throw(), the
compiler must normally emit *extra* code that asserts that there are
no exceptions thrown from it, sort of like this:

   try { BODY } catch (...) { abort(); }

The *caller* of such a function may in turn assume that no exceptions
can come back out, so the compiler may (eventually?) optimize based on
that.  So, specifying throw() allows new optimization opportunities
only at the caller.


- FChE

Re: Using throw(): to use or not to use?

[Joe Buck]

> 
> 
> Joe Buck <jbuck@synopsys.COM> writes:
> 
> : [...]  Specififying throw() should, if anything, make it possible to
> : generate slightly faster code.  If the code is instead slower, I'd
> : call it a bug, [...]
> 
> Not really.  Within the body of a function declared with throw(), the
> compiler must normally emit *extra* code that asserts that there are
> no exceptions thrown from it, sort of like this:
> 
>    try { BODY } catch (...) { abort(); }

unless the function is a leaf, or only calls throw() functions.

> The *caller* of such a function may in turn assume that no exceptions
> can come back out, so the compiler may (eventually?) optimize based on
> that.  So, specifying throw() allows new optimization opportunities
> only at the caller.

Right.

Using throw(): continue with "simple code"...

[Maxim Dementiev]

-----Original Message-----
From: Joe Buck [ mailto:jbuck@synopsys.com ]
Sent: Thursday, November 29, 2001 8:35 PM
To: Maxim Dementiev
Cc: gcc@gcc.gnu.org
Subject: Re: Using throw(): to use or not to use?
>
> This seems surprising, but you haven't specified what platform you are
> using and you haven't provided sample code, so it's hard to figure out
> why you are seeing a slowdown.
>
> Specififying throw() should, if anything, make it possible to generate
> slightly faster code.  If the code is instead slower, I'd call it a bug,
> but we'd need a full bug report.

Oh, I'm sorry!

Linux 2.2.19 (Slackware 8.0), Intel Celeron (Mendocino).
gcc 3.0.2 was builded with gcc 2.95.3 (from slackware).
Here is "simple code" (this is modification of
http://cpp3.virtualave.net/cpp3comm/043 ).
This code with "throw()". Just cancel out "throw()" and try again with same
argument.


-=-=-=-=-=-=-=-=- start -=-=-=-=-=-=-=-=-

#include <stdio.h>
#include <stdlib.h>
#include <time.h>


long Var=0, Count=0;


void some_func() throw();


class A
{
public:
    A() throw();
    ~A() throw();
};


void ACon() throw();
void ADes() throw();
void f1() throw();
void f2() throw();


int main( int argc, char** argv )
{
    if (argc>1) Count=atol(argv[1]);

    clock_t c1,c2;
    {
        c1=clock();

        for( long i=0; i<Count; i++ )
            for( long j=0; j<1000000; j++ )
                f1();

        c2=clock();

        printf( "f1(): %ld mlns calls per %.1f sec\n",
                Count,
                double(c2-c1)/CLOCKS_PER_SEC );
    }

    {
        c1=clock();

        for( long i=0; i<Count; i++ )
            for( long j=0; j<1000000; j++ )
                f2();

        c2=clock();

        printf( "f2(): %ld mlns calls per %.1f sec\n",
                Count,
                double(c2-c1)/CLOCKS_PER_SEC );
    }

    return 0;
}


void f1() throw()
{
    A a;
}


void f2() throw()
{
    ACon();
    ADes();
}


A::A() throw()
{
    some_func();
}


A::~A() throw()
{
    some_func();
}


void ACon() throw()
{
    some_func();
}


void ADes() throw()
{
    some_func();
}


void some_func() throw()
{
    Var++;
}

-=-=-=-=-=-=-=-=- end -=-=-=-=-=-=-=-=-

My test results (with 500 iteration X 1 mlns):
-----------------------------------------------------
                   -O0       -O1       -O2
-----------------------------------------------------
with
throw()  53.2/45.2  50.6/42.0  45.5/43.1
-----------------------------------------------------
without
throw()  50.9/45.5  48.8/41.2  44.4/40.8
-----------------------------------------------------

Maxim Dementiev