Tech Insider					     Technology and Trends


			      USENET Archives

Path: sparky!uunet!usc!zaphod.mps.ohio-state.edu!uakari.primate.wisc.edu!
sdd.hp.com!mips!darwin.sura.net!uvaarpa!cv3.cv.nrao.edu!laphroaig!cflatter
From: cfla...@nrao.edu (Chris Flatters)
Newsgroups: comp.unix.bsd
Subject: Re: Jolitz 386BSD-0.1 -- floating point perform
Message-ID: <1992Jul22.152854.27730@nrao.edu>
Date: 22 Jul 92 15:28:54 GMT
References: <l6qc51INN1gu@neuro.usc.edu>
Sender: ne...@nrao.edu
Reply-To: cfla...@nrao.edu
Organization: NRAO
Lines: 22

In article l6qc51...@neuro.usc.edu, mer...@neuro.usc.edu (merlin) writes:
>I have most of the US Army BRLCAD three dimensional CSG modeling and
>distributed ray tracing system ported to the Jolitz 386BSD-0.1.  But,
>I am getting only about one fifth of the floating point performance
>previously measured using AT&T pcc and GNU gcc 1.4x on ATT UNIX SYSV.
>
>Does the compiler default to '387 emulation?  Is there some flag which
>needs to be set to actually use the coprocessor?  Or are there reasons
>386BSD-0.1 would exhibit relatively poor floating point performance?

The problem is that there is a mismatch between gcc 1.4 and Intel coprocessors.
gcc expects floating-point registers while the 80x87s have a stack.  This
leads to a fairly large performance hit.  gcc 2.x can produce optimised code
for the 80x87.  Is anyone working on porting gcc 2.x to 386BSD? Come to
think of it, is there anything that needs to be done to do this (wouldn't
the BSD/386 configuration work)?

NB: the coprocessor shows up as device psx0 during the bootstrap sequence.  If
this doesn't show up 386BSD thinks you don't have a coprocessor.

	Chris Flatters
	cfla...@nrao.edu

Path: sparky!uunet!mcsun!news.funet.fi!hydra!klaava!torvalds
From: torv...@klaava.Helsinki.FI (Linus Benedict Torvalds)
Newsgroups: comp.unix.bsd
Subject: Re: Jolitz 386BSD-0.1 -- floating point perform
Message-ID: <1992Jul23.010341.22292@klaava.Helsinki.FI>
Date: 23 Jul 92 01:03:41 GMT
References: <l6qc51INN1gu@neuro.usc.edu> <1992Jul22.152854.27730@nrao.edu>
Organization: University of Helsinki
Lines: 22

In article <1992Jul22.1...@nrao.edu> cfla...@nrao.edu writes:
> [ deleted ]  Is anyone working on porting gcc 2.x to 386BSD? Come to
>think of it, is there anything that needs to be done to do this (wouldn't
>the BSD/386 configuration work)?

One thing that migth be a problem with porting gcc-2.2.2 to 386BSD is
that gcc-2.2.2 has added the 'fsqrt' command to the list of floating
point instructions that gcc can create code for - and I don't know if
the 386bsd math emulator emulates that particular command yet.  I've
already written the code (it's in linux), but it wasn't available back
when people ported the emulator to 386bsd. 

If 386bsd 0.1 does indeed use the linux math-emulator (I haven't even
checked: maybe they found something better) it shouldn't be difficult to
add the fsqrt support in there (the linux math-emulator may not be fast
or complete, but it's simple and relatively modular).  The code can be
gotten from any linux site: while the linux source is generally
copylefted, the math-code can be used freely for 386bsd (but /only/ for
386bsd - if you want to use it for something else and cannot accept the
copyleft conditions, contact me). 

		Linus

Newsgroups: comp.unix.bsd
Path: sparky!uunet!cis.ohio-state.edu!zaphod.mps.ohio-state.edu!wupost!
darwin.sura.net!uvaarpa!cv3.cv.nrao.edu!laphroaig!cflatter
From: cfla...@nrao.edu (Chris Flatters)
Subject: Re: Jolitz 386BSD-0.1 -- floating point perform
Message-ID: <1992Jul24.161646.22896@nrao.edu>
Sender: ne...@nrao.edu
Reply-To: cfla...@nrao.edu
Organization: NRAO
References: <l6qc51INN1gu@neuro.usc.edu>
Date: Fri, 24 Jul 1992 16:16:46 GMT
Lines: 50

In article l6qc51...@neuro.usc.edu, mer...@neuro.usc.edu (merlin) writes:
>I have most of the US Army BRLCAD three dimensional CSG modeling and
>distributed ray tracing system ported to the Jolitz 386BSD-0.1.  But,
>I am getting only about one fifth of the floating point performance
>previously measured using AT&T pcc and GNU gcc 1.4x on ATT UNIX SYSV.
>
>Does the compiler default to '387 emulation?  Is there some flag which
>needs to be set to actually use the coprocessor?  Or are there reasons
>386BSD-0.1 would exhibit relatively poor floating point performance?

I ran some checks last night and 386BSD is certainly exploiting the coprocessor.
These are the results from the Plum2 benchmark (See section 8.2 of "C++
Programming Guidelines" by Thomas Plum and Dan Saks.  The results are
the average time for a register int, auto short, auto long and auto float
operation and the average time to call and return from an empty function.
Times are in nominal milliseconds (CLOCKS_PER_SEC was missing from <time.h>
so I guessed a value of 100 --- I now think that it should have been 60.
The tests were performed on a CompuAdd 325s (25MHz 80387SX CPU) with a
Cyrix 83S87 FasMath coprocessor.

                       register      auto      auto  function      auto
                            int     short      long  call+ret    double
            386BSD gcc    0.178     0.448     0.474      1.62      4.94  
         386BSD gcc -O    0.159     0.207     0.159      1.75      3.37  

The ration of floating-point time to auto long is 21.2 (with optimization)
which is in the correct ball park for a 386SX/387SX system but a little
on the long size.

As a control, I made a copy of the dist.fs disk with a compiled version of
bench2 on it and booted it on my portable: a 16 MHz 80386SX system without
a coprocessor.  The results were

                       register      auto      auto  function      auto
                            int     short      long  call+ret    double
         386BSD gcc -O    0.240     0.317     0.242      2.32       346  

Note that the ratio of of f-p time to auto long is now 1429.8 --- in other
words emulation is more than 60 times slower than the coprocessor.  Unless
BRLCAD uses very little floating-point I believe that the coprocessor is
active on Alexander-James Annala's machine too (If Alexander-James wants to
try these tests I'll send him the source code if he drops me a line).

For final comparison, I have some old figures from Linux with gcc 2.1.
Using the register int time to place the results on the same scale as
the 25MHz results above the mean time for a f-p operation was 2.09 usec
without optimization and 0.936 usec at -O1 and above.

	Chris Flatters
	cfla...@nrao.edu



Newsgroups: comp.unix.bsd
Path: sparky!uunet!darwin.sura.net!uvaarpa!cv3.cv.nrao.edu!laphroaig!cflatter
From: cfla...@nrao.edu (Chris Flatters)
Subject: Re: 386BSD-0.1/BRLCAD4.0 benchmark -- poor floa
Message-ID: <1992Jul29.152914.2508@nrao.edu>
Sender: ne...@nrao.edu
Reply-To: cfla...@nrao.edu
Organization: NRAO
References: <l7ctu0INN880@neuro.usc.edu>
Date: Wed, 29 Jul 1992 15:29:14 GMT
Lines: 21

In article l7ctu0...@neuro.usc.edu, mer...@neuro.usc.edu (merlin) writes:
>It looks like the floating point processor is used for simple floating
>point operations (+, -, /, *) but not for higher functions -- these go
>to /usr/src/lib/libm/ieee/support.c where they get emulated (ie _sqrt)
>very slowly.  Perhaps someone has a redistributable i386 library which
>could be plugged in place of the default 4.3BSD mathematics library.
>
>This is likely why BRLCAD 4.0 runs correctly but very slowly at the
>present time.  Any help or suggestions which would fix this problem
>would be very much appreciated.  
>
>Does gcc 2.2 actually use 80387 inline code for transcedental functions?

No. I just looked :-(.  (Unless it is very well hidden).

It could probably be made to though.  There appears to be some support for
inlining transcendental functions for the Moto 68881.

	Chris Flatters
	cfla...@nrao.edu

Path: sparky!uunet!mcsun!news.funet.fi!hydra!klaava!torvalds
From: torv...@klaava.Helsinki.FI (Linus Benedict Torvalds)
Newsgroups: comp.unix.bsd
Subject: Re: 386BSD-0.1/BRLCAD4.0 benchmark -- poor floa
Message-ID: <1992Jul29.222708.4315@klaava.Helsinki.FI>
Date: 29 Jul 92 22:27:08 GMT
References: <l7ctu0INN880@neuro.usc.edu> <1992Jul29.152914.2508@nrao.edu>
Organization: University of Helsinki
Lines: 31

In article <1992Jul29....@nrao.edu> cfla...@nrao.edu writes:
>In article l7ctu0...@neuro.usc.edu, mer...@neuro.usc.edu (merlin) writes:
>>
>>Does gcc 2.2 actually use 80387 inline code for transcedental functions?
>
>No. I just looked :-(.  (Unless it is very well hidden).

gcc-2.2.2 only uses the basic math + fsqrt (fsqrt is new to gcc-2.x). 
The basic math is handled pretty well, though: much better than with
earlier versions.  gcc-2 knows about the fpu stack, resulting in fpu
code that looks almost hand-optimized (at least sometimes).  gcc-1.40
isn't very good at handling the 387 stack (it seems to use mostly
ready-made templates). 

>It could probably be made to though.  There appears to be some support for
>inlining transcendental functions for the Moto 68881.

I don't think inlining is as easy on the 387 as it's on a 68881: the 387
transcendental functions have enough special cases (argument limitations
etc) that it's probably easier to do it in a dedicated function.  But
those functions should certainly use the 387 instructions instead of
using series arithmetic or whatever portable C code the current 386bsd
libraries seem to use. 

The linux libraries might be useful: linux has two different math
libraries, one for soft-float (ie using only the normal arithmetic
functions that are emulated), and one for hard-float.  With shared
libraries (under linux), the same binary can use either, but under
386bsd you'd have to decide at link-time which to use. 

		Linus

			        About USENET

USENET (Users’ Network) was a bulletin board shared among many computer
systems around the world. USENET was a logical network, sitting on top
of several physical networks, among them UUCP, BLICN, BERKNET, X.25, and
the ARPANET. Sites on USENET included many universities, private companies
and research organizations. See USENET Archives.

		       SCO Files Lawsuit Against IBM

March 7, 2003 - The SCO Group filed legal action against IBM in the State 
Court of Utah for trade secrets misappropriation, tortious interference, 
unfair competition and breach of contract. The complaint alleges that IBM 
made concentrated efforts to improperly destroy the economic value of 
UNIX, particularly UNIX on Intel, to benefit IBM's Linux services 
business. See SCO v IBM.

The materials and information included in this website may only be used
for purposes such as criticism, review, private study, scholarship, or
research.

Electronic mail:			       WorldWideWeb:
   tech-insider@outlook.com			  http://tech-insider.org/