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-4800hjespers@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