* Re: Estimated SPEC2000 results for gcc+alpha
@ 2000-01-31 0:39 Toon Moene
0 siblings, 0 replies; 7+ messages in thread
From: Toon Moene @ 2000-01-31 0:39 UTC (permalink / raw)
To: gcc
Brad Lucier wrote:
> mgrid and apsi are embarrassingly (sp?) bad and swim is not so great
> either.
I've seen the loop that comprises 2/3rds of the run time of mgrid in the
old SPECfp95 test. It doesn't contain any other floating point
operations than add/sub/mul/div, so it's not surprising that adding
-lcpml doesn't help.
apsi is a weather model (actually a dispersion model derived from a
weather model), so - based on my experience as a meteorologist - I
expect it to be dominated by add/sub/mul/div too.
> Perhaps things would be better if I added -funroll-loops.
Anton Ertl recently posted (comp.arch) results of SPEC95 on Alpha with
and without -funroll-loops - it didn't make a dent; probably because all
the relevant loops are too large to be unrolled by GCC.
Hope this helps,
--
Toon Moene, KNMI, PO Box 201, 3730 AE De Bilt, The Netherlands.
Tel. +31302206443, Fax +31302210407, e-mail moene@knmi.nl
URL: http://www.knmi.nl/hirlam
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Estimated SPEC2000 results for gcc+alpha
2000-01-28 18:01 ` Richard Henderson
@ 2000-01-29 10:19 ` Brad Lucier
0 siblings, 0 replies; 7+ messages in thread
From: Brad Lucier @ 2000-01-29 10:19 UTC (permalink / raw)
To: Richard Henderson; +Cc: Brad Lucier, gcc, hosking
>
> You could hack gcc/f/g77spec.c and make sure -lcpml shows up before -lm...
>
> r~
It is not as easy as it seemed. I tried setting MATH_LIBRARY to "-lcpml -lm"
in gcc/f/g77spec.c and got the message:
popov-45% g77 -O3 -o testlm testlm.f
/export/u10/binutils-2.9.5.0.16/bin/ld: cannot find -lcpml -lm
collect2: ld returned 1 exit status
I then defined it in alpha.h and got the same message. The comments in
gcc/f/g77spec.c indicate that nothing should come between -lg2c and -lm.
So I figured out how to make libm.so a script to first include libcpml
and then libm, and this works for some small benchmarks I've tried (speeds
things up by a factor of 5-6), but it doesn't make any difference at all
to the CFP2000 benchmarks.
I find it hard to believe that the SPECFP2000 benchmark results compiled with
g77 are as bad as as I reported before in
http://gcc.gnu.org/ml/gcc/2000-01/msg00863.html
sixtrack is simply horrendous; I speculated that it was because I was
using slow math libraries, but I can't seem to get it to go any faster
with libcpml, and I'm finding it hard to figure out if I'm really using
cpml (although ldd reports cpml before lm). mgrid and apsi are
embarrassingly (sp?) bad and swim is not so great either.
Perhaps things would be better if I added -funroll-loops.
To make things more difficult, the g77 sources are getting increasingly
brittle; they won't build now with make -j on alpha linux (it bombs because
some files in gcc/f/ include the system system.h because the fixinclude'd
system.h is not ready yet) and is an increasing time sink for me.
For my codes I'm worried about gcc and g++ performance, and I'll continue
to concentrate on those compilers.
Brad
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Estimated SPEC2000 results for gcc+alpha
2000-01-28 7:26 Brad Lucier
@ 2000-01-28 18:01 ` Richard Henderson
2000-01-29 10:19 ` Brad Lucier
0 siblings, 1 reply; 7+ messages in thread
From: Richard Henderson @ 2000-01-28 18:01 UTC (permalink / raw)
To: Brad Lucier; +Cc: gcc, hosking
On Fri, Jan 28, 2000 at 10:26:25AM -0500, Brad Lucier wrote:
> I don't know how to set up libm so that libcpml is
> automatically searched first for unresolved math references; if someone
> can tell me, I'll run the benchmark suite over again.
You could hack gcc/f/g77spec.c and make sure -lcpml shows up before -lm...
r~
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Estimated SPEC2000 results for gcc+alpha
@ 2000-01-28 7:26 Brad Lucier
2000-01-28 18:01 ` Richard Henderson
0 siblings, 1 reply; 7+ messages in thread
From: Brad Lucier @ 2000-01-28 7:26 UTC (permalink / raw)
To: gcc; +Cc: lucier, hosking
Here are revised SPEC2000 extimated results; the new FP results are at
the bottom.
With gcc version 2.96 20000121 (experimental), options -mcpu=ev6 -O3
-ffast-math, MATHLIBOPT = -lcpml -lm:
SPEC CINT2000 Summary
-- --
Wed Jan 26 16:46:22 2000
SPEC License #0 Test date: -- Hardware availability: --
Tester: -- Software availability: --
Estimated Estimated
Base Base Base Peak Peak Peak
Benchmarks Ref Time Run Time Ratio Ref Time Run Time Ratio
------------ -------- -------- -------- -------- -------- --------
164.gzip 1400 741 189*
175.vpr 1400 726 193*
176.gcc 1100 412 267*
181.mcf 1800 981 184*
186.crafty X
197.parser 1800 1201 150*
252.eon X
253.perlbmk 1800 800 225*
254.gap 1100 480 229*
255.vortex 1900 966 197*
256.bzip2 1500 640 234*
300.twolf X
Est. SPECint_base2000 205
Est. SPECint2000 --
With gcc version 2.96 20000127 (experimental), options -mcpu=ev6 -O3
-ffast-math, MATHLIBOPT = -lcpml -lm:
SPEC CFP2000 Summary
-- --
Thu Jan 27 21:56:37 2000
SPEC License #0 Test date: -- Hardware availability: --
Tester: -- Software availability: --
Estimated Estimated
Base Base Base Peak Peak Peak
Benchmarks Ref Time Run Time Ratio Ref Time Run Time Ratio
------------ -------- -------- -------- -------- -------- --------
168.wupwise 1600 583 275 *
171.swim 3100 1797 173 *
172.mgrid 1800 1306 138 *
173.applu 2100 935 224 *
177.mesa 1400 369 379 *
178.galgel X
179.art 2600 654 398 *
183.equake 1300 599 217 *
187.facerec X
188.ammp 2200 858 256 *
189.lucas X
191.fma3d X
200.sixtrack 1100 1789 61.5 *
301.apsi 2600 1640 159 *
Est. SPECfp_base2000 --
Est. SPECfp2000 --
The four failures are written in Fortran 90, so gcc/g77 has no failures
in the CFP suite.
I believe the truly lousy result for 200.sixtrack is because libm.so
got linked in rather than libcpml.so, and that benchmark uses a lot of
elementary functions. I don't know how to set up libm so that libcpml is
automatically searched first for unresolved math references; if someone
can tell me, I'll run the benchmark suite over again.
Brad
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Estimated SPEC2000 results for gcc+alpha
@ 2000-01-27 18:49 Brad Lucier
0 siblings, 0 replies; 7+ messages in thread
From: Brad Lucier @ 2000-01-27 18:49 UTC (permalink / raw)
To: lucier, rth; +Cc: gcc, hosking
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 6553 bytes --]
> From rth@cygnus.com Thu Jan 27 15:06:47 2000
> On Thu, Jan 27, 2000 at 11:24:41AM -0500, Brad Lucier wrote:
> > 171.swim X
> > 172.mgrid X
> > 173.applu X
> > 301.apsi X
>
> Wow I'm surprised all of these failed. Or did they update them for f90?
I screwed up the config file. I'll run the tests again tonight with
the current mainline source; I anticipate that there will be many fewer
failures.
>
> > 176.gcc X
>
> Is this a compilation failure?
No, it was a runtime failure with gcc-2.95.2; this was not an issue
with the development branch. Here's the bug report I sent to SPEC.
(I get the same error after removing all the ifdef __GNUC__ as you
suggested in your other post.) I now believe that it is a problem with
gcc-2.95.2.
Brad
When I compile 176.gcc with gcc-2.95.2 on Red Hat Linux 6.0 with kernel
2.2.13 on a Compaq DS20 alpha 21264 clone, with the following options:
OPTIMIZE = -mcpu=ev6 -O2 -g -Wall
I get a segfault in flow.c at the bzero at the last line below (line 935):
static void
life_analysis (f, nregs)
rtx f;
int nregs;
{
register regset tem;
int first_pass;
int changed;
/* For each basic block, a bitmask of regs
live on exit from the block. */
regset *basic_block_live_at_end;
/* For each basic block, a bitmask of regs
live on entry to a successor-block of this block.
If this does not match basic_block_live_at_end,
that must be updated, and the block must be rescanned. */
regset *basic_block_new_live_at_end;
/* For each basic block, a bitmask of regs
whose liveness at the end of the basic block
can make a difference in which regs are live on entry to the block.
These are the regs that are set within the basic block,
possibly excluding those that are used after they are set. */
regset *basic_block_significant;
register int i;
rtx insn;
struct obstack flow_obstack;
gcc_obstack_init (&flow_obstack);
max_regno = nregs;
bzero (regs_ever_live, sizeof regs_ever_live);
/* Allocate and zero out many data structures
that will record the data from lifetime analysis. */
allocate_for_life_analysis ();
reg_next_use = (rtx *) alloca (nregs * sizeof (rtx));
bzero ((char *) reg_next_use, nregs * sizeof (rtx));
/* Set up several regset-vectors used internally within this function.
Their meanings are documented above, with their declarations. */
basic_block_live_at_end
= (regset *) alloca (n_basic_blocks * sizeof (regset));
/* Don't use alloca since that leads to a crash rather than an error message
if there isn't enough space.
Don't use oballoc since we may need to allocate other things during
this function on the temporary obstack. */
tem = (regset) obstack_alloc (&flow_obstack, n_basic_blocks * regset_bytes);
bzero ((char *) tem, n_basic_blocks * regset_bytes);
Here is the output of xxgdb:
(xxgdb) run /export/u11/lucier/programs/SPEC2000/benchspec/CINT2000/176.gcc/run/00000003/166.i
__sigismember __sigaddset __sigdelset mem_access_latency dl1_access_fn dl2_access_fn il1_access_fn il2_access_fn itlb_access_fn dtlb_access_fn sim_reg_options
Program received signal SIGSEGV, Segmentation fault.
memset_loop () at ../sysdeps/alpha/memset.S:62
../sysdeps/alpha/memset.S:62: No such file or directory.
Current language: auto; currently asm
(xxgdb) up
#1 0x1200e18c4 in life_analysis (f=0x1204dab98, nregs=347) at flow.c:935
Current language: auto; currently c
(xxgdb) info locals
tem = 0x20511b00
first_pass = 539669120
changed = 0
basic_block_live_at_end = (regset *) 0x11fffcef8
basic_block_new_live_at_end = (regset *) 0x11fffcef0
basic_block_significant = (regset *) 0x1202ac5b0
i = 539673992
insn = 0x2c
flow_obstack = {
chunk_size = 4072,
chunk = 0x120511ac0,
object_base = 0x20511b30 <Address 0x20511b30 out of bounds>,
next_free = 0x20511b30 <Address 0x20511b30 out of bounds>,
chunk_limit = 0x120512aa8 "ñ\017",
temp = 0,
alignment_mask = -4294967289,
chunkfun = 0x12002a800 <xmalloc>,
freefun = 0x20000449b80 <__libc_free>,
extra_arg = 0xffffffffffffffff <Address 0xffffffffffffffff out of bounds>,
use_extra_arg = -8,
maybe_empty_object = -8,
alloc_failed = -8
}
(xxgdb) info args
f = 0x1204dab98
nregs = 347
So, at this point tem is invalid pointer, and flow_obstack.alloc_failed is
nonzero, so it indicates the allocation failed. This does not happen with
-O1 or -O0.
Many, many warnings are reported with the -Wall. In particular, here
are the more worrying warnings from flow.c:
flow.c: In function `flow_analysis':
flow.c:383: warning: type mismatch in implicit declaration for built-in function `memset'
flow.c: In function `find_basic_blocks':
flow.c:714: warning: implicit declaration of function `simplejump_p'
flow.c: In function `life_analysis':
flow.c:903: warning: implicit declaration of function `gcc_obstack_init'
flow.c:998: warning: implicit declaration of function `volatile_refs_p'
flow.c:1149: warning: type mismatch in implicit declaration for built-in function `memcpy'
flow.c: In function `propagate_block':
flow.c:1376: warning: `regs_sometimes_live' might be used uninitialized in this function
flow.c:1380: warning: `maxlive' might be used uninitialized in this function
flow.c: In function `insn_dead_p':
flow.c:1727: warning: implicit declaration of function `rtx_equal_p'
flow.c: In function `mark_set_1':
flow.c:1966: warning: implicit declaration of function `reg_overlap_mentioned_p'
flow.c:1969: warning: implicit declaration of function `side_effects_p'
flow.c:1973: warning: implicit declaration of function `reg_mentioned_p'
flow.c: In function `mark_used_regs':
flow.c:2511: warning: implicit declaration of function `dead_or_set_p'
flow.c:2524: warning: implicit declaration of function `dead_or_set_regno_p'
So with implicit declarations of important obstack routines, and type
mismatches in built-in functions, I'm having a hard time trying to figure
out where the problem is. I.e., is it in the code or in the compiler?
Has anything like this been reported before? Do you have any suggestions
about how I might proceed? (I sure don't want to compile everything with
-O1 to get around this problem.)
Brad Lucier lucier@math.purdue.edu
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Estimated SPEC2000 results for gcc+alpha
2000-01-27 8:24 Brad Lucier
@ 2000-01-27 12:06 ` Richard Henderson
0 siblings, 0 replies; 7+ messages in thread
From: Richard Henderson @ 2000-01-27 12:06 UTC (permalink / raw)
To: Brad Lucier; +Cc: gcc, hosking
On Thu, Jan 27, 2000 at 11:24:41AM -0500, Brad Lucier wrote:
> I do have some partial results, though. If people think that it will
> help the development of the gcc toolset, then I'll continue.
Fixing the bugs that were exposed would help everyone. Tuning
would of course also help, but it seems rare to find the time.
> 171.swim X
> 172.mgrid X
> 173.applu X
> 301.apsi X
Wow I'm surprised all of these failed. Or did they update them for f90?
> 176.gcc X
Is this a compilation failure? Spec95 shipped with code that simply
would not compile with gcc due to ifdef __GNUC__ code referring to
stuff they'd removed.
r~
^ permalink raw reply [flat|nested] 7+ messages in thread
* Estimated SPEC2000 results for gcc+alpha
@ 2000-01-27 8:24 Brad Lucier
2000-01-27 12:06 ` Richard Henderson
0 siblings, 1 reply; 7+ messages in thread
From: Brad Lucier @ 2000-01-27 8:24 UTC (permalink / raw)
To: gcc; +Cc: lucier, hosking
I thought I'd get a copy of the SPEC2000 benchmark (Purdue is a member
of SPEC) and compare gcc-2.95.2 with the current mainline, -mieee vs no
-mieee, Compaq ccc and fort vs gcc and g77, etc. God, was I naive.
I do have some partial results, though. If people think that it will
help the development of the gcc toolset, then I'll continue. I'll also
accept suggestions and offers of help. Otherwise, I anticipate it will
just be too much work.
The word "estimated" is used in the subject line because I don't have
a complete set of results for either CFP (don't have an f90 compiler)
or CINT. An entry that is blank or filled with an X means that it didn't
compile, or it crashed when run, or the results don't agree with the
expected results, etc.
Machine: dual 500 MHz 21264, 2 GB memory, one 9 GB disk, Compaq DS20
clone. Software: Red Hat 6.0, kernel 2.2.13
With gcc-2.95.2, options -mcpu=ev6 -O4 -ffast-math -funroll-loops for
gcc, g++, and g77, MATHLIBOPT = -lcpml -lm
SPEC CFP2000 Summary
-- --
Tue Jan 25 22:50:46 2000
SPEC License #0 Test date: -- Hardware availability: --
Tester: -- Software availability: --
Estimated Estimated
Base Base Base Peak Peak Peak
Benchmarks Ref Time Run Time Ratio Ref Time Run Time Ratio
168.wupwise X
171.swim X
172.mgrid X
173.applu X
177.mesa 1400 369 379 *
178.galgel X
179.art 2600 657 396 *
183.equake 1300 635 205 *
187.facerec X
188.ammp 2200 835 264 *
189.lucas X
191.fma3d X
200.sixtrack X
301.apsi X
SPEC CINT2000 Summary
-- --
Tue Jan 25 22:50:46 2000
SPEC License #0 Test date: -- Hardware availability: --
Tester: -- Software availability: --
Estimated Estimated
Base Base Base Peak Peak Peak
Benchmarks Ref Time Run Time Ratio Ref Time Run Time Ratio
164.gzip 1400 766 183*
175.vpr 1400 751 186*
176.gcc X
181.mcf 1800 978 184*
186.crafty 1000 317 316*
197.parser 1800 1231 146*
252.eon 1300 473 275*
253.perlbmk 1800 890 202*
254.gap 1100 492 224*
255.vortex 1900 1001 190*
256.bzip2 1500 676 222*
300.twolf X
Est. SPECint_base2000 208
Est. SPECint2000 --
With gcc version 2.96 20000121 (experimental), options -mcpu=ev6 -O3
-ffast-math, MATHLIBOPT = -lcpml -lm:
SPEC CFP2000 Summary
-- --
Wed Jan 26 16:46:22 2000
SPEC License #0 Test date: -- Hardware availability: --
Tester: -- Software availability: --
Estimated Estimated
Base Base Base Peak Peak Peak
Benchmarks Ref Time Run Time Ratio Ref Time Run Time Ratio
------------ -------- -------- -------- -------- -------- --------
168.wupwise X
171.swim X
172.mgrid X
173.applu X
177.mesa 1400 378 370 *
178.galgel X
179.art 2600 680 382 *
183.equake 1300 596 218 *
187.facerec X
188.ammp 2200 868 253 *
189.lucas X
191.fma3d X
200.sixtrack X
301.apsi X
Est. SPECfp_base2000 --
Est. SPECfp2000 --
SPEC CINT2000 Summary
-- --
Wed Jan 26 16:46:22 2000
SPEC License #0 Test date: -- Hardware availability: --
Tester: -- Software availability: --
Estimated Estimated
Base Base Base Peak Peak Peak
Benchmarks Ref Time Run Time Ratio Ref Time Run Time Ratio
------------ -------- -------- -------- -------- -------- --------
164.gzip 1400 741 189*
175.vpr 1400 726 193*
176.gcc 1100 412 267*
181.mcf 1800 981 184*
186.crafty X
197.parser 1800 1201 150*
252.eon X
253.perlbmk 1800 800 225*
254.gap 1100 480 229*
255.vortex 1900 966 197*
256.bzip2 1500 640 234*
300.twolf X
Est. SPECint_base2000 205
Est. SPECint2000 --
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2000-01-31 0:39 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2000-01-31 0:39 Estimated SPEC2000 results for gcc+alpha Toon Moene
-- strict thread matches above, loose matches on Subject: below --
2000-01-28 7:26 Brad Lucier
2000-01-28 18:01 ` Richard Henderson
2000-01-29 10:19 ` Brad Lucier
2000-01-27 18:49 Brad Lucier
2000-01-27 8:24 Brad Lucier
2000-01-27 12:06 ` Richard Henderson
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).