f/runtime configure for x-builds?

f/runtime configure for x-builds?

[Mumit Khan]

currently the configuration for f/runtime is botched for x-builds, since
the configuration scripts uses host CC to do its job; eg., if your host
is i386-linux-gnulibc1 and target is i386-cygwin32, and you check for 
__CYGWIN32__, it won't find it since host cc is probably not the same as 
target and hence wouldn't define it.

For i386-cygwin32-g77, I did this by a horrible hack by forcing CC to be
GCC_FOR_TARGET, and even then it didn't work right. What's the right way
to do this?

Mumit

Re: mdbench for g77 & f2c+gcc

[Jeffrey A Law]

  In message <199708210611.CAA05848@jenolan.rutgers.edu>you write:
  > I'm willing to bet that Ultra-3 will be 8 issue, and that should be
  > showing up within the next year (you'll have to second mortgage your
  > house to buy one initially though ;-) So these sort of strategies will
  > be even more important as 8 issue RISC pipes start showing up.
Another alternative is for Ultra-3 to switch gears and move to
an out of order execution model like PA8000.  Which takes much of
the emphasis off the compiler for scheduling.  (I really don't know
what the Ultra-3 is doing, just pointing out that some newer machines
don't need traditional latency scheduling -- in fact on the PA8000
traditional latency scheduling hurts performance).


  > I think Haifa will steer the way so that GCC can begin to cope with
  > this sort of stuff.
That's the hope.

jeff

Re: gcc installation

[Thomas Weise]

I've installed it on another machine now, and the problem with specs has
been going away. However, g++ hsn't been installed again. It also
wasn't built in the make directory. But explicitly typing 'make g++'
goes well ... When I've installed Cygnus's latest release from April this
wouldn't happen. So I don't know whats wrong there.

Thomas Weise, http://www.inf.tu-dresden.de/~tw4
Dresden University of Technology, Department of Computer Science  

On Tue, 19 Aug 1997, Jeffrey A Law wrote:

>   In message <Pine.ULT.3.95.970819173626.27159C-100000@irz301.inf.tu-dresden.de
> >you write:
>   > is not a bug report for gcc itself. But can someone please tell me,
>   > why (1) there will  be no configuration spec installed (on Linux
>   > /usr/lib/gcc-lib/i586-pc-linux-gnulibc1/egcs-2.90.00/specs) and whether
> Weird.  It's installed on other platforms.  I'm not aware of any
> linux specific code which would cause specs not to get installed.
> 
>   > (2) g++ seems to be no longer supported (I know that it just calls gcc,
>   > however I've installed both languages, c AND c++).
> Similarly.
> 
> Where there any errors during the "make install"?  Did g++ and
> the specs file get built in the object directory?
> 
> 
> jeff
> 

Re: mdbench for g77 & f2c+gcc

[Oleg Krivosheev]

Hi,

On Thu, 21 Aug 1997, Dave Love wrote:

> Date: Thu, 21 Aug 1997 19:32:49 +0100
> From: Dave Love <d.love@dl.ac.uk>
> To: egcs@cygnus.COM
> Subject: Re: mdbench for g77 & f2c+gcc
> 
> On x86 -fforce-addr often has a significant effect on fortran in
> either direction, doubtless differently in different parts of the
> code.

i'll check...

> f2c-compiled code is normally significantly better with gcc if you use
> `-a' (basically equivalent to g77's default -fautomatic), as is always
> appropriate for standard-conforming code.  Failure to use -a has given
> f2c and C-as-UNCOL a worse press than warranted.

oops! my bug...

just tried f2c -a & egcs gcc. Time is down from ~25 sec
to 18.94 sec. Still ~15% worse that g77.

> Beware that old Fortran benchmarks often have coding problems which
> g77 will show up, either through straight standard-non-conformance or
> portability problems such as not declaring EXTERNALs; mdbnch did the
> latter IIRC, though it just elicits a warning from g77.

hmm...
it's quite clean now - g77/f2c/ftncheck emits just
few warning about declared but unused variables.

> [One important x86-performance-related thing that backend experts
> might like to look at sometime is why the backend allegedly doesn't
> (or didn't early this year) generate optimal 586 code for the level-1
> BLAS (O(n) floating point linear algebra), which people have been
> feeling the need to code in assembler.  I can provide references for
> that at some stage if anyone is interested.]

please, send it to me in private mail

> Gratifying interest in Fortran :-).

;)

OK

Re: mdbench for g77 & f2c+gcc

[Dave Love]

If mdbnch discussions are continuing, I might point out some things
about it and some possibly-mis-remembered facts I don't have time to
check on.  Toon might correct me.

The first thing is that in my experience a couple of years ago it
depends critically on the cache and should probably be run single-user
for compiler benchmarking, as opposed to real-life performance.  (I
think this is an intentional feature of mdbnch, but not necessarily
representative.)  On MIPS R4000s it made a significant difference when
gcc 2.7 introduced an r4000 configuration and g77 basically caught up
with MIPS f77 on mdbnch IIRC; they've probably both got better since.

It looks as though data in (static) COMMON are a bottleneck (if
-malign-double makes a consistent significant improvement) and that
may hurt optimization -- Craig or Toon can probably say better.
Automatic data in it will be subject to the non-double-alignment
problem on [56]86.

On x86 -fforce-addr often has a significant effect on fortran in
either direction, doubtless differently in different parts of the
code.

f2c-compiled code is normally significantly better with gcc if you use
`-a' (basically equivalent to g77's default -fautomatic), as is always
appropriate for standard-conforming code.  Failure to use -a has given
f2c and C-as-UNCOL a worse press than warranted.

Beware that old Fortran benchmarks often have coding problems which
g77 will show up, either through straight standard-non-conformance or
portability problems such as not declaring EXTERNALs; mdbnch did the
latter IIRC, though it just elicits a warning from g77.

[One important x86-performance-related thing that backend experts
might like to look at sometime is why the backend allegedly doesn't
(or didn't early this year) generate optimal 586 code for the level-1
BLAS (O(n) floating point linear algebra), which people have been
feeling the need to code in assembler.  I can provide references for
that at some stage if anyone is interested.]

Gratifying interest in Fortran :-).

Re: mdbench for g77 & f2c+gcc

[Furio Ercolessi]

> Hi, All

Hi (what a large party!)

> i've benchmarked g77 and f2c+gcc
> using mdbench on Ultrasparc II / 200Mhz
> and Pentium/133Mhz/256k cache.

Thanks for the data, I am putting then online right now

> g77 and gcc were build from egcs-ss-970814.tar.gz sources

Do you have the g77 and gcc release numbers at hand?

> g77 -O6 -funroll-all-loops -fomit-frame-pointer -ffast-math
> -fstrength-reduce -fthread-jumps -mcpu=ultrasparc -mtune=ultrasparc
> mdbnch.f
> 
> 17.56 sec
> 
> not bad, huh!!! official data are
> 
> Sun Ultra 2 (200Mhz), Solaris 2.5.1, SC4.0 FORTRAN [^] ........ 15.7 s+
> 24Apr96

Well, now your data are also official ...
However, I now discovered that I erroneously reported
Sun Ultra 2 (300MHz), Solaris 2.6, f77 SC4.2 [o] .............. 14.6 s+ 16Jul97
where the MHz where incorrectly typed, this was in fact
Sun Ultra 2 (200MHz), Solaris 2.6, f77 SC4.2 [o] .............. 14.6 s+ 16Jul97
which is therefore the best time for this machine.

> my own result with sun f77 4.2 is 16.5 sec

The above time was obtained using
-fast -xO5 -xtarget=native -xarch=v8plus -stackvar -xdepend

> 2. Intel P133/60ns EDO 32M/256K cache, Triton2 HX board 
>    with agressive BIOS settings, Debian/hamm Linux
>    with glibc 2

Also for this case I would appreciate knowing the release numbers
of g77 and gcc.

Thank you very much again

furio ercolessi
SISSA
Trieste, Italy

Re: mdbench for g77 & f2c+gcc

[Oleg Krivosheev]

Hi,

On Thu, 21 Aug 1997, Oleg Krivosheev wrote:

> Date: Thu, 21 Aug 1997 00:56:37 -0500 (CDT)
> From: Oleg Krivosheev <kriol@FNAL.GOV>
> To: Arno PAHLER <paehler@atlas.rc.m-kagaku.co.jp>,
>     Christian Kuehnke
     <Christian.Kuehnke@arbi.Informatik.UNI-OLDENBURG.DE>,
>     "H.J. Lu" <hjl@lucon.org>
> Cc: egcs@cygnus.COM, furio@sissa.IT
> Subject: mdbench for g77 & f2c+gcc
> 
> 
> Hi, All
> 
> i've benchmarked g77 and f2c+gcc
> using mdbench on Ultrasparc II / 200Mhz
> and Pentium/133Mhz/256k cache.
> 
> g77 and gcc were build from egcs-ss-970814.tar.gz sources
> with Haifa scheduler plus
> Bernd Schmidt haifa patch plus
> Christian ultra patch plus
> Jim Wilson patch.
> 
> All numbers are averaged over five runs.
> ultra and P133 both had zero load.
> 
> 1. Ultra II/200 mhz
> 
> jor-el ~/work/Project/tmp$ fpversion
>  A SPARC-based CPU is available.
>  CPU's clock rate appears to be approximately 200.2 MHz.
>  Kernel says CPU's clock rate is 200.0 MHz.
>  Kernel says main memory's clock rate is 100.0 MHz.
> 
>  Sun-4 floating-point controller version 0 found.
>  An UltraSPARC chip is available.
>  FPU's frequency appears to be approximately 201.5 MHz.
> 
>  Use "-xtarget=ultra -xcache=16/32/1:1024/64/1" code-generation option.
>  
> 
> g77 -O6 -funroll-all-loops -fomit-frame-pointer -ffast-math
> -fstrength-reduce -fthread-jumps -mcpu=ultrasparc -mtune=ultrasparc
> mdbnch.f
> 
> 17.56 sec
> 
> not bad, huh!!! official data are
> 
> Sun Ultra 2 (200Mhz), Solaris 2.5.1, SC4.0 FORTRAN [^] ........ 15.7 s+
> 24Apr96
> 
> my own result with sun f77 4.2 is 16.5 sec
> 
> g77 is only ~10% slower !

i just tried to compile without scheduler intervention:

g77 -O6 -fno-schedule-insns -fno-schedule-insns2 -funroll-all-loops
-fomit-frame-pointer -ffast-math -fstrength-reduce -fthread-jumps
-mcpu=ultrasparc -mtune=ultrasparc mdbnch.f 

21.04 sec

Haifa gives quite substantial contribution into performance !

OK

Re: mdbench for g77 & f2c+gcc

[David S. Miller]

   Date: Thu, 21 Aug 1997 00:56:37 -0500 (CDT)
   From: Oleg Krivosheev <kriol@fnal.gov>

   in both cases g77 is a bit faster. I don't know what is the cause
   of such big difference on Ultra

I can't overemphasize how critical it is to schedule code properly on
the Ultra to get decent performance.  The SunPRO people spent close to
2 years developing their code generation scheduler for the Ultra.  It
paid off, they saturate %100 of the Ultra's resources for %92 of the
code they sampled during development.  This means for %92 of the code:

1) All load uses were successfully pushed to 8 cycles after the load
2) All stores were seperated properly to prevent store buffer
   overflow (so that stores always could be sent quietly and thus
   the store buffer contents never exceeded 5 entries).
3) For FPU intensive code they get 4 issue a substantial amount of
   the time
4) For loops they unroll and align branch targets such that the ICACHE
   is perfectly used, no dead cache lines.

The key to their design aparently is that they model the Ultra
pipeline using a VLIW virtual machine in the code generator.  They
schedule as if you _must_ fill the cycles or put nops there if you
can't deal with the interlocks.  I don't think this was so much a
powerful infrastructure as much as it was a mental one for the
algorithms.  When you're coding for something which "must" fill the
cycles or put nops there, as opposed to "make things schedule
'better'", you tend to subconsciously place a different set of
heuristics in there.

I'm willing to bet that Ultra-3 will be 8 issue, and that should be
showing up within the next year (you'll have to second mortgage your
house to buy one initially though ;-) So these sort of strategies will
be even more important as 8 issue RISC pipes start showing up.

I think Haifa will steer the way so that GCC can begin to cope with
this sort of stuff.

Later,
David "Sparc" Miller
davem@caip.rutgers.edu

mdbench for g77 & f2c+gcc

[Oleg Krivosheev]

Hi, All

i've benchmarked g77 and f2c+gcc
using mdbench on Ultrasparc II / 200Mhz
and Pentium/133Mhz/256k cache.

g77 and gcc were build from egcs-ss-970814.tar.gz sources
with Haifa scheduler plus
Bernd Schmidt haifa patch plus
Christian ultra patch plus
Jim Wilson patch.

All numbers are averaged over five runs.
ultra and P133 both had zero load.

1. Ultra II/200 mhz

jor-el ~/work/Project/tmp$ fpversion
 A SPARC-based CPU is available.
 CPU's clock rate appears to be approximately 200.2 MHz.
 Kernel says CPU's clock rate is 200.0 MHz.
 Kernel says main memory's clock rate is 100.0 MHz.

 Sun-4 floating-point controller version 0 found.
 An UltraSPARC chip is available.
 FPU's frequency appears to be approximately 201.5 MHz.

 Use "-xtarget=ultra -xcache=16/32/1:1024/64/1" code-generation option.
 

g77 -O6 -funroll-all-loops -fomit-frame-pointer -ffast-math
-fstrength-reduce -fthread-jumps -mcpu=ultrasparc -mtune=ultrasparc
mdbnch.f

17.56 sec

not bad, huh!!! official data are

Sun Ultra 2 (200Mhz), Solaris 2.5.1, SC4.0 FORTRAN [^] ........ 15.7 s+
24Apr96

my own result with sun f77 4.2 is 16.5 sec

g77 is only ~10% slower !


f2c -A mdbnch.f

gcc -O6 -funroll-all-loops -fomit-frame-pointer -ffast-math
-fstrength-reduce -fthread-jumps -mcpu=ultrasparc -mtune=ultrasparc
mdbnch.c -lf2c -lm

25.70 sec

2. Intel P133/60ns EDO 32M/256K cache, Triton2 HX board 
   with agressive BIOS settings, Debian/hamm Linux
   with glibc 2

g77 -O6 -malign-double -funroll-all-loops -fomit-frame-pointer -ffast-math
-fstrength-reduce -fthread-jumps -mcpu=i586 mdbnch.f
 
59.58 sec

f2c -A mdbnch.f

gcc -O6 -malign-double -funroll-all-loops -fomit-frame-pointer -ffast-math
-fstrength-reduce -fthread-jumps -mcpu=i586 mdbnch.c 
-lf2c

62.89 sec

closest result here is

Pentium 586 200MHz, 256k cache, Win95, MS PwrStatn 4.0, -G5 -Ox 46.7 s
08Nov96

well, not bad either


NOTE!!! if i'll add -mno-ieee-fp option i'll get
aroung 53.5 sec for g77 and 56 sec for f2c+gcc
but first table will be wrong - some kind of numeric
instability diverges K.E. really fast.
Is it some known bug ?

in both cases g77 is a bit faster. I don't know
what is the cause of such big difference on Ultra

cheers

OK