* RE: performance of complex arithmetic
@ 1999-01-27 14:00 Billinghurst, David (RTD)
1999-01-31 23:58 ` Billinghurst, David (RTD)
0 siblings, 1 reply; 20+ messages in thread
From: Billinghurst, David (RTD) @ 1999-01-27 14:00 UTC (permalink / raw)
To: 'Toon Moene', Peter.Bienstman; +Cc: egcs
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
^ permalink raw reply [flat|nested] 20+ messages in thread
* RE: performance of complex arithmetic
1999-01-27 14:00 performance of complex arithmetic Billinghurst, David (RTD)
@ 1999-01-31 23:58 ` Billinghurst, David (RTD)
0 siblings, 0 replies; 20+ messages in thread
From: Billinghurst, David (RTD) @ 1999-01-31 23:58 UTC (permalink / raw)
To: 'Toon Moene', Peter.Bienstman; +Cc: egcs
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
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: performance of complex arithmetic
@ 1999-01-26 19:24 Stephen L Moshier
1999-01-27 0:33 ` Michael Hayes
` (2 more replies)
0 siblings, 3 replies; 20+ messages in thread
From: Stephen L Moshier @ 1999-01-26 19:24 UTC (permalink / raw)
To: Peter Bienstman, egcs
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.
^ permalink raw reply [flat|nested] 20+ messages in thread* Re: performance of complex arithmetic
1999-01-26 19:24 Stephen L Moshier
@ 1999-01-27 0:33 ` Michael Hayes
1999-01-31 23:58 ` Michael Hayes
1999-01-27 1:37 ` Peter Bienstman
1999-01-31 23:58 ` Stephen L Moshier
2 siblings, 1 reply; 20+ messages in thread
From: Michael Hayes @ 1999-01-27 0:33 UTC (permalink / raw)
To: Re:moshier; +Cc: Peter Bienstman, egcs
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.
^ permalink raw reply [flat|nested] 20+ messages in thread* Re: performance of complex arithmetic
1999-01-27 0:33 ` Michael Hayes
@ 1999-01-31 23:58 ` Michael Hayes
0 siblings, 0 replies; 20+ messages in thread
From: Michael Hayes @ 1999-01-31 23:58 UTC (permalink / raw)
To: Re:moshier; +Cc: Peter Bienstman, egcs
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.
^ permalink raw reply [flat|nested] 20+ messages in thread
* RE: performance of complex arithmetic
1999-01-26 19:24 Stephen L Moshier
1999-01-27 0:33 ` Michael Hayes
@ 1999-01-27 1:37 ` Peter Bienstman
1999-01-27 9:25 ` Stephen L Moshier
` (2 more replies)
1999-01-31 23:58 ` Stephen L Moshier
2 siblings, 3 replies; 20+ messages in thread
From: Peter Bienstman @ 1999-01-27 1:37 UTC (permalink / raw)
To: moshier; +Cc: egcs
>> `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
-------------------------------------
^ permalink raw reply [flat|nested] 20+ messages in thread* RE: performance of complex arithmetic
1999-01-27 1:37 ` Peter Bienstman
@ 1999-01-27 9:25 ` Stephen L Moshier
1999-01-27 9:55 ` Joe Buck
1999-01-31 23:58 ` Stephen L Moshier
1999-01-27 13:24 ` craig
1999-01-31 23:58 ` Peter Bienstman
2 siblings, 2 replies; 20+ messages in thread
From: Stephen L Moshier @ 1999-01-27 9:25 UTC (permalink / raw)
To: Peter Bienstman; +Cc: egcs
> 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);
}
^ permalink raw reply [flat|nested] 20+ messages in thread* RE: performance of complex arithmetic
1999-01-27 9:25 ` Stephen L Moshier
@ 1999-01-27 9:55 ` Joe Buck
1999-01-31 23:58 ` Joe Buck
1999-01-31 23:58 ` Stephen L Moshier
1 sibling, 1 reply; 20+ messages in thread
From: Joe Buck @ 1999-01-27 9:55 UTC (permalink / raw)
To: moshier; +Cc: Peter.Bienstman, egcs
> 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).
^ permalink raw reply [flat|nested] 20+ messages in thread
* RE: performance of complex arithmetic
1999-01-27 9:55 ` Joe Buck
@ 1999-01-31 23:58 ` Joe Buck
0 siblings, 0 replies; 20+ messages in thread
From: Joe Buck @ 1999-01-31 23:58 UTC (permalink / raw)
To: moshier; +Cc: Peter.Bienstman, egcs
> 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).
^ permalink raw reply [flat|nested] 20+ messages in thread
* RE: performance of complex arithmetic
1999-01-27 9:25 ` Stephen L Moshier
1999-01-27 9:55 ` Joe Buck
@ 1999-01-31 23:58 ` Stephen L Moshier
1 sibling, 0 replies; 20+ messages in thread
From: Stephen L Moshier @ 1999-01-31 23:58 UTC (permalink / raw)
To: Peter Bienstman; +Cc: egcs
> 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);
}
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: performance of complex arithmetic
1999-01-27 1:37 ` Peter Bienstman
1999-01-27 9:25 ` Stephen L Moshier
@ 1999-01-27 13:24 ` craig
1999-01-27 13:45 ` Stephen L Moshier
1999-01-31 23:58 ` craig
1999-01-31 23:58 ` Peter Bienstman
2 siblings, 2 replies; 20+ messages in thread
From: craig @ 1999-01-27 13:24 UTC (permalink / raw)
To: Peter.Bienstman; +Cc: 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)
^ permalink raw reply [flat|nested] 20+ messages in thread* Re: performance of complex arithmetic
1999-01-27 13:24 ` craig
@ 1999-01-27 13:45 ` Stephen L Moshier
1999-01-31 23:58 ` Stephen L Moshier
1999-01-31 23:58 ` craig
1 sibling, 1 reply; 20+ messages in thread
From: Stephen L Moshier @ 1999-01-27 13:45 UTC (permalink / raw)
To: craig; +Cc: Peter.Bienstman, egcs
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.
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: performance of complex arithmetic
1999-01-27 13:45 ` Stephen L Moshier
@ 1999-01-31 23:58 ` Stephen L Moshier
0 siblings, 0 replies; 20+ messages in thread
From: Stephen L Moshier @ 1999-01-31 23:58 UTC (permalink / raw)
To: craig; +Cc: Peter.Bienstman, egcs
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.
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: performance of complex arithmetic
1999-01-27 13:24 ` craig
1999-01-27 13:45 ` Stephen L Moshier
@ 1999-01-31 23:58 ` craig
1 sibling, 0 replies; 20+ messages in thread
From: craig @ 1999-01-31 23:58 UTC (permalink / raw)
To: Peter.Bienstman; +Cc: 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)
^ permalink raw reply [flat|nested] 20+ messages in thread
* RE: performance of complex arithmetic
1999-01-27 1:37 ` Peter Bienstman
1999-01-27 9:25 ` Stephen L Moshier
1999-01-27 13:24 ` craig
@ 1999-01-31 23:58 ` Peter Bienstman
2 siblings, 0 replies; 20+ messages in thread
From: Peter Bienstman @ 1999-01-31 23:58 UTC (permalink / raw)
To: moshier; +Cc: egcs
>> `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
-------------------------------------
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: performance of complex arithmetic
1999-01-26 19:24 Stephen L Moshier
1999-01-27 0:33 ` Michael Hayes
1999-01-27 1:37 ` Peter Bienstman
@ 1999-01-31 23:58 ` Stephen L Moshier
2 siblings, 0 replies; 20+ messages in thread
From: Stephen L Moshier @ 1999-01-31 23:58 UTC (permalink / raw)
To: Peter Bienstman, egcs
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.
^ permalink raw reply [flat|nested] 20+ messages in thread
* performance of complex arithmetic
@ 1999-01-26 1:08 Peter Bienstman
1999-01-27 6:28 ` Toon Moene
1999-01-31 23:58 ` Peter Bienstman
0 siblings, 2 replies; 20+ messages in thread
From: Peter Bienstman @ 1999-01-26 1:08 UTC (permalink / raw)
To: egcs
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
-------------------------------------
^ permalink raw reply [flat|nested] 20+ messages in thread* Re: performance of complex arithmetic
1999-01-26 1:08 Peter Bienstman
@ 1999-01-27 6:28 ` Toon Moene
1999-01-31 23:58 ` Toon Moene
1999-01-31 23:58 ` Peter Bienstman
1 sibling, 1 reply; 20+ messages in thread
From: Toon Moene @ 1999-01-27 6:28 UTC (permalink / raw)
To: Peter.Bienstman; +Cc: egcs
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
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: performance of complex arithmetic
1999-01-27 6:28 ` Toon Moene
@ 1999-01-31 23:58 ` Toon Moene
0 siblings, 0 replies; 20+ messages in thread
From: Toon Moene @ 1999-01-31 23:58 UTC (permalink / raw)
To: Peter.Bienstman; +Cc: egcs
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
^ permalink raw reply [flat|nested] 20+ messages in thread
* performance of complex arithmetic
1999-01-26 1:08 Peter Bienstman
1999-01-27 6:28 ` Toon Moene
@ 1999-01-31 23:58 ` Peter Bienstman
1 sibling, 0 replies; 20+ messages in thread
From: Peter Bienstman @ 1999-01-31 23:58 UTC (permalink / raw)
To: egcs
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
-------------------------------------
^ permalink raw reply [flat|nested] 20+ messages in thread
end of thread, other threads:[~1999-01-31 23:58 UTC | newest]
Thread overview: 20+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
1999-01-27 14:00 performance of complex arithmetic Billinghurst, David (RTD)
1999-01-31 23:58 ` Billinghurst, David (RTD)
-- strict thread matches above, loose matches on Subject: below --
1999-01-26 19:24 Stephen L Moshier
1999-01-27 0:33 ` Michael Hayes
1999-01-31 23:58 ` Michael Hayes
1999-01-27 1:37 ` Peter Bienstman
1999-01-27 9:25 ` Stephen L Moshier
1999-01-27 9:55 ` Joe Buck
1999-01-31 23:58 ` Joe Buck
1999-01-31 23:58 ` Stephen L Moshier
1999-01-27 13:24 ` craig
1999-01-27 13:45 ` Stephen L Moshier
1999-01-31 23:58 ` Stephen L Moshier
1999-01-31 23:58 ` craig
1999-01-31 23:58 ` Peter Bienstman
1999-01-31 23:58 ` Stephen L Moshier
1999-01-26 1:08 Peter Bienstman
1999-01-27 6:28 ` Toon Moene
1999-01-31 23:58 ` Toon Moene
1999-01-31 23:58 ` Peter Bienstman
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).