[comp.sys.att] MIPS Rating of 3B2/400??

pjh@mccc.uucp (Pete Holsberg) (09/10/89)

Does anyone know the MIPS rating of the 3B2/400?  Thanks.
-- 
Pete Holsberg                UUCP: {...!rutgers!}princeton!mccc!pjh
Mercer College               CompuServe: 70240,334
1200 Old Trenton Road        GEnie: PJHOLSBERG
Trenton, NJ 08690            Voice: 1-609-586-4800

hjespers@attcan.UUCP (Hans Jespersen) (09/11/89)

In article <1989Sep10.014005.19352@mccc.uucp> pjh@mccc.UUCP (Pete Holsberg) writes:
>
>Does anyone know the MIPS rating of the 3B2/400?  Thanks.

My marketing guide says 1.5 MIPS.

-- 
Hans Jespersen                UUCP: uunet!attcan!hjespers
AT&T Canada Inc.                
Toronto, Ontario              

wcs) (09/12/89)

In article <10305@attcan.UUCP> hjespers@attcan.UUCP (Hans Jespersen) writes:
]>Does anyone know the MIPS rating of the 3B2/400?  Thanks.
]My marketing guide says 1.5 MIPS.

It shouldn't say that, unless MIPS are more inflated in Canada :-)
I think the commonly-used numbers are something like 
	300	.7 MIPS (long since expired)
	310,400	1.1	(10 MHz)
	3B15	1.5	(14 MHz)
	3B2/500	2.1	(without optional VCACHE)
	3B2/600	2.6	(VCACHE is standard)
	3B2/700	4-5
	/1000	faster

These seem to be reasonable numbers, at least for "Microvax MIPS";
it's hard to compare multiuser performance of a 3B2/400 using ST506
disks against a VAX/780 that's had the RM05's replaced with Eagles.
As with any UNIX box, you do need enough memory, especially with
slow disks.  I'm pretty sure SCSI is available for the 310/400.

There are companies out there that will replace the 10 MHz chips in
310s and 400s with 14 MHz, which works in most machines, if you
don't mind running them above rated speed and remember to get the
right shape chip packages.  It's certainly worth getting the MAU
(floating point chip) if you don't have one.
-- 
# Bill Stewart, AT&T Bell Labs 4M312 Holmdel NJ 201-949-0705 ho95c.att.com!wcs
# often found at 201-271-4712 tarpon.att.com!wcs Somerset CP3-4C423 fax469-1355
# Extremism in Defense of Liberty is No Substitute for Vice.

roynh@cbnewsc.ATT.COM (roy.n.harkness) (09/12/89)

In article <3802@cbnewsh.ATT.COM> wcs@cbnewsh.ATT.COM (Bill Stewart 201-949-0705 ho95c.att.com!wcs) writes:
>In article <10305@attcan.UUCP> hjespers@attcan.UUCP (Hans Jespersen) writes:
>]>Does anyone know the MIPS rating of the 3B2/400?  Thanks.
>]My marketing guide says 1.5 MIPS.
>
>It shouldn't say that, unless MIPS are more inflated in Canada :-)
>I think the commonly-used numbers are something like 
>	300	.7 MIPS (long since expired)
>	310,400	1.1	(10 MHz)
	.
	.
	.
> It's certainly worth getting the MAU
>(floating point chip) if you don't have one.

How much does the MAU effect the performance of the above machines?
Is unix (as distributed) able to recognize the MAU when it is there
and take advantage of it? Do the C libraries (and other floating point
code) know when the MAU is there and are they able to take automatic
advantage of it or do you have to recompile everything? Are the unix
support programs (such as sum) able to automatically take advantage of
the MAU?

>-- 
># Bill Stewart, AT&T Bell Labs 4M312 Holmdel NJ 201-949-0705 ho95c.att.com!wcs
># often found at 201-271-4712 tarpon.att.com!wcs Somerset CP3-4C423 fax469-1355
># Extremism in Defense of Liberty is No Substitute for Vice.

Roy Harkness		AT&T Bell Labs  (Not the 3B2 division)
att!ihlpb!roynh		312-979-4668

Bush is smart. First he's insured that he won't be assassinated by having
Quayle as his vice, Second he's managed to distract the american people
so he can dismantle the constitution and entrench his power.

friedl@vsi.COM (Stephen J. Friedl) (09/13/89)

In article <3109@cbnewsc.ATT.COM>, roynh@cbnewsc.ATT.COM (roy.n.harkness) writes:
> How much does the MAU effect the performance of the above machines?

The MAU is of limited use in many cases.  The best code is
generated by the CPLU4.2 compiler in -Kmau mode.  In this mode,
the compiler generates direct coprocessor calls, and it really
does run very, very fast.  However, it requires that the MAU be
present, so if you are compiling code that is to run all around
you really can't use it.  The -Kfpe mode generates code that
checks for a MAU and uses it or not accordingly.

The bummer is that this involves a function call for almost every
operation (probably all but loads and stores) and this is pretty
slow.  Note that in the absense of a MAU the function call
overhead is *much* less than the miserably slow FP interpreter
found in the older compilers.

In addition, many application packages are not compiled to use
even the conditional MAU code.  For instance, it was only
recently that Informix included this code, and it's my belief
that RM/Cobol still has the old FP interpreters.

Note that the FP interpreter is really an amazing piece of code.
It works in concert with the compiler to use the holes in the
opcode map of the WE32100 processor for each floating point
"instruction".  When one of these opcodes is used, the CPU takes
a trap, and this is routed to the user process because the FP
startup routines use the S3BIOP undocumented fast illegal opcode
handler (see <sys/sys3b.h> for a little info on this).

Given the address of the faulting instruction, the handler checks
to see if it is in fact a floating point instruction.  If so, it
enters an interpreter for the rest of the instruction, including
what seems to be all the addressing modes.  It is my feeling
after doing lots of testing that it is the instruction decode (if
you will) that takes most of the time, not the fp emulation.

It is also my feeling that this was a lot of energy targeted in
the wrong direction.  At the very least, supporting all those
addressing modes really cuts into the efficiency of the package,
and I really doubt that the compiler really can use them.

**** personal opinion: I do not have much experience with this
kind of thing, but I can see a lot of benefit by having the FP
interpreter located in the kernel.  The fptrap.o routine (located
in libc.a) is a little larger than 5kb of code, and this could
all be saved if it was not located in every program.  In addition
-- and more importantly -- it strikes me that by organizing it
this way, they could have built it such that inserting a MAU
would (say) cause a different "interpreter" to be loaded at boot
time.  Now old code can use the MAU.

They didn't do this for what I must imagine to be good reasons,
and we are stuck with what we have.  Oh well.

     Steve

Disclaimer: I very specifically do not speak for V-Systems, they
don't even know what I am talking about, and they get nervous
when I post.

-- 
Stephen J. Friedl / V-Systems, Inc.  /  Santa Ana, CA  / +1 714 545 6442 
3B2-kind-of-guy   / {attmail uunet}!vsi!{bang!}friedl  /  friedl@vsi.com

"But officer, I *was* carpooling; I had the Lord with me!" - me

jim@dfmp1.UUCP (Jim Murray) (09/15/89)

In article <1178@vsi.COM>, friedl@vsi.COM (Stephen J. Friedl) writes:
> 
> The MAU is of limited use in many cases.  The best code is
> generated by the CPLU4.2 compiler in -Kmau mode.  In this mode,
> the compiler generates direct coprocessor calls, and it really

Does this same thing happen with fpcci (C-FP+ Programming language 
utilities) ?  I've been compiling a statistical program with this because I \expected it to automatically use the MAU, have greater precision and faster
processing.  Am I wrong on this?  If I am wrong, is there a difference
in the precision that can be handled by cc -kmau vs fpcc.

Thanks
Jim Murray
UUCP ..!usenet!uwvax!schaefer!dfmp1!jim
INTERNET dfmp1!jim@schaefer.math.wisc.edu