Re: performance of complex arithmetic

Re: performance of complex arithmetic

[Stephen L Moshier]

    Is any work being done on the improvement of complex arithmetic?

I am currently interested in this subject and would like to receive
simple test cases of inefficient or wrong code relating to the native
complex type (preferably in C, as opposed to FORTRAN or C++).


    `gcc' has some known problems in its back-end support for
    `complex' arithmetic, due primarily to the support not being
    completed as of version 2.7.2.2.

This remark is a bit obsolete.  There was a severe problem in gcc-2.7
on i386, but it was fixed in gcc-2.8.  Currently gcc's native complex
data type seems to work pretty well in C language, except that single
precision complex does not yet work on 64-bit target computers.

Re: performance of complex arithmetic

[Michael Hayes]

Stephen L Moshier writes:
 > I am currently interested in this subject and would like to receive
 > simple test cases of inefficient or wrong code relating to the native
 > complex type (preferably in C, as opposed to FORTRAN or C++).

OK, a very simple case is the loading of complex constants.  These
always appear to be forced into memory by expand_expr.   Try this:

 __complex__ float foo(void)
{
    return 0.0 + 0.0fi;
}

I've got many other simple testcases I can fire at you.  At the
moment, the crippling factor for complex vector arithmetic on the C4x
is a poor combination of GIVs in strength reduction.  This is another
story...


Michael.

Re: performance of complex arithmetic [gremlins]

[Michael Hayes]

Michael Hayes writes:

 > I've got many other simple testcases I can fire at you.  

Ah, but not the same one three times!  Sorry about that folks.  I
wonder what my mail client thought it was up to?

Michael.

RE: performance of complex arithmetic

[Peter Bienstman]

>>     `gcc' has some known problems in its back-end support for
>>     `complex' arithmetic, due primarily to the support not being
>>     completed as of version 2.7.2.2.
>
> This remark is a bit obsolete.  There was a severe problem in gcc-2.7
> on i386, but it was fixed in gcc-2.8.

Indeed, that seems to be true. The flag '-fno-emulate-complex' doesn't seem
to influence the created binaries. It's probably time to get rid of the
scaring documentation for this switch in the g77 info-files?

> I am currently interested in this subject and would like to receive
> simple test cases of inefficient or wrong code relating to the native
> complex type (preferably in C, as opposed to FORTRAN or C++).

I wasn't actually aware you could do native complex arithmetic in C. Here
are some links to sample test programs (C++) regarding the elimination of
complex temporaries:

http://monet.uwaterloo.ca/blitz/contribute/blitz-dev/archive/0108.html
http://monet.uwaterloo.ca/blitz/contribute/blitz-dev/archive/0109.html

I'm not sure however if the problem lies in the native complex type in the
backend or in the C++ frontend.

Greetings,

-------------------------------------
Peter Bienstman
Department of Information Technology
INTEC/IMEC - University of Gent
St.-Pietersnieuwstraat 41
B-9000 Gent - Belgium
E-mail: Peter.Bienstman@rug.ac.be
Tel: +32 9 264 3445
Fax: +32 9 264 3593
-------------------------------------

RE: performance of complex arithmetic

[Stephen L Moshier]

> I wasn't actually aware you could do native complex arithmetic in C. Here
> are some links to sample test programs (C++) regarding the elimination of
> complex temporaries:
> 
> http://monet.uwaterloo.ca/blitz/contribute/blitz-dev/archive/0108.html
> http://monet.uwaterloo.ca/blitz/contribute/blitz-dev/archive/0109.html
> 
> I'm not sure however if the problem lies in the native complex type in the
> backend or in the C++ frontend.

This one, 0109.html, optimizes ok when rewritten in C to use the built-in
complex type.  I don't know enough about the C++ or FORTRAN to say why
they would have trouble with it.  I could not locate the test case
mentioned in number 0108.html.


#include <complex.h>

void sink(complex<double>&);

void foo()
{
complex<double> a;
sink(a);
complex<double> b = a;
complex<double> c = b;
complex<double> d = c;
complex<double> e = d;
complex<double> f = e;
sink(f);
}

RE: performance of complex arithmetic

[Joe Buck]

> This one, 0109.html, optimizes ok when rewritten in C to use the built-in
> complex type.  I don't know enough about the C++ or FORTRAN to say why
> they would have trouble with it.  I could not locate the test case
> mentioned in number 0108.html.

The backend has special support for the builtin C complex; the C++ complex
just uses the generic struct stuff, which isn't so good.

In principle it would be possible to rewrite libstdc++'s <complex> to
use this builtin support.  However, ideally special builtin complex
support shouldn't be needed, rather the same special handling should be
available for all structs (let the compiler treat them as an unordered
collection of values unless they are being read or written to a
struct/class variable in memory ... even for spills you can spill the
different members separately).

Re: performance of complex arithmetic

[craig]

>Indeed, that seems to be true. The flag '-fno-emulate-complex' doesn't seem
>to influence the created binaries. It's probably time to get rid of the
>scaring documentation for this switch in the g77 info-files?

The `-fno-emulate-complex' flag applies only to g77-compiled code, I
believe.  If you used it compiling C or C++ code, for example, it
would (presumably) be silently accepted and have no effect, while any
Fortran code in files listed on the same command line *would* be
affected.

There are still bugs in the back end, I believe, leading to the
generation of incorrect code is `-fno-emulate-complex' is specified
when compiling using g77.

In g77, I'm pretty sure `-fno-emulate-complex' still makes a big
difference in *how* complex code is generated.  But I suppose it's
possible there are complex codes for which it makes no difference
in *what* ultimately gets generated.

        tq vm, (burley)

Re: performance of complex arithmetic

[Stephen L Moshier]

On 27 Jan 1999 craig@jcb-sc.com wrote:

> There are still bugs in the back end, I believe, leading to the
> generation of incorrect code is `-fno-emulate-complex' is specified
> when compiling using g77.

I don't think anyone is addressing this, except for the problems with
single precision complex on 64-bit machines.  Please post test cases
if you have them.

Re: performance of complex arithmetic

[craig]

>Indeed, that seems to be true. The flag '-fno-emulate-complex' doesn't seem
>to influence the created binaries. It's probably time to get rid of the
>scaring documentation for this switch in the g77 info-files?

The `-fno-emulate-complex' flag applies only to g77-compiled code, I
believe.  If you used it compiling C or C++ code, for example, it
would (presumably) be silently accepted and have no effect, while any
Fortran code in files listed on the same command line *would* be
affected.

There are still bugs in the back end, I believe, leading to the
generation of incorrect code is `-fno-emulate-complex' is specified
when compiling using g77.

In g77, I'm pretty sure `-fno-emulate-complex' still makes a big
difference in *how* complex code is generated.  But I suppose it's
possible there are complex codes for which it makes no difference
in *what* ultimately gets generated.

        tq vm, (burley)

RE: performance of complex arithmetic

[Joe Buck]

> This one, 0109.html, optimizes ok when rewritten in C to use the built-in
> complex type.  I don't know enough about the C++ or FORTRAN to say why
> they would have trouble with it.  I could not locate the test case
> mentioned in number 0108.html.

The backend has special support for the builtin C complex; the C++ complex
just uses the generic struct stuff, which isn't so good.

In principle it would be possible to rewrite libstdc++'s <complex> to
use this builtin support.  However, ideally special builtin complex
support shouldn't be needed, rather the same special handling should be
available for all structs (let the compiler treat them as an unordered
collection of values unless they are being read or written to a
struct/class variable in memory ... even for spills you can spill the
different members separately).

Re: performance of complex arithmetic

[Michael Hayes]

Stephen L Moshier writes:
 > I am currently interested in this subject and would like to receive
 > simple test cases of inefficient or wrong code relating to the native
 > complex type (preferably in C, as opposed to FORTRAN or C++).

OK, a very simple case is the loading of complex constants.  These
always appear to be forced into memory by expand_expr.   Try this:

 __complex__ float foo(void)
{
    return 0.0 + 0.0fi;
}

I've got many other simple testcases I can fire at you.  At the
moment, the crippling factor for complex vector arithmetic on the C4x
is a poor combination of GIVs in strength reduction.  This is another
story...


Michael.

Re: performance of complex arithmetic

[Stephen L Moshier]

    Is any work being done on the improvement of complex arithmetic?

I am currently interested in this subject and would like to receive
simple test cases of inefficient or wrong code relating to the native
complex type (preferably in C, as opposed to FORTRAN or C++).


    `gcc' has some known problems in its back-end support for
    `complex' arithmetic, due primarily to the support not being
    completed as of version 2.7.2.2.

This remark is a bit obsolete.  There was a severe problem in gcc-2.7
on i386, but it was fixed in gcc-2.8.  Currently gcc's native complex
data type seems to work pretty well in C language, except that single
precision complex does not yet work on 64-bit target computers.

RE: performance of complex arithmetic

[Stephen L Moshier]

> I wasn't actually aware you could do native complex arithmetic in C. Here
> are some links to sample test programs (C++) regarding the elimination of
> complex temporaries:
> 
> http://monet.uwaterloo.ca/blitz/contribute/blitz-dev/archive/0108.html
> http://monet.uwaterloo.ca/blitz/contribute/blitz-dev/archive/0109.html
> 
> I'm not sure however if the problem lies in the native complex type in the
> backend or in the C++ frontend.

This one, 0109.html, optimizes ok when rewritten in C to use the built-in
complex type.  I don't know enough about the C++ or FORTRAN to say why
they would have trouble with it.  I could not locate the test case
mentioned in number 0108.html.


#include <complex.h>

void sink(complex<double>&);

void foo()
{
complex<double> a;
sink(a);
complex<double> b = a;
complex<double> c = b;
complex<double> d = c;
complex<double> e = d;
complex<double> f = e;
sink(f);
}

RE: performance of complex arithmetic

[Peter Bienstman]

>>     `gcc' has some known problems in its back-end support for
>>     `complex' arithmetic, due primarily to the support not being
>>     completed as of version 2.7.2.2.
>
> This remark is a bit obsolete.  There was a severe problem in gcc-2.7
> on i386, but it was fixed in gcc-2.8.

Indeed, that seems to be true. The flag '-fno-emulate-complex' doesn't seem
to influence the created binaries. It's probably time to get rid of the
scaring documentation for this switch in the g77 info-files?

> I am currently interested in this subject and would like to receive
> simple test cases of inefficient or wrong code relating to the native
> complex type (preferably in C, as opposed to FORTRAN or C++).

I wasn't actually aware you could do native complex arithmetic in C. Here
are some links to sample test programs (C++) regarding the elimination of
complex temporaries:

http://monet.uwaterloo.ca/blitz/contribute/blitz-dev/archive/0108.html
http://monet.uwaterloo.ca/blitz/contribute/blitz-dev/archive/0109.html

I'm not sure however if the problem lies in the native complex type in the
backend or in the C++ frontend.

Greetings,

-------------------------------------
Peter Bienstman
Department of Information Technology
INTEC/IMEC - University of Gent
St.-Pietersnieuwstraat 41
B-9000 Gent - Belgium
E-mail: Peter.Bienstman@rug.ac.be
Tel: +32 9 264 3445
Fax: +32 9 264 3593
-------------------------------------

Re: performance of complex arithmetic [gremlins]

[Michael Hayes]

Michael Hayes writes:

 > I've got many other simple testcases I can fire at you.  

Ah, but not the same one three times!  Sorry about that folks.  I
wonder what my mail client thought it was up to?

Michael.

Re: performance of complex arithmetic

[Stephen L Moshier]

On 27 Jan 1999 craig@jcb-sc.com wrote:

> There are still bugs in the back end, I believe, leading to the
> generation of incorrect code is `-fno-emulate-complex' is specified
> when compiling using g77.

I don't think anyone is addressing this, except for the problems with
single precision complex on 64-bit machines.  Please post test cases
if you have them.

RE: performance of complex arithmetic

[Billinghurst, David (RTD)]

I can compile and run the LAPACK testsuite with 'FFLAGS=-O3 -funroll-loops'
using recent snapshots on Irix 6.2,
provided I compile routine SRC/cspr.f with -O1.

I have narrowed the problem down to
http://www.cygnus.com/ml/egcs-bugs/1999-Jan/0334.html

Interestingly, using -fnoemulate-complex gives an ICE 

/exd4/billingd/tmp/egcs-19990124/bin/g77 -O2 -g -Wall -o labug2a
-fno-emulate-complex labug2a.f
/exd4/billingd/src/egcs-19990124/gcc/emit-rtl.c:991: Internal compiler error
in function gen_lowpart


> -----Original Message-----
> From:	Toon Moene [SMTP:toon@moene.indiv.nluug.nl]
> Sent:	Thursday, January 28, 1999 1:18 AM
> To:	Peter.Bienstman@rug.ac.be
> Cc:	egcs@cygnus.com
> Subject:	Re: performance of complex arithmetic
> 
> Peter Bienstman wrote:
> 
> > I have a question regarding EGCS's performance on complex arithmetic.
> 
> > '-fno-emulate-complex'
> >      Implement `COMPLEX' arithmetic using the facilities in the `gcc'
> >      back end that provide direct support of `complex' arithmetic,
> >      instead of emulating the arithmetic.
> > 
> >      `gcc' has some known problems in its back-end support for
> >      `complex' arithmetic, due primarily to the support not being
> >      completed as of version 2.7.2.2.  Other front ends for the `gcc'
> >      back end avoid this problem by emulating `complex' arithmetic at a
> >      higher level, so the back end sees arithmetic on the real and
> >      imaginary components.
> > 
> > Is it true that the g++ ang g77 frontends still emulate complex
> arithmetic?
> > This would seem like a significant performance penalty, as the optimiser
> > would probably miss out on some optimisations.
> 
> Worse even, we _know_ it does.
> 
> The (remaining) problems seem to concentrate on targets with 64 bit
> words using single precision complex.  AFAICD, 32 bit targets do not
> suffer from "native complex" bugs anymore in current snapshots.
> 
> To check this, I ran LAPACK's testsuite to completion on my Pentium II
> based laptop, using:
> 
> [toon@moene LAPACK]$ /usr/snp/bin/gcc -v
> Reading specs from
> /usr/snp/lib/gcc-lib/i686-pc-linux-gnu/egcs-2.93.03/specs
> gcc version egcs-2.93.03 19990125 (gcc2 ss-980609 experimental)
> 
> with the following options:
> 
> OPTS     = -g -O3 -funroll-loops -fomit-frame-pointer
> -fno-emulate-complex -malign-double
> 
> without any problem.
> 
> Eliminating the -fno-emulate-complex option, I ran into the same problem
> as Josip Loncaric, namely that xlintstc (test driver for the single
> precision complex LINear algebra routines) crashed.  Because about one
> eighth of the complete LAPACK distribution is linked in with this
> program, there's little use posting the constituent parts here ;-)
> 
> People who'd like to investigate this have to download the LAPACK
> distribution themselves (which, BTW, is a very good test tool for a
> Fortran compiler by itself).
> 
> One note of caution, though:  Although the distribution itself is only
> about 4.5 Mb gzip'd, after unpacking and building you need about 120 Mb.
> 
> Cheers,
> 
> -- 
> Toon Moene (toon@moene.indiv.nluug.nl)
> Saturnushof 14, 3738 XG  Maartensdijk, The Netherlands
> Phone: +31 346 214290; Fax: +31 346 214286
> g77 Support: fortran@gnu.org; egcs: egcs-bugs@cygnus.com

performance of complex arithmetic

[Peter Bienstman]

Hello,

I have a question regarding EGCS's performance on complex arithmetic.

A first point regards the following switch for g77:

'-fno-emulate-complex'
     Implement `COMPLEX' arithmetic using the facilities in the `gcc'
     back end that provide direct support of `complex' arithmetic,
     instead of emulating the arithmetic.

     `gcc' has some known problems in its back-end support for
     `complex' arithmetic, due primarily to the support not being
     completed as of version 2.7.2.2.  Other front ends for the `gcc'
     back end avoid this problem by emulating `complex' arithmetic at a
     higher level, so the back end sees arithmetic on the real and
     imaginary components.

Is it true that the g++ ang g77 frontends still emulate complex arithmetic?
This would seem like a significant performance penalty, as the optimiser
would probably miss out on some optimisations.

Secondly, I was wondering if g++ is able to eliminate complex temporaries
the same way it is able to eliminate e.g. real or integer temporaries. A
while ago, this was a point of concern on the Blitz mailing list.

Is any work being done on the improvement of complex arithmetic? The code
I'm writing relies heavily on complex numbers, so it would be really bad
news if an otherwise great compiler wouldn't perform well in this area.

Greetings,

-------------------------------------
Peter Bienstman
Department of Information Technology
INTEC/IMEC - University of Gent
St.-Pietersnieuwstraat 41
B-9000 Gent - Belgium
E-mail: Peter.Bienstman@rug.ac.be
Tel: +32 9 264 3445
Fax: +32 9 264 3593
-------------------------------------

Re: performance of complex arithmetic

[Toon Moene]

Peter Bienstman wrote:

> I have a question regarding EGCS's performance on complex arithmetic.

> '-fno-emulate-complex'
>      Implement `COMPLEX' arithmetic using the facilities in the `gcc'
>      back end that provide direct support of `complex' arithmetic,
>      instead of emulating the arithmetic.
> 
>      `gcc' has some known problems in its back-end support for
>      `complex' arithmetic, due primarily to the support not being
>      completed as of version 2.7.2.2.  Other front ends for the `gcc'
>      back end avoid this problem by emulating `complex' arithmetic at a
>      higher level, so the back end sees arithmetic on the real and
>      imaginary components.
> 
> Is it true that the g++ ang g77 frontends still emulate complex arithmetic?
> This would seem like a significant performance penalty, as the optimiser
> would probably miss out on some optimisations.

Worse even, we _know_ it does.

The (remaining) problems seem to concentrate on targets with 64 bit
words using single precision complex.  AFAICD, 32 bit targets do not
suffer from "native complex" bugs anymore in current snapshots.

To check this, I ran LAPACK's testsuite to completion on my Pentium II
based laptop, using:

[toon@moene LAPACK]$ /usr/snp/bin/gcc -v
Reading specs from
/usr/snp/lib/gcc-lib/i686-pc-linux-gnu/egcs-2.93.03/specs
gcc version egcs-2.93.03 19990125 (gcc2 ss-980609 experimental)

with the following options:

OPTS     = -g -O3 -funroll-loops -fomit-frame-pointer
-fno-emulate-complex -malign-double

without any problem.

Eliminating the -fno-emulate-complex option, I ran into the same problem
as Josip Loncaric, namely that xlintstc (test driver for the single
precision complex LINear algebra routines) crashed.  Because about one
eighth of the complete LAPACK distribution is linked in with this
program, there's little use posting the constituent parts here ;-)

People who'd like to investigate this have to download the LAPACK
distribution themselves (which, BTW, is a very good test tool for a
Fortran compiler by itself).

One note of caution, though:  Although the distribution itself is only
about 4.5 Mb gzip'd, after unpacking and building you need about 120 Mb.

Cheers,

-- 
Toon Moene (toon@moene.indiv.nluug.nl)
Saturnushof 14, 3738 XG  Maartensdijk, The Netherlands
Phone: +31 346 214290; Fax: +31 346 214286
g77 Support: fortran@gnu.org; egcs: egcs-bugs@cygnus.com

RE: performance of complex arithmetic

[Billinghurst, David (RTD)]

I can compile and run the LAPACK testsuite with 'FFLAGS=-O3 -funroll-loops'
using recent snapshots on Irix 6.2,
provided I compile routine SRC/cspr.f with -O1.

I have narrowed the problem down to
http://www.cygnus.com/ml/egcs-bugs/1999-Jan/0334.html

Interestingly, using -fnoemulate-complex gives an ICE 

/exd4/billingd/tmp/egcs-19990124/bin/g77 -O2 -g -Wall -o labug2a
-fno-emulate-complex labug2a.f
/exd4/billingd/src/egcs-19990124/gcc/emit-rtl.c:991: Internal compiler error
in function gen_lowpart


> -----Original Message-----
> From:	Toon Moene [SMTP:toon@moene.indiv.nluug.nl]
> Sent:	Thursday, January 28, 1999 1:18 AM
> To:	Peter.Bienstman@rug.ac.be
> Cc:	egcs@cygnus.com
> Subject:	Re: performance of complex arithmetic
> 
> Peter Bienstman wrote:
> 
> > I have a question regarding EGCS's performance on complex arithmetic.
> 
> > '-fno-emulate-complex'
> >      Implement `COMPLEX' arithmetic using the facilities in the `gcc'
> >      back end that provide direct support of `complex' arithmetic,
> >      instead of emulating the arithmetic.
> > 
> >      `gcc' has some known problems in its back-end support for
> >      `complex' arithmetic, due primarily to the support not being
> >      completed as of version 2.7.2.2.  Other front ends for the `gcc'
> >      back end avoid this problem by emulating `complex' arithmetic at a
> >      higher level, so the back end sees arithmetic on the real and
> >      imaginary components.
> > 
> > Is it true that the g++ ang g77 frontends still emulate complex
> arithmetic?
> > This would seem like a significant performance penalty, as the optimiser
> > would probably miss out on some optimisations.
> 
> Worse even, we _know_ it does.
> 
> The (remaining) problems seem to concentrate on targets with 64 bit
> words using single precision complex.  AFAICD, 32 bit targets do not
> suffer from "native complex" bugs anymore in current snapshots.
> 
> To check this, I ran LAPACK's testsuite to completion on my Pentium II
> based laptop, using:
> 
> [toon@moene LAPACK]$ /usr/snp/bin/gcc -v
> Reading specs from
> /usr/snp/lib/gcc-lib/i686-pc-linux-gnu/egcs-2.93.03/specs
> gcc version egcs-2.93.03 19990125 (gcc2 ss-980609 experimental)
> 
> with the following options:
> 
> OPTS     = -g -O3 -funroll-loops -fomit-frame-pointer
> -fno-emulate-complex -malign-double
> 
> without any problem.
> 
> Eliminating the -fno-emulate-complex option, I ran into the same problem
> as Josip Loncaric, namely that xlintstc (test driver for the single
> precision complex LINear algebra routines) crashed.  Because about one
> eighth of the complete LAPACK distribution is linked in with this
> program, there's little use posting the constituent parts here ;-)
> 
> People who'd like to investigate this have to download the LAPACK
> distribution themselves (which, BTW, is a very good test tool for a
> Fortran compiler by itself).
> 
> One note of caution, though:  Although the distribution itself is only
> about 4.5 Mb gzip'd, after unpacking and building you need about 120 Mb.
> 
> Cheers,
> 
> -- 
> Toon Moene (toon@moene.indiv.nluug.nl)
> Saturnushof 14, 3738 XG  Maartensdijk, The Netherlands
> Phone: +31 346 214290; Fax: +31 346 214286
> g77 Support: fortran@gnu.org; egcs: egcs-bugs@cygnus.com

Re: performance of complex arithmetic

[Toon Moene]

Peter Bienstman wrote:

> I have a question regarding EGCS's performance on complex arithmetic.

> '-fno-emulate-complex'
>      Implement `COMPLEX' arithmetic using the facilities in the `gcc'
>      back end that provide direct support of `complex' arithmetic,
>      instead of emulating the arithmetic.
> 
>      `gcc' has some known problems in its back-end support for
>      `complex' arithmetic, due primarily to the support not being
>      completed as of version 2.7.2.2.  Other front ends for the `gcc'
>      back end avoid this problem by emulating `complex' arithmetic at a
>      higher level, so the back end sees arithmetic on the real and
>      imaginary components.
> 
> Is it true that the g++ ang g77 frontends still emulate complex arithmetic?
> This would seem like a significant performance penalty, as the optimiser
> would probably miss out on some optimisations.

Worse even, we _know_ it does.

The (remaining) problems seem to concentrate on targets with 64 bit
words using single precision complex.  AFAICD, 32 bit targets do not
suffer from "native complex" bugs anymore in current snapshots.

To check this, I ran LAPACK's testsuite to completion on my Pentium II
based laptop, using:

[toon@moene LAPACK]$ /usr/snp/bin/gcc -v
Reading specs from
/usr/snp/lib/gcc-lib/i686-pc-linux-gnu/egcs-2.93.03/specs
gcc version egcs-2.93.03 19990125 (gcc2 ss-980609 experimental)

with the following options:

OPTS     = -g -O3 -funroll-loops -fomit-frame-pointer
-fno-emulate-complex -malign-double

without any problem.

Eliminating the -fno-emulate-complex option, I ran into the same problem
as Josip Loncaric, namely that xlintstc (test driver for the single
precision complex LINear algebra routines) crashed.  Because about one
eighth of the complete LAPACK distribution is linked in with this
program, there's little use posting the constituent parts here ;-)

People who'd like to investigate this have to download the LAPACK
distribution themselves (which, BTW, is a very good test tool for a
Fortran compiler by itself).

One note of caution, though:  Although the distribution itself is only
about 4.5 Mb gzip'd, after unpacking and building you need about 120 Mb.

Cheers,

-- 
Toon Moene (toon@moene.indiv.nluug.nl)
Saturnushof 14, 3738 XG  Maartensdijk, The Netherlands
Phone: +31 346 214290; Fax: +31 346 214286
g77 Support: fortran@gnu.org; egcs: egcs-bugs@cygnus.com

performance of complex arithmetic

[Peter Bienstman]

Hello,

I have a question regarding EGCS's performance on complex arithmetic.

A first point regards the following switch for g77:

'-fno-emulate-complex'
     Implement `COMPLEX' arithmetic using the facilities in the `gcc'
     back end that provide direct support of `complex' arithmetic,
     instead of emulating the arithmetic.

     `gcc' has some known problems in its back-end support for
     `complex' arithmetic, due primarily to the support not being
     completed as of version 2.7.2.2.  Other front ends for the `gcc'
     back end avoid this problem by emulating `complex' arithmetic at a
     higher level, so the back end sees arithmetic on the real and
     imaginary components.

Is it true that the g++ ang g77 frontends still emulate complex arithmetic?
This would seem like a significant performance penalty, as the optimiser
would probably miss out on some optimisations.

Secondly, I was wondering if g++ is able to eliminate complex temporaries
the same way it is able to eliminate e.g. real or integer temporaries. A
while ago, this was a point of concern on the Blitz mailing list.

Is any work being done on the improvement of complex arithmetic? The code
I'm writing relies heavily on complex numbers, so it would be really bad
news if an otherwise great compiler wouldn't perform well in this area.

Greetings,

-------------------------------------
Peter Bienstman
Department of Information Technology
INTEC/IMEC - University of Gent
St.-Pietersnieuwstraat 41
B-9000 Gent - Belgium
E-mail: Peter.Bienstman@rug.ac.be
Tel: +32 9 264 3445
Fax: +32 9 264 3593
-------------------------------------