HDTenEightyP/NetNews huggingface dataset:
From: gbyrd@ncsc.org (Gregory T. Byrd)
Subject: Re: Could I compete the low-end CM5 with multiple SPARCstations?
Keywords: CM5, vector units
Reply-To: gbyrd@ncsc.org (Gregory T. Byrd)
Organization: North Carolina Supercomputing Center
Date: Wed, 22 Jul 1992 21:44:47 GMT

In article <1992Jul22.191250.8476@msuinfo.cl.msu.edu>,
enbody@ss33.cps.msu.edu (Richard Enbody) writes:
 >In article <9207221613.AA05637@x1sun6.ccl.itri.org.tw>,
lycmit@X1SUN6.CCL.ITRI.ORG.TW (Yin-Chih Lin) writes:
 >|> 
 >|> I am curious, if I connect 32 SPARCstation 10 model 30 (33MHz, SuperSPARC
 >|> module with 86.1 MIPS - Sun Micro adverted!?) computers (loosely-coupled
 >|> MIMD multicomputers?) either by Ethernet, ISDN or FDDI with the multi-
 >|> thread OS and might use facilities from Linda-like distributed data
 >|> structures. Is it possible for me to obtain the reasonable performance
 >|> when compared with the 32-node TMC CM5 (SIMD machine)?
 >
 >Greatly simplified response:
 >
 >The difference is communication latency.  For many, but certainly not all,
 >applications that could kill you.

Another difference -- most folks who order CM5's will get the 
optional vector units, which provide a peak 128 MFlops
per node.  (And they also do integer ops.)

...Greg Byrd             North Carolina Supercomputing Center
   gbyrd@ncsc.org        P.O. Box 12889
   (919)248-1439         Research Triangle Park, NC  27709-2889
From: daryl@hpcuhe.cup.hp.com (Daryl Odnert)
Date: Mon, 27 Jul 1992 16:21:44 GMT
Subject: Re: Code Repositioning on MIPS Systems?
Organization: Hewlett Packard, Cupertino
Newsgroups: comp.arch

> Are there any such tools available on Hewlett Packard
> systems?  MIPS's "cord" is part of the standard no-extra-cost
> software shipped (& has been since about '87); how about HP's?

Procedure level code repositioning is already available on series 700
workstations.  This feature is supported in the linker.  See the HP-UX
man page for ld(1) and look at the text regarding the -I and -P
options.

On HP-UX release 9.0 for the series 700 and series 800 systems, we
will be introducing basic block level code repositioning for the C and
FORTRAN language products.

HP's implementation is based on the techiques described in Pettis &
Hansen's "Profile Guided Code Positioning" which is published in the
SIGPLAN '90 conference proceedings (SIGPLAN Notices, Vol 25, No 6, June
1990, pgs 16-27.)
 
Daryl Odnert     daryl@cup.hp.com
Hewlett-Packard
California Language Lab
Newsgroups: comp.arch
From: glew@pdx007.intel.com (Andy Glew)
Subject: Re: CISC Microcode (was Re: RISC Mainframe)
Organization: Intel Corp., Hillsboro, Oregon
	<GLEW.92Jul14234349@pdx007.intel.com> <141o6mINN10h@rodan.UU.NET>
Date: Fri, 24 Jul 1992 02:33:53 GMT

    Sure. You also have to check caches for consistency in multi-processor
    systems and when you do DMA, so the circuits or software are already in place.
    It can be done by cache controllers which monitor the bus or by invalidating
    cache entries which correspond to the target memory area.

Hmmm...  My background is in Motorola systems and minicomputers.  In
my experience most I/O devices are *not* cache coherent, so the
circuits are not in place. Plus, even when cache coherent, there was
frequently a performance advantage to not being coherent.

Now, admittedly, in the PC world I have been surprised by how common
cache coherent I/O is.  How about other worlds?  Which is more common,
cache coherent or cache incoherent I/O?  I believe John Mashey already
noted that on the R3000 I/O was non-coherent, but on the R4000 I/O is
coherent.



--

Andy Glew, glew@ichips.intel.com
Intel Corp., M/S JF1-19, 5200 NE Elam Young Pkwy, 
Hillsboro, Oregon 97124-6497

This is a private posting; it does not indicate opinions or positions
of Intel Corp.

Intel Inside (tm)
Newsgroups: comp.arch
From: ed@weir.pa.dec.com (Ed Gould)
Subject: Re: MVC and MVCL (was Re: RISC Mainframe)
Reply-To: ed@pa.dec.com
Organization: DEC Network Systems Lab, Palo Alto
Date: Fri, 24 Jul 92 19:05:06 GMT

> And since most of the code is written in assembly language to begin
> with, compiler optimizations are moot.

I don't think this necessarily follows.  For example, one of the compiled
languages for Alpha is Macro-32, i.e., VAX Assembly.  It's unusual to think
of what started out as an assembly language to be run through a compiler,
but there's nothing magic about it.

--
Ed Gould	  ed@pa.dec.com		Digital Equipment Corporation
+1 415 688 1309	  Network Systems Lab	505 Hamilton Ave, Palo Alto, CA  94301

"Unison is only one form of harmony." -- LW
Newsgroups: comp.arch
From: glew@pdx007.intel.com (Andy Glew)
Subject: Re: CISC Microcode (was Re: RISC Mainframe)
Organization: Intel Corp., Hillsboro, Oregon
	<BrE09F.4JK@metaflow.com> <1992Jul15.163217.434@urbana.mcd.mot.com>
	<BrM813.Du5@zoo.toronto.edu>
Date: Fri, 24 Jul 1992 02:46:29 GMT


    It's not obvious why you need special instructions for it, however.
    If I recall correctly, the first MIPS chips had the physical address
    space in their kernel virtual space *twice*:  the second was uncached,
    specifically so you could do things like bulk data copying without
    trashing the cache.

By the way: creating virtual address aliases with different cache
properties is a recipe for a complicated, expensive, and lower
performance than it should be multilevel cache system.

--

Andy Glew, glew@ichips.intel.com
Intel Corp., M/S JF1-19, 5200 NE Elam Young Pkwy, 
Hillsboro, Oregon 97124-6497

This is a private posting; it does not indicate opinions or positions
of Intel Corp.

Intel Inside (tm)
From: limes@ouroborous.Eng.Sun.COM (Greg Limes)
Newsgroups: comp.arch
Subject: Re: SparcStation Questions
Date: 24 Jul 1992 18:17:01 GMT
Organization: Sun Microsystems, Inc.
NNTP-Posting-Host: ouroborous

In article <BrutGJ.36H@zoo.toronto.edu> henry@zoo.toronto.edu (Henry Spencer) writes:
| Details on Sun MMUs in particular are definitely proprietary nondisclosure
| material, although you can learn a lot from careful study of include files
| and the like.
...
| That was the situation about five years ago, anyway; there are probably
| some new wrinkles in the more recent designs.

Recent designs -- the Sun-4M series of machines, which include the
SPARCsystem 600 series MP servers and (now) the SPARCstation 10 -- use
the SPARC Reference MMU, which is quite well and publicly documented.
Newsgroups: comp.arch
From: henry@zoo.toronto.edu (Henry Spencer)
Subject: Re: SparcStation Questions
Date: Thu, 23 Jul 1992 18:17:05 GMT
Organization: U of Toronto Zoology

In article <1992Jul23.163423.19061@dcc.uchile.cl> pchris@dcc.uchile.cl writes:
>Looking through the /usr/include/sun4/param.h file on some Sun Sparcs, I came
>across a few things I could use some help on...

To get this sort of information from Sun -- or, unfortunately, almost any
manufacturer today -- you need to convince them that you have a worthy
project which needs to know.  Then you sign a nondisclosure agreement.
Then they ship you a bundle of Xeroxed sheets, missing page 17 and two
of the appendixes, with hand-drawn diagrams and inked-in corrections,
telling you not quite everything you need to know about the previous
version of the hardware.  And if you ask about the missing bits, you get
told "oh, we never did get that stuff written down properly".

>What does this 3 level mmu on the 470 look like?  What does the normal mmu
>on the other Suns look like?

Details on Sun MMUs in particular are definitely proprietary nondisclosure
material, although you can learn a lot from careful study of include files
and the like.

The outlines are not secret.  (One wonders why Sun is so anal-retentive
about details that would not be hard to reverse-engineer.)  Some bits of
the address plus bits from what is essentially a short process ID form
an address into memory A.  The number that comes out, plus some more bits
from the address, form an address into memory B.  Out of that comes a
page-table entry, with an address in main memory plus some permission
bits and such.  This is essentially an associative TLB simulated with
ordinary RAMs, using memory A as the associative-lookup mechanism.

That was the situation about five years ago, anyway; there are probably
some new wrinkles in the more recent designs.
-- 
There is nothing wrong with making      | Henry Spencer @ U of Toronto Zoology
mistakes, but... make *new* ones. -D.Sim|  henry@zoo.toronto.edu  utzoo!henry
From: doconnor@sedona.intel.com (Dennis O'Connor)
Newsgroups: comp.arch
Subject: Re: What's in a name?
Date: 23 Jul 92 15:55:13 GMT
Organization: Intel i960(tm) Architecture
In-reply-to: vhs@darkcube.radig.de's message of 22 Jul 92 17:02:28 GMT


vhs@darkcube.radig.de (Volker Herminghaus-Shirai) writes:
] In article <> davidsen@ariel.crd.GE.COM  (william E Davidsen) writes:
] > In article <1992Jul20.092822.7666@spool.cs.wisc.edu>,  
] mfrank@wilma.cs.wisc.edu (Matt Frank) writes:
] > 
] > |> 1)  Backwards compatability is a waste of everyones time.
] > 
] >   Fortunately for the vendors, consumers disagree with that statement.
] > In millions.
]
] You're right. Fortunately *for the vendors*.

Give me a break. Intel's employees would love to take off with a bold new
architecture that would be the pinnacle of microprocessor performance,
completely free of the baggage of the past.

It's the CUSTOMERS who INSIST on compatability. Customers also
insist on performance. It's the hard-working X86 architects and
engineers who have to suffer and jump through hoops to deliver both.
I've got a lot of respect for those guys, and always have had.
And it's a good thing process technology keeps improving.

Perhaps Volker Herminghaus-Shirai is smarter than all those customers :
maybe his freely-given opinion is somehow more important than the 
"voting with their wallets" millions of PC buyers have done.
But it's not important to Intel's bottom line.





--
Dennis O'Connor			doconnor@sedona.intel.com
Newsgroups: comp.arch,alt.folklore.computers,comp.benchmarks
From: rbe@yrloc.ipsa.reuter.COM (Robert Bernecky)
Subject: Re: dinosaur horsepower
Reply-To: rbe@yrloc.ipsa.reuter.COM (Robert Bernecky)
Organization: Snake Island Research Inc, Toronto
Date: Thu, 30 Jul 92 05:32:40 GMT

In article <Bs3oGt.6vp@helios.physics.utoronto.ca> mark@cita.toronto.edu writes:
>Larry Stewart's proposal regarding the computer history project prompts
>me to offer a suggestion for something I'd like to see:  A compendium of
>old machines, and just how fast (well, slow) they were compared with the
>systems we use today, and how much they cost when they were new.
>

I'm just finishing a course in Philosophy of Math. One topic we covered
was computer proofs, with the 4-colo(u)r theorem as the prime example.

The prof (Jim Brown -- a superb lecturer, and excellent teacher, for 
those of you interested in the topic!) noted that the proof took 
months on a "supercomputer".

Being the fussbudget I am, and remembering the date of the Scientific
Armenian article which described it, I decided a bit of research was
called for: Another article noted that the "supercomputer" was 
an IBM S/370/168. Ahah! False advertising from Big Blew strikes again!

I then went and looked up rough timings on said machine. Hard, because
the closest thing I have on hand is a System S/370 system summary
(GA22-7001-2)which gives the following information:

Mainstore 1meg-4 meg.
8k-16k Cache
80nsec clock(aka ~~12mhz)
Mainstore cycle time: 480 nsec
Storage access width: 8 bytes
Storage interleaving: 4-way 

4-way interleave gets effective mainstore cycle time down to 120nsec,
for housebroken programs.

This means that the "supercomputer" which solved the 4-color problem
was about on a par with high-end PC's of today, IF YOU IGNORE THE
I/O BANDWIDTH of the system.

Given that the 4-color theorem was not I/O intensive, this means that 
today's PCs could solve the same problem in a similar timeframe, a
mere 20 years or so later.


Robert Bernecky      rbe@yrloc.ipsa.reuter.com  bernecky@itrchq.itrc.on.ca 
Snake Island Research Inc  (416) 368-6944   FAX: (416) 360-4694 
18 Fifth Street, Ward's Island
Toronto, Ontario M5J 2B9 
Canada
From: moss@cs.umass.edu (Eliot Moss)
Newsgroups: comp.arch
Subject: Re: Looking for Trace Driven Simulator
Date: 28 Jul 92 21:39:05 GMT
Reply-To: moss@cs.umass.edu
Organization: Dept of Comp and Info Sci, Univ of Mass (Amherst)
In-reply-to: osborne@cs.tamu.edu's message of 27 Jul 92 17:40:07 GMT

Mark Hill has two tools, tycho and dineroIII, which simulate caches from
traces. One can evaluate a number of sizes and set associativities in one pass
through a trace; the other has fancier options (e.g., prefetching) that it can
model, but does one size/associativity per pass. You can reach Mark as
markhill@cs.wisc.edu. You need to collect/generate traces somehow to use these
tools.

David Wood as Wisconsin has a tool called CPROF, which profiles cache misses
and can help you find where you get the most misses. It runs from traces
generated by Jim Larus's QPT program. These work from MIPS and SPARC a.out
format files, though you could modify them to work for other instruction sets
(with some effort). Not all features are available for each machine yet. Both
of these products are licensed for a modest fee; if you are a poor professor
(like me), you can throw yourself on their mercy regarding the fee, but you
must still complete the license agreements. Their email addresses are
wood@cs.wisc.edu and larus@cs.wisc.edu. Larus is also the author of the spim
simulator for the MIPS instruction set; spim is freely available from him.
--

		J. Eliot B. Moss, Associate Professor
		Department of Computer Science
		Lederle Graduate Research Center
		University of Massachusetts
		Amherst, MA  01003
		(413) 545-4206, 545-1249 (fax); Moss@cs.umass.edu
From: bobp@hal.com (Bob Pendelton)
Newsgroups: comp.arch
Subject: Re: Graphics Systems
Date: 24 Jul 92 16:24:55 GMT
Organization: HaL Computer Systems, Inc.

From article <1992Jul23.182530.12006@dircon.co.uk>, by uad1077@dircon.co.uk (Ian Kemmish):
> rthomson@mesa.dsd.es.com (Rich Thomson) writes:
                    ^^
The es here stands for Evans&Sutherland the graphics computer company
start by Dave Evans and Ivan Sutherland.

> It seems time to remind people about that marvellous paper, ``The
> Computer Graphics Wheel of Re-incarnation'', that charted the
> history of people moving graphics in and out and in and out of
> special purpose h/ware (and it was written sometime around the end
> of the sixties!).  I *think* Ivan Sutherland was the author, but
> I wouldn't swear to it (*especially* on the net).

It was Ivan. And during the time I worked for E&S I heard the phrase,
"It's just another turn of the wheel" more times than I can count.

Seeing someone point this out to one of my old cohorts from E&S nearly
knocked me off my seat. (Hi Rich, how's it going?)

			Bob P.

-- 
Bob Pendleton             | As an engineer I hate to hear:
bobp@hal.com              |   1) You've earned an "I told you so."
Speaking only for myself. |   2) Our customers don't do that.
                   <<< Odin, after the well of Mimir. >>>
Newsgroups: comp.arch
From: kuttanna@ee.tamu.edu (Belliappa Kuttanna)
Subject: C Compiler for the RISC I or RISC II
Organization: Texas A&M University
Date: Wed, 29 Jul 1992 18:25:45 GMT

 
As the subject suggests, I am looking for a publicly
available compiler. Any help in this regard will be 
greatly appreciated.

Belliappa Kuttanna       kuttanna@ee.tamu.edu
Dept. of Electrical Engg.
Texas A&M University.

Newsgroups: comp.arch
From: peter@ferranti.com (Peter da Silva)
Subject: Re: Proposal: Computer History Project
Organization: Xenix Support, FICC
Date: Mon, 27 Jul 1992 13:45:43 GMT

In article <13297@ns-mx.uiowa.edu> jones@pyrite.cs.uiowa.edu (Douglas W. Jones,201H MLH,3193350740,3193382879) writes:
> My idea is to have
> the emulator present itself to the user through X-windows, for example,
> with a window that represents the front panel (complete with lights,
> switches, and the original manufacturer's distinctive graphic designs),
> and a second window representing the console teletype (or flexowriter,
> if you go back far enough on some machines).

Well, provide a dumb terminal interface as well. Some of us still have them,
and using them for this application is entirely in the spirit of the excersize.

I have original users manuals for the 4004 and 8008, if anyone actually gets
this going and needs the information.
-- 
Peter da Silva                                               `-_-'
$ EDIT/TECO LOVE                                              'U` 
%TECO-W-OLDJOKE Not war?                        Have you hugged your wolf today?
Ferranti Intl. Ctls. Corp.      Sugar Land, TX  77487-5012       +1 713 274 5180
Newsgroups: comp.arch,alt.folklore.computers,comp.benchmarks
From: lasner@watsun.cc.columbia.edu (Charles Lasner)
Subject: Re: dinosaur horsepower
Reply-To: lasner@watsun.cc.columbia.edu (Charles Lasner)
Organization: Columbia University
Date: Wed, 29 Jul 1992 17:06:36 GMT

In article <Bs5ME8.1p2@news.larc.nasa.gov> kludge@grissom.larc.nasa.gov ( Scott Dorsey) writes:
>In article <Bs5L03.3tH@exnet.co.uk> dhd@exnet.co.uk (Damon) writes:
>>In article <1992Jul28.155852.23608@sctc.com> smith@sctc.com (Rick Smith) writes:
>>>I was a fan of papertape myself. (5 points: can you spot the pun?)
>>
>>No, but I'm sure I'll burst out laughing when you list out the hole joke.
>
>What an uncultured chad.
>--scott

Yeah, don't you just want to punch him out and throw him into the chad box.

Let's fan-fold him or wind him onto a reel.

cjl
From: lindsay+@cs.cmu.edu (Donald Lindsay)
Newsgroups: comp.arch
Subject: Re: 1000 MHz
Keywords: decwrl BIPS-1
Date: 22 Jul 92 17:04:54 GMT
Article-I.D.: cs.1992Jul22.170454.139562
Organization: School of Computer Science, Carnegie Mellon

solman@athena.mit.edu (Jason W Solinsky) writes:
>|> DECWRL has the following project:
>|>  "BIPS-1"
>|>  1,000 MHz
>|>  8 KB first level onchip cache, bipolar, 1 ns
>|>  32 KB second level onchip cache, BiCMOS, 3 ns
>|>  130 watts
>
>I believe I was recently told that an ENTIRE one of those new IBM ES/9000
>uses around 1500 watts. I think that it would take some pretty smart
>engineering to make it economical to cool the little toaster.

Smart, yes, but the engineering is mostly in hand. DECWRL's tech
report 92/1 describes putting a 150 W ECL chip, with 348 signal pins,
into a socketed plastic package (a PPGA). Their estimate was that the
non-volume-production price of the packaging would be $300, counting
the price of the two 6 cm fans attached to the 12 cm cooling tower.
They claim it would operate (quietly) inside a standard desk-top box.

I'm not sure why people think that 130 watts would be hard to cool.
When there's only one such chip in a system, the only challenge is to
do it cheaply and compactly and quietly. When a machine contains
(say) 4 GB of ECL SRAM, then the heat isn't even in one place, and
there might be 10 KW or even 100 KW to dispose of - machine room
time.

From the mail of the last few days, a correction: the first level
cache is also BiCMOS. A true ECL design took too much silicon.





-- 
Don		D.C.Lindsay 	Carnegie Mellon Computer Science
Newsgroups: comp.arch
From: david@elroy.jpl.nasa.gov (David Robinson)
Subject: Re: Scheduling in Shared Memory Multiprocessor Systems
Organization: Image Analysis Systems Group, JPL
Date: Fri, 24 Jul 1992 18:32:13 GMT

In article <GLEW.92Jul23215649@pdx007.intel.com> glew@pdx007.intel.com (Andy Glew) writes:
>Gould PN machines used a simple affinity algorithm:
>    The run queue was divided into 32 priorities (each a single chain)
>    - the classic BSD run queue.
Isn't this an artifact of the Vax architecture having 32 hardware
queues and instructions to manipulate them?  Have most BSD vendors
kept this structure or gone with something radically different?

	-David
-- 
David Robinson	david@elroy.jpl.nasa.gov
Disclaimer: No one listens to me anyway!	'92 GS500E DoD #480
"An addiction is a drag" - Dennis Hopper	'90 EX250R Ninja
"A tisket, a tasket, a condom or a casket" - Dr. Carl Bell
Newsgroups: comp.arch
Subject: Re: BUSES
From: jpp@StarConn.com (John Pettitt)
Date: 28 Jul 92 18:05:37 GMT
Organization: Starnet-Public Access UNIX--Los Altos, CA  415-949-3133

keith@ksmith.uucp (Keith Smith) writes:
>Is it not also true however, that the current disk devices can't even
>swamp an ISA bus?  The average desktop doesn't have multiple striped
>disks and whatnot.

>Even the new crop cannot swamp an EISA bus.  Video may soon go another
>route, we will see.  Memory is already localized, as part of the CPU on
>most products, with a SIMM pinout becomming a local memory bus of sorts.

Not true - on a 486 multi processor system running UNIX (an extreme
example I will admit) bus bandwidth for disk, network and serial I/O is
a major concern.   

On a more normal level an ISA bus will peak out at around 3.3 MB a
second half duplex (600 ns per transaction 2 bytes per).  In the real
world where things don't run 0 wait and you have to do read modify write
transactions on byte registers things slow way down and just over 1Mb /
second is about all you get without using bus mastering.

EISA is a better proposition but even their the 33 MB/sec theorectical
max is not attainable on any system I know of.  ~10Mb sec is more
normal.    

In paractice the pure data rate is often not the issue - you don't want
to more more than a 2 megs a scond on a PC that often.  However as most
PC's either don't have write buffers or have at most 4 levels of
buffering the main x86 CPU is held in wait state while the bus
transaction finishes.  This significantly impacts performance.   For
example a 486/25 Micro Channel system (ALR in this case) running 128
serial ports at 38.4K baud (~5 mbits /sec) takes a 60% of the CPU.  If
you look further into this of that 60% some 2 thirds (40% of real time)
is spent waiting for the bus to finish a transaction.   Whilst in the
real world people don't run all terminals at 38.4 100% duty you can see
that bus speed does make a difference.  N.B. these numbers are from a
real live set of tests done during the design of a fault tolerant I/O
solution. 

So waht to do about it.  Well fistly keep things in balance - EISA is
fine for most PC applications.   Beyond that more write buffering or a
separate I/O controller with high speed access to memory and it's own
EISA or ISA bus may be the way to go (similar to the channel controller
concept in mainframe systems).

Regards

John Pettitt  I/O system designer (retired :-)

-- 
John Pettitt					jpp@starconn.com
Archer N81034					apple!starnet!jpp
Me, say that, never: It's a forged posting!	Fax: +1 415 949 2037
From: ivie@cc.usu.edu (CP/M lives!)
Newsgroups: comp.arch
Subject: Re: MVC and MVCL (was Re: RISC Mainframe)
Date: 30 Jul 92 10:04:40 MDT
Organization: Utah State University

In article <e7w0026N1bbP01@JUTS.ccc.amdahl.com>, haw30@macaw.ccc.amdahl.com (Henry A Worth) writes:
> In article <1992Jul24.190506.6168@PA.dec.com> ed@pa.dec.com writes:
>> > And since most of the code is written in assembly language to begin
>> > with, compiler optimizations are moot.
>> 
>> I don't think this necessarily follows.  For example, one of the compiled
>> languages for Alpha is Macro-32, i.e., VAX Assembly.  It's unusual to think
>> of what started out as an assembly language to be run through a compiler,
>> but there's nothing magic about it.
>> 
> 
>    Except that a lot of old assembly code dates from an age when being	
> self-modifing was a virtue... 

I think self-modifying code is rare on a VAX. The closes that I've ever
come to doing it is having the header of my device driver patch the 
JSB instruction in the IDB to save the registers that _I_ wanted it to
save.

Roger Ivie
ivie@cc.usu.edu