HDTenEightyP/NetNews huggingface dataset:
From: zstern@adobe.com (Zalman Stern)
Subject: Re: specks for the intel P5
Organization: Adobe Systems Incorporated
Date: Mon, 21 Dec 1992 02:09:30 GMT

In article <1h1qseINNdi@uniwa.uwa.edu.au> john@gu.uwa.edu.au (John West)  
writes:
> awolfe@moo.Princeton.EDU (Andrew Wolfe) writes:
> 
> >This is not quite true.  Intel has presented limited P5 details at  
Hot-Chips
> >and at the Microprocessor Forum.  Pentium will be a Superscalar
> >implementation of the X86 instruction set.  It is a single integrated CPU  
-
> >not a RISC chip with a 386 tagged on.  It will run 368 and 486 user code  
as
> >is.
> 
> Someone posted some numbers here a while back. A 33MHz external/66MHz  
internal
> part was claimed to run at 30-40 MIPS. Meaningless enough for you?
> Sounds about right. Superscalar, and they still can't get 1  
instruction/cycle.
> 
> John West
> --
> For the humour impaired: Insert a :-) after every third word
There was an article in the San Francisco Chronicle on Firday where some  
Intel person claimed the P5 would have a higher SPECfp rating than the  
R4000. You can be the judge of what that means. (If nothing else, its an  
apples and oranges comparison because of the time difference between when  
the chips came out. I gaurantee you they won't be beating an R4400 :-))

There was also an article the Saturday Chronicle detailing Intel's problems  
being able to reliably deliver flash memory chips. It was in sharp contrast  
to the Friday article which promoted Intel as the "rising star of American  
high-tech." 
--
Zalman Stern		   zalman@adobe.com		    (415) 962 3824
Adobe Systems, 1585 Charleston Rd., POB 7900, Mountain View, CA 94039-7900
  "Yeah. Ask 'em if they'll upgrade my shifters too." Bill Watterson
From: tdbear@dvorak.amd.com (Thomas D. Barrett)
Newsgroups: comp.arch
Subject: Re: Date request
Date: 17 Dec 92 14:40:05 GMT
Organization: Advanced Micro Devices, Inc.; Austin, Texas

In article <1992Dec16.182110.28229@ico.isc.com> timhu@ico.isc.com (Timothy Hu) writes:
>The convention MM/DD/YY probably came about because when we mention a
>date the long way, we say: December 16, 1992. 

I have always used the format 16 December 1992, which unfortunately is
the military's format :)  My favorite is the format which Microsoft
Word 2.0 has "16 December, 1992"... those crazy MS guys... I guess
they have never read Kate L. Terabean (sp?)

Tom
-- 
| Tom Barrett (TDBear), Sr. Engineer | tom.barrett@amd.com
| AMD PCD / Austin, TX  78741        | v:512-462-6856 / f:512-462-5155
| "No is Yes, and We are All FREE!"  | CO made a #2 no-no... PU!
| My views may not be shared by the organization of origin
From: gupta@crhc.uiuc.edu (Aloke Gupta)
Newsgroups: comp.arch
Subject: Survey on architecture support for Graphics/multimedia
Date: 11 Dec 92 19:35:31
Organization: University of Illinois Center for Reliable & High Performance
	Computing
Distribution: comp
NNTP-Posting-Host: buctril.crhc.uiuc.edu


    Hi, I am compiling a survey on architecture support for advanced
    visually-oriented applications

    Some aspects of this survey are the following:

    1. Support for graphics function in general-purpose processors.
    2. Sp. purpose coprocessors that offload work from main processors.
    3. Design choices in actual workstation systems ranging from Xterminals
       to advanced modeling/visualization engines.

    Some related areas include design of laser-printer engines / Postscript
    interpretors.

    Some of the microarchitecture issues are:
    =========================================

    1. Techniques for optimizing frame-buffer access.
        > Sp. cache instructions, e.g., allocate-no-fetch as in 88110.
        > Small frame-buffer write-back cache with 1/60 sec flushing.
        > Tiling organization of frame-buffer for exploiting access locality.
    2. Support for saturating arithmetic.
    3. Packed pixel arithmetic.
    4. Support for single-cyle x,y addressing.
    5. TLB support for different page sizes.
    6. Support for the special requirements posed by applications such as
        > MPEG
        > Display Postscript
        > 3-D graphics and viewing transforms
        > Gouraud/Phong shading
        > Real-time video processing
        > Speech recognition

--
Aloke Gupta                                         E-mail: gupta@crhc.uiuc.edu
Coordinated Science Laboratory                           or a-gupta@uiuc.edu
Dept. of Electrical & Computer Engineering
Univ. of Illinois at Urbana-Champaign
Newsgroups: comp.arch
From: dperks@gandalf.ca (Dave Perks)
Subject: Re: Any new instructions in a i486?
Organization: Gandalf Data Ltd.
Date: Tue, 15 Dec 1992 04:25:13 GMT

In <1992Dec15.014650.24209@grebyn.com> richk@grebyn.com (Richard Krehbiel) writes:

>This would explain why they chose to require the 486 instruction set.
>It does not explain why NeXT Step 486 won't run on the Cyrix 486DLC,
>which *has* the BSWAP instruction, like an Intel 486.

Is it also possible that since the Intel 486 supports supervisor-mode write
protection, it is is used to allow something like copy-on-write?  If NeXT Step
was designed to use this then the kernel would require fairly major changes.

Of course, I know nothing about NeXT Step so I'm just speculating wildly.
-- 
Dave Perks              | dperks@gandalf.ca        | 73230.2156@compuserve.com
Gandalf Data Limited    | TEL 1-613-723-6500 x8765 | (not checked very often)
Nepean, Ontario, Canada | FAX 1-613-226-1717       |
Newsgroups: comp.arch
From: hallam@zeus02.desy.de (Phill Hallam-Baker)
Subject: Re: IBM's FIRST RISC System/6000(tm) based Shared Memory Parallel Processor
Keywords: mp shared-memory parallel multiprocessor risc smp
Reply-To: Hallam@zeus02.desy.de
Organization: Deutsches Elektronen Synchrotron, Experiment ZEUS bei HERA
Date: Sat, 12 Dec 1992 18:05:37 GMT

In article <1992Dec11.131542.9190@jarvis.csri.toronto.edu>,
hsandhu@sys.toronto.edu (Harjinder S Sandhu) writes:

|>chased@rbbb.Eng.Sun.COM (David Chase) writes:
|>>I've had this nagging suspicion for about a year that people building
|>>MP's were working awfully hard to maintain coherency where it just
|>>didn't matter.  Given that most of the programming languages tell you
|>>to lock your data if it is shared, the "we're guarding against this"
|>>examples always looked like buggy programs to me.  People have been
|>>working on this at Rice, I know, and at least one other place that I
|>>cannot recall right now.
|> 
|>  Along the same lines, we have implemented and experimented with
|>a software coherence strategy based on the notion that applications
|>explicitly lock/unlock shared data. It requires no hardware or 
|>compiler support, but does rely on the programmer to program "correctly". 
|>This is described in a paper that will be appearing in the 1993 ACM SigPlan
|>Symposium on Principles and Practice of Parallel Programming in May:
|>"The Shared Regions Approach to Software Cache Coherence on
|>Multiprocessors". It will also be made available via ftp soon; send mail 
|>if you are interested.

IBM's approach should be able to streach scalability. hardware cache coherency
requires a lot of work. A lot of the time the software does not need the
coherency, ergo it makes sense to use software to solve the problem.

I disagree with the statement about putting the work onto the programmer though.
This work should go into the compiler. this may require a shift away from
traditional FORTRAN inspired approaches.

The IBM approach would be interesting for CSP. There data is explicitly locked
and unlocked. The model also sits very nicely with oops since it *is* a message
passing paradigm,

--

Phill Hallam-Baker
From: ivie@cc.usu.edu (CP/M lives!)
Newsgroups: comp.arch
Subject: Re: <None> (Should be Open Systems, bloody NEWS system...)
Date: 18 Dec 92 10:23:47 MDT
Organization: Utah State University

In article <BzGL07.2wK@dscomsa.desy.de>, hallam@zeus02.desy.de (Phill Hallam-Baker) writes:
> 
> W/NT on introduction will of course have to cope with the CP/M filestore which
> it inherited from MSDOS. 

About the only thing common between the MSDOS file system and the CP/M 
filesystem is the size of the filename (8.3). Although MSDOS _can_ use
CP/M-style FCBs, these are just a facade for old software.
-- 

Roger Ivie                      "My God! That computer is full of Pentium!
ivie@cc.usu.edu                  It's a wonder that you haven't been turned
                                 into mutants!"
From: sysmgr@king.eng.umd.edu (Doug Mohney)
Newsgroups: comp.arch
Subject: Re: COMPAQ PROPOSED SCALABLE I/O ARCHITECTURE
Date: 17 Dec 92 16:05:31 GMT
Reply-To: sysmgr@king.eng.umd.edu
Organization: Computer Aided Design Lab, U. of Maryland College Park

In article <1992Dec16.200846.12843@super.org>, rminnich@super.org (Ronald G Minnich) writes:
>I was wrong. I got some bad information from a DEC technical person 
>who was here a while back to show us the Alpha box. His firm claim was 100 
>Mbits/second. He blew it. 

Sure it wasn't a sales weenie? 

You should NEVER believe a sales weenie, no matter what the nameplate on the
box. :-). 


                    I have talked to Ehud, and lived.
  -- >                  SYSMGR@CADLAB.ENG.UMD.EDU                        < --
Newsgroups: comp.arch
From: george@allegra.att.com (Lal George)
Subject: Re: RISC assemblers question
Date: Fri, 18 Dec 1992 15:39:55 GMT
Organization: AT&T Bell Laboratories

   From: masticol@cadenza.rutgers.edu (Steve Masticola)
   Date: 17 Dec 92 15:16:37 GMT

   I've met a couple of people who have attempted to write assemblers for
   RISC machines, who say that it's a difficult job. Can someone give me
   an inkling as to why?


Scheduling in the presence of span dependent instructions adds 
an interesting twist to writing an assembler for RISC machines.
This is particularly true for machines that require NOPs.

For example, consider:
		
		instr		; regular instruction
		sdi(Label_1)	; span dependent instruction
		instr		; regular instruction
		instr		; regular instruction
	
		...
	Label_1:

One would like to schedule the above sequence of instruction after
having expanded the instruction sdi(Label_1). Unfortunately, this
presents a chicken and egg scenario. One cannot expand the instruction
sdi(Label_1) unless one knows the value of the label Label_1. Further,
one cannot determine the value of Label_1 unless one schedules these
instructions and determines the number of NOPs required.

This problem is addressed in the SML/NJ compiler and is quite easily
solved. The sources are free with the SML/NJ distribution. Further,
this "assembler" is derived from a machine description and is
presently used in the MIPS, SPARC, HPPA, and RS6000 code generators
for SML/NJ. There is every reason to believe that it will readily
adapt to other RISC processors too.




		
Newsgroups: comp.arch
From: dhd@exnet.co.uk (Damon)
Subject: Hand-tuned strcmp, Was: SPECmark for 486PC
Organization: ExNet Systems Ltd Public Access News, London, UK
Date: Mon, 14 Dec 1992 01:07:21 GMT

In article <723248954.28138@minster.york.ac.uk> mjl-b@minster.york.ac.uk (Mathew Lodge) writes:
>On C compilers (remember Dhrstone was actually implemented in Ada, then
>converted) this means hand tuning strcmp() -- I have a 68K C compiler that
>generates a little hand-crafted in-line asssembly for this particular
>library call.

I had a program (the same one I ported to an HP-UX in 30 minutes
mentioned in a post earlier today) that *doubled* in speed when I wrote
the inlined version of strcmp().  Well, not quite strcmp(); it did the
subtraction comparison in longer integers or something.

The code was compiling rather fancy concordances.  Bet NSA has a similar
program...

Damon
-- 
Damon Hart-Davis                          Internet: dhd@exnet.co.uk, d@hd.org

Public-access UNIX (Suns), news and mail for UK#5 per month.  FIRST MONTH FREE.
[1.35] Cheap Sun eqpt.  UUCP news/mail feeds.  Tel/Fax: +44 81 755 0077.
Newsgroups: comp.arch
From: peter@ferranti.com (peter da silva)
Subject: Re: Any new instructions in a i486?
Organization: Xenix Support, FICC
Date: Tue, 15 Dec 1992 18:42:18 GMT

In article <edm.724366309@wrs.com> edm@wrs.com (Ed McClannahan) writes:
> The jist I got was that NeXTstep wants to maintain compatible File Systems
> between 680X0 and X86 platforms.  To do this, they needed to do a lot of
> byte swapping on the X86 platforms.  Since the 486 has a simple instruction
> to do it while the 386 does not, NeXT just went with the 486.

But going back to Cyrix, since the 486?LC implements this instruction, what's
the point?
-- 
%Peter da Silva/77487-5012 USA/+1 713 274 5180/Have you hugged your wolf today?
/L{lineto}def/C{curveto}def/F{0 562 moveto 180 576 324 648 396 736 C 432 736 L
482 670 518 634 612 612 C}def/G{setgray}def .75 G F 612 792 L 0 792 L fill 1 G
324 720 24 0 360 arc fill 0 G 3 setlinewidth F stroke showpage % "Peerless"
Newsgroups: comp.arch
From: rsrodger@wam.umd.edu (Yamanari)
Subject: Re: COMPAQ PROPOSED SCALABLE I/O ARCHITECTURE
Organization: University of Maryland, College Park
Date: Wed, 16 Dec 1992 18:56:00 GMT

In article <1992Dec15.205639.25591@super.org> rminnich@super.org (Ronald G Minnich) writes:
>In article <1992Dec15.194637.10009@eng.umd.edu> sysmgr@king.eng.umd.edu writes:
>>You guys ever thought of licensing TurboChannel from DEC and building a
>>Pentium box/server around it? 
>
>TurboChannel is a dog. 
>
>Actually, seems to me they could look at SCI. Except they want low cost.
>But if the CMOS chips for SCI pan out, maybe they will meet the cost 
>range.

	How about QuikRing (Apple)?  
 
	<No flames, please--all I've seen is the hype and none of the
	commentary--is there anything there besides hype and computer
	mags babbling happily?>

-- 
	"If you can't eat sand, why the hell are you living in a desert?"

	     Rule 1:  "Don't have more children than you can feed."
	  	  Nuclear redevelopment for a better world!
Newsgroups: comp.arch
From: lewine@cheshirecat.webo.dg.com (Donald A. Lewine)
Subject: IBM AS/400 is the world's slowest computer
Date: Fri, 18 Dec 92 16:59:50 GMT
Reply-To: lewine@cheshirecat.webo.dg.com
Organization: Data General Corporation

IBM is currently running full-page Ads that claim "The AS/400
is the world's most powerfull computer with the industry's best
price/performance(*)"

"(*) According to the TPC-C benchmark results published through
     12/3/92"

IBM does not point out the the AS/400 is the only computer with
TPC-C results published as of 12/3/93.  The AS/400 is also the
world's slowest and most expensive computer by the same benchmark.

Do people fall for this stuff?  IBM claims that the AS/400 is the
best selling mid-range system in the world, so someone must fall
for it.

--------------------------------------------------------------------
Donald A. Lewine                (508) 870-9008 Voice
Data General Corporation        (508) 366-0750 FAX
4400 Computer Drive. MS D112A
Westboro, MA 01580  U.S.A.

uucp: uunet!dg!lewine   Internet: lewine@cheshirecat.webo.dg.com
From: gjr@zurich.ai.mit.edu (Guillermo J. Rozas)
Newsgroups: comp.arch
Subject: Re: Any use for Branch if Even/Odd ?
Date: 11 Dec 92 23:11:16
Organization: M.I.T. Artificial Intelligence Lab.
Reply-To: gjr@zurich.ai.mit.edu
NNTP-Posting-Host: chamartin.ai.mit.edu
In-reply-to: moss@cs.cmu.edu's message of 11 Dec 92 22:27:28 GMT

In article <MOSS.92Dec11172728@CRAFTY.cs.cmu.edu> moss@cs.cmu.edu (Eliot Moss) writes:

|   Many garbage collected / dynamic languages use tagging to distinguish pointers
|   from non-pointers. If one uses the low bit to implement that tag, the branch
|   has obvious utility ....					ELiot

Another place where it is useful is to test packed booleans.
On most machines, the word containing the packed boolean would have to
be masked, but the mask generation might take multiple instructions.
Having branch-on-low-bit, you only need to shift before branching.
Newsgroups: comp.arch
From: ajrooks@mansci1.UWaterloo.ca (Alan Rooks)
Subject: Re: Relatively long cycle time in 486 LOOP instruction
Keywords: 486 LOOP instruction cycle
Organization: University of Waterloo
Date: Wed, 16 Dec 1992 21:29:26 GMT

In article <fWFHrqe@quack.sac.ca.us> dfox@quack.sac.ca.us (David Fox) writes:
>
>I and others on a different network have had an ongoing thread about
>386/486 assembler programming in general.  One has posted recently
>that the 486's LOOP and JMP [E]CX instructions seem to take an
>inordinately long time, compared to other instructions that branch.
>

I've tested this on quite a few '486 motherboards, and always found the
same result: all of the complex looping instructions (movs, lods, stos,
scas, cmps, loop, loopz, loopnz, jecxz) take longer to execute than
the series of operations that they are composed of.  In other words,
use simple instructions like dec, inc, mov, jnz, etc, and it will go
faster.  This is no doubt due to the '486's optimized execution of
simple instructions.  Remember: the '486 is a RISC, if you use the
right instructions!  :-)

Alan Rooks	University of Waterloo		ajrooks@mansci1.uwaterloo.ca
Newsgroups: comp.arch
From: Philip Machanick <philip@concave.cs.wits.ac.za>
Subject: Re: Compaq's Proposed Scalable I/O Architecture
X-Xxdate: Wed, 16 Dec 92 10:25:11 GMT
Organization: Computer Science Dept, Wits University
X-Useragent: Nuntius v1.1.1d12
Date: Wed, 16 Dec 1992 08:31:07 GMT

In article <1992Dec11.231814.13317@twisto.eng.hou.compaq.com> Chris
Simonich, simonich@croatia.eng.hou.compaq.com writes:
>Sorry if this is a repost, we were unable to determine if our
>server posted the original copy.  Could someone outside the
>Houston area please post a response upon receiving this article?

Is this far enough from Houston for you? At least 3 copies reached this
part of the world.
--
Philip Machanick
Computer Science Dept, Univ of the Witwatersrand, 2050 Wits, South Africa
philip@concave.cs.wits.ac.za  phone: 27 (11) 716-3759  fax: 339-7965
Xref: sparky comp.arch:11791 comp.arch.storage:876
From: tdbear@dvorak.amd.com (Thomas D. Barrett)
Newsgroups: comp.arch,comp.arch.storage
Subject: Re: ?Concurrent DMA possible on smarter PC buses (EISA/MCA/Localbus)
Keywords: EISA,MCA,Localbus,VESA,PC,IBM,smartIO
Date: 19 Dec 92 16:30:12 GMT
Organization: Advanced Micro Devices, Inc.; Austin, Texas

In article <1gul5nINN7ln@cbl.umd.edu> mike@cbl.umd.edu (Michael Santangelo) writes:
>
>So this theoretical EISA SCSI controller and this theoretical EISA FDDI
>controller could both be doing DMA writes to main memory (interleaving their
>accesses I assume)?

Actually, they could "snarf" (to, eek!, borrow an intel term) each
other's transfers to main memory I suppose.  This concept of single
transfers being snarfed-up was first seen by me in a Z80 design which
used a series of POPs and PUSHs to perform a block move in half the
time.


-- 
| Tom Barrett (TDBear), Sr. Engineer | tom.barrett@amd.com
| AMD PCD / Austin, TX  78741        | v:512-462-6856 / f:512-462-5155
| "No is yes, And we're all free"    | CO made a #2 no-no... PU!
| My views may not be shared by the organization of origin
Newsgroups: comp.arch
From: andy@SAIL.Stanford.EDU (Andy Freeman)
Subject: Re: Any use for Branch if Even/Odd ?
Organization: Computer Science Department,  Stanford University.
Date: Tue, 15 Dec 1992 18:31:27 GMT

In article <1992Dec15.024545.7336@ryn.mro4.dec.com> Peter.Mayne@cao.mts.dec.com writes:
>In article <1992Dec14.203631.16388@CSD-NewsHost.Stanford.EDU>, andy@SAIL.Stanford.EDU (Andy Freeman) writes:
>>Does anyone know why they preferred even/odd to >=0/<0?  Sometimes one
>>has to test the sign bit, so why not use it whenever one can use any
>>bit to split things into two classes?
>
>VMS status codes record more than just true/false. The bottom three bits of
>a status code are encoded as follows:

So?  Any three bits work just as well.

>Opinion: If the status codes were at the high end of the longword, the
>error codes for a particular facility would be scattered all over the
>range instead of in a single group of numbers; harder for us humans to
>comprehend. Given that the VAX architecture has bit test operations,
>why not do it this way?

DEC's dinosaurs had symbolic assemblers and debuggers.  I "remember"
that even some of the 11's had similar software well before the vax
and VMS was invented.

-andy
--
From: wayne@backbone.uucp (Wayne Schlitt)
Newsgroups: comp.arch
Subject: Re: Any new instructions in a i486?
Date: Sun, 20 Dec 1992 23:10:36 GMT
Organization: The Backbone Cabal
	<PCG.92Dec19162224@decb.aber.ac.uk> <9212200017.12@rmkhome.UUCP>
NNTP-Posting-Host: helios.unl.edu

In article <9212200017.12@rmkhome.UUCP> rmk@rmkhome.UUCP (Rick Kelly) writes:

< >(somebody)> NeXTStep is said to not run on the Cyrix 486 chips because
< >(somebody)> "they are not real 486's".  No one has come up with a
< >(somebody)> reliable reason _why_ NeXT doesn't think they are "real
< >(somebody)> 486's" or why NeXTStep won't run on them.
< >
< >FUD, FUD. Ah Intel, Intel. :-)
< 
< 
< I don't see where this has anything to do with Intel.  Cyrix decided that
< they could make some money by cloning a best selling CPU chip.  Obviously,
< they have missed something.  


Well, from the info that has been posted so far, it looks more and
more like it is NeXT that screwed something up and doesn't care about
fixing it.  Chances are NeXTStep won't run on the Pentium either if it
is that fragile.


-wayne
From: ivie@cc.usu.edu (CP/M lives!)
Newsgroups: comp.arch
Subject: Re: COMPAQ PROPOSED SCALABLE I/O ARCHITECTURE
Date: 17 Dec 92 10:05:28 MDT
Organization: Utah State University

In article <1992Dec16.235011.17202@twisto.eng.hou.compaq.com>, simonich@croatia.eng.hou.compaq.com (Chris Simonich) writes:
> Very well put.  However, wouldn't it be MUCH cheaper if you used a byte wide
> interface instead of 32 bit wide interfaces?  The same architecture with
> the Compaq Proposal saves a lot of pins on the control block.
> I don't know all that much about Tc, but I've been told that each channel
> requires about 60ish pins on the controller once data, control, and power/
> gnd pins are taken into account.  The Compaq proposal requires 20ish pins
> per channel on the controller.  One could save 120 pins on the controller
> for this case by using the Compaq Proposal rather than Tc.  A 120 pin savings
> translates into a significant cost savings.

Well, working for a small company that can't afford to run out and spin
ASICs for every design, I would much rather deal with a TURBOchannel that
can be managed with a few PALs and jellybeans than a lower pin-count bus
that requires an ASIC to unpack that packets.
-- 

Roger Ivie                      "My God! That computer is full of Pentium!
ivie@cc.usu.edu                  It's a wonder that you haven't been turned
                                 into mutants!"
Newsgroups: comp.arch,comp.sys.dec,comp.sys.sgi,comp.sys.hp
From: mo@gizmo.bellcore.com (Michael O'Dell)
Subject: Is the SCI spec online anywhere??
Keywords: 
 
Reply-To: mo@bellcore.com
Organization: Center for Chaotic Repeatabilty
Date: Fri, 18 Dec 92 20:55:01 GMT

I asked uncle archie but he didn't seem to know.

	-Mike
Newsgroups: comp.arch,comp.sys.dec,comp.sys.sgi,comp.sys.hp
From: lindsay+@cs.cmu.edu (Donald Lindsay)
Newsgroups: comp.arch
Subject: Re: Multiprocessors
Date: 12 Dec 92 18:20:02 GMT
Article-I.D.: cs.Bz5s9F.J32.2
Organization: School of Computer Science, Carnegie Mellon

xm9@sdcc12.ucsd.edu (richard g. adair) writes:
>Even though a 730 will toast an 8 processor SGI!

Never fear. SGI has promised a machine with 32 R4400's. Of course, HP
has promised a 16 CPU machine. It's finally about time to multithread
those codes, folks.

Oddly, although Crays have been multiprocessors for years, a lot of
programs only use one Cray processor. This is often largely a
function of incentive. One installation offered a big budget break to
parallel applications, and sure enough, almost everything suddenly
turned out to be parallelizable.
-- 
Don		D.C.Lindsay	Carnegie Mellon Computer Science
From: perry@hpfcmgw.FC.HP.COM (Perry Scott)
Date: Fri, 11 Dec 1992 00:04:29 GMT
Subject: Re: Re: Re: Comparison of Alpha, MIPS and PA-RISC-II wanted (fwd)
Organization: HP Fort Collins, CO