HDTenEightyP/NetNews huggingface dataset:
From: solman@athena.mit.edu (Jason W Solinsky)
Subject: Re: Superscalar vs. multiple CPUs ?
Organization: Massachusetts Institute of Technology
Date: Wed, 23 Dec 1992 02:54:03 GMT

In article <2121@coyote.UUCP>, shoens@rufus.almaden.ibm.com writes:
|> Jason Solinsky  ...
|> 
|> > In how many of these examples are we actually concerned with processor
|> > performance?  In editors and word processors we certainly aren't ...
|> > In the case of a database, I would not expect it to be processor limited.
|> 
|> As you have more cycles to fool with you get to put more function in,
|> of course.  So where I previously edited nroff source with ed, I now
|> use a system like Framemaker with X-windows.  Database systems are
|> typically CPU bound because disks have been slow forever, so the problem
|> of disk parallelism has already been tackled.  Besides, if you analyze
|> the popular transaction benchmarks you can see that the disk bandwidth
|> required is relatively small, assuming reasonably-sized buffer pools.
|> For complex queries, there's even more processing to do and more opportunity
|> for smart data placement on disk and sequential prefetch.

Several people wrote me concerning the fact that their word processors and
editors do this, that, and the other thing. HOWEVER, in all of those cases and
apparently in the two examples mentioned above, there exists a huge (or at the
very least presently underutilized) degree of parallelism. When you have an
idle CPU there will always be additional things that software people would
like to run on it, but the practical examples are OVERWHELMINGLY
under-parallelized in their present day incarnations.

This is certainly true of a CPU running an editor while updating several macros
within the editor and then running several tasks in the background. It is again
true of most database programs which will typically be very parallelizable
at the higher levels of examination.

What I am trying to say is that when a task which has been non-cpu bound, is
modified such that it becomes cpu-bound, the modifications invloved are
typically excellent candidates for parallelization. Thus it still holds that
"general purpose" computing can support the degree of parallelization available
to a deep pipelined "hyperscalar" uP.

Jason W. Solinsky
From: tim@Apple.COM (Tim Olson)
Newsgroups: comp.arch
Subject: Re: Alpha and Super-pipelining
Date: 31 Dec 92 00:01:14 GMT
Organization: Apple Computer Inc, Cupertino, CA

In article <1992Dec30.175717.15249@dcc.uchile.cl> pchris@dcc.uchile.cl writes:

|After reading the material available about the Alpha, I noticed that it was
|mentioned a few times that the first implementation of the Alpha, the 21064,
|is *super-pipelined* as well as superscalar.
|
|After reading the Data Sheet of the 21064, I find nothing that seems to
|indicate the 21064 is super-pipelined, at least in terms of the common
|definition of super-pipelined.  Is DEC redefining the word "super-pipeline"?
|Anybody out there that can explain?

I believe some "simple" ALU instructions, such as shift, issue at a
single-cycle rate, but have a 2-cycle latency.

-- 
	-- Tim Olson
	Apple Computer Inc. / Somerset
	(tim@apple.com)
From: YOUNG@tattoo.cs.widener.edu (Rob Young)
Newsgroups: comp.arch
Subject: Re: Def of a workstation (a lark)
Date: 4 Jan 93 02:20:24 GMT
Organization: Widener News/Mail Gateway
NNTP-Posting-Host: tattoo.cs.widener.edu
X-News-Reader: VMS NEWS 1.20


In <WAYNE.93Jan3184216@backbone.uucp>
   wayne@backbone (Wayne Schlitt) writes:

>This is almost certain to cause a long string of definitions, and
>quite possible a flame war or two.
	yeah

>* A workstation must run UNIX
>  This is a favorite of the unix bigots.  Of course, one of the
>  founders of the workstation field was apollo and they didn't run unix.

	This one is more than a little puzzling.  VMS workstations don't
	count?   Sort of like a men's club?  What if it comes with a POSIX
	shell?  Still doesn't count?  What a drag. . .

>* Workstations must be multi-user
>  Well, this is kind of part of being on a network.  A lot of what
>  goes into Novell is adding multi-user functions to DOS.  This also
>  makes OS/2 and WNT questionable.  (That may be why I have heard it
                                                  ^^^
>  used as a requirement recently :-)
          ^^^^^^^^^^^^^^^^^^^^^^^
	Exactly.


	Earlier you wrote:

>What definition there is, has been defined more by the marking folks
>than by anyone else.  There have been long discussions about what the
>There have been long discussions about what the difference between a mainframe
>and a minicomputer and a microcomputer are.  What separates a PC from a
>workstation is much less well defined.

I agree with wayne's assertion that it is a marketing thing.  Leads me to the
question:  If you have a *PC* that outperforms most workstations (and also
can run Unix and jump through all your hoops above), does that make it a 
workstation?  Couldn't a company call something a PC when it is really a 
workstation in PC clothing?  Will DEC have a marketing *hammer* that says in 
essense:

             "Our PC outperforms most/all of your workstations."

		Don't forget to date your checks correctly,

				Rob


                                                     young@tattoo.cs.widener.edu
"Even the street fighters over at Sun are concerned when they look at what's
happening with Windows.  They see the way the market works: The users are a
bunch of sheep, and Billy [Gates, Microsoft CEO] is the shepherd"
						-- Maureen O'Gara
						   Unigram-X editor
Newsgroups: comp.arch
Subject: Re: question about DMA devices
From: don@zl2tnm.gen.nz (Don Stokes)
Date: 24 Dec 92 01:37:25 GMT
Distribution: world
Organization: The Wolery

jan@pallas.neuroinformatik.ruhr-uni-bochum.de (Jan Vorbrueggen) writes:
> A number of smaller Vaxen (only the uVaxI? or also the 725/730?) didn't have
> these and in general had to do I/O a page at a time...probably still slightly
> faster than a PC/XT :).

The MicroVAX I addressed memory on the Qbus, in the same way it addressed
peripherals.  DMA is no different on these systems, except that there is no
need for mapping registers because the memory is in the same address space
as the peripheral and can be addressed directly.  I'm not sure about the 
11/730, but there's nothing special about the I/O adapters -- bog standard
Unibus devices that presumably have some sort of map into memory.

--
Don Stokes, ZL2TNM (DS555)                        don@zl2tnm.gen.nz (home)
Network Manager, Computing Services Centre            don@vuw.ac.nz (work)
Victoria University of Wellington, New Zealand              +64-4-495-5052
From: lazzaro@boom.CS.Berkeley.EDU (John Lazzaro)
Newsgroups: comp.arch
Subject: Re: multiuser systems (was Re: IBM AS/400 is the world's slowest..)
Date: 2 Jan 1993 19:36:15 GMT
Organization: University of California, Berkeley
NNTP-Posting-Host: boom.cs.berkeley.edu

In article <16189@auspex-gw.auspex.com> guy@Auspex.COM (Guy Harris) writes:
>
>I suspect the people who suffered timeshared systems back then suffered
>from having a timesharing system capable of supporting N people
>comfortably, but having M > N (perhaps M >> N) people using it
>regularly.
>

In a workstation evironment, you can't grow N without growing CPU
resources at the same time; in a multi-user environment, the variables
are under separate control.  In some sense, a workstation evironment
is inherently more resistant to political problems than a multi-user
environment, at least as far as CPU, core, and swap space are
concerned; network bandwidth is the only political pressure point.
Technology is easier to deal with than politics for many
organizations, so choosing the technology that minimizes political
problems is a big organizational win.





Newsgroups: comp.arch
From: peter@ferranti.com (peter da silva)
Subject: Re: Any new instructions in a i486?
Organization: Xenix Support, FICC
Date: Mon, 21 Dec 1992 23:43:50 GMT

In article <BzMEIJ.Anz@pix.com> stripes@pix.com (Josh Osborne) writes:
> I don't think this is the case (but I would love to be wrong...).  I beleve
> the #clocks each insn takes is more like the 386, then the i486.

If NeXTstep does busyloops using instruction timing, I don't want it no
matter WHAT it looks like.
-- 
Peter da Silva                                            `-_-'
Ferranti International Controls Corporation                'U` 
Sugar Land, TX  77487-5012 USA
+1 713 274 5180                            "Zure otsoa besarkatu al duzu gaur?"
From: supnik@human.enet.dec.com (Bob Supnik)
Newsgroups: comp.arch
Subject: Re: uniprocessor design ceiling
Summary: Trend can continue for w while
Keywords: microprocessor, evolution, performance
Date: 26 Dec 92 19:22:05 GMT
Organization: Digital Equipment Corporation


In article <1gbpjrINNsq6@girtab.usc.edu>, plaw@usc.edu (Patrick Law) writes...
>Correct me if I am wrong. For the last 20 years, we have 4-bit 
>microprocessor, CISC, cache, RISC, superscalar, superpipeline,
>etc. Have we reached a point of diminishing return in uniprocessor
>design? Could we still get a speedup of "X" every "N" years like
>before? <text deleted>

Since the mid-70's, microprocessors have exhibited performance growth of
roughly 50% per year, within a given base architecture type (eg, CISC
processors, RISC processors, superscalar RISC processors).  Since circuit
speed has not improved as much (roughly 30% every process generation),
the balance has come by improved design and microarchitecture.  An example
from VAX history:

chip	year	process	cycle	rel	comments
				perf

MicroVAX 1985	3u	200ns	1X	No pipeline within microcycle

CVAX	1987	2u	 80ns	3X	'Half folded' pipeline within
					microcycle (ie, register writes
					overlapped with reads), onchip cache

CVAX+	1988	1.5u	 60ns	4X	Straight shrink

Rigel	1989	1.5u	 28ns	8X	'Fully folded' pipeline within
					microcycle (register read/ALU/register
					write overlapped, like classic RISC)

Mariah	1990	1.0u	 16ns	14X	Straight shrink + circuit tweaks

NVAX	1992	 .75u	 12ns	32X	Overlapped macropipeline -> lower cpi

In RISC, a comparable timeline would show the five stage pipe 'classic RISC'
employing more finely divided pipelines (for faster clock rates) and/or
multiple instruction issue, as well as improvements in memory hierarchy.

The ingenuity of processor designers (and semiconductor technologists) being
far from exhausted, I believe this performance growth can continue for the
rest of this decade.  There are some limiting factors:

- Process technology evolution appears to be slowing somewhat, due to
  lengthening development time (and cost) for new generations of semiconductor
  processing equipment.

- Increases in performance have been accompanied by increases in power
  consumption, in opposition to rising requirements for 'green' technology.

The shape of microprocessors in the year 2000 is the subject of a panel
discussion at the ISSCC conference, February 93.

Finally, the ability to continue improving uniprocessor performance does
negate the importance of cracking the programming problems on MIMD's and
other collectives.  An MPP could provide one to three orders of magnitude
more computing power.  Indeed, if the underlying microprocessors continue
to improve, so will the MPP.

Bob Supnik	>Supnik@human.enet.dec.com
		>All opinions expressed are those of a hardline microcoder
		>and do not reflect those of Digital Equipment Corporation
From: wlw@hpfcso.FC.HP.COM (Will Walker)
Date: Mon, 21 Dec 1992 19:54:57 GMT
Subject: Re: Alpha Architecture Quirks
Organization: Hewlett-Packard, Fort Collins, CO, USA
Newsgroups: comp.arch

In comp.arch, jfc@grouse.dsg.dec.com (John F Carr) writes:

> In article <1992Dec14.072942.21962@doug.cae.wisc.edu>
> 	keiths@cae.wisc.edu (Keith Scidmore) writes:
> 
> >1)  I read that the 21064 divide unit is not pipelined and takes one cycle 
> >    per bit to produce a result.  Isn't this going to kill floating point
> >    performance? [...] I'm
> >    lead to think that DEC isn't interested in the FP performance of this chip,
> >    or do I have my facts wrong?
> 
> A double precision floating point divide is slow, but look at the benchmark
> results: the Alpha AXP 10000 is rated at 200 SPECfp92.  If you buy the
> low-end model you get 112 SPECfp92.  Obviously divide performance isn't
> critical to this large selection of real-world applications.

Quite right, SPECfp92 is not very sensitive to divide or square root
latency.  Which applications are?  Possibly 3D graphics.  Perhaps Mr.
Scidmore's applications are sensitive to divide latency since he
brought it up?  I don't know.

> In any case, considering the clock speed difference between Alpha AXP and
> competitive systems you are better off counting nanoseconds instead of
  ^^^^^^^^^^^^^^^^^^^

  That's right, you should compare latencies in nanoseconds, not cycles.
  I'll add an HP machine to your table.

> 			DEC Alpha AXP			IBM RS 6000
> 		 	133 Mhz	150 Mhz		 	41 Mhz	62.5 Mhz
> 			cycles	ns	ns		cycles	ns	ns
> FP mult or add	 6	 45	 40		 2	 48	 32
> FP divide		63	473	420		20	480	320

  			   HP 735
			   100 MHz
			cycles	ns
  FP mult or add	 2	 20
  FP divide		15	150


- Will Walker
  my own opinions
From: lindsay+@cs.cmu.edu (Donald Lindsay)
Newsgroups: comp.arch
Subject: Re: IBM AS/400 is the world's slowest computer
Date: 31 Dec 92 20:08:58 GMT
Organization: School of Computer Science, Carnegie Mellon


keith@ksmith.uucp (Keith Smith) writes:
>I was under the assumption that the machine model
>of the AS/400 is that everything you scribble on or read from lies
>somewhere on the terabyte or so of address space in the machine.  This
>seems really stupid to me.  Basically then by hiding the hardware in an
>address you would *HAVE* to check the memory references for capability,
>where if you just treated devices differently from the start you can
>avoid this.  

Mapping a file into memory is (to the programmer) like having the
"open" read the entire file into memory. [Modulo issues such as
multiple users opening the file.] This allows a different style of
programming - and  sometimes the style is a better one. That's the
user-level win.

>In fact you avoid 2 layers, the one at the OS level where
>you translate the Device work into a memory reference, and then at the
>microcode level where it gets translated *BACK* to some device
>operation.

Layering can be even worse that that. The file system may use trees
[more generally, "access structures"] to find the pieces of the file
on disk. The virtual memory support uses access structures to map
between file-system-relative locations and addresses. And, a data
base manager or transaction manager does bookkeeping concerning its
pattern of file-relative reads and writes. If these layers ignore
each other, it's possible to get some considerable overheads,
relative to a more integrated product.

[A data base designer tells the story of a user who tried to build a
200 MB data base, and asked why he needed 400 MB free to make it
work.  It turned out that the initialization wasn't special cased,
and was writing all those "new" zeroes into shadow pages, which were
later "committed". The point being that actual usages don't always
match the model the designers worked to.]

-- 
Don		D.C.Lindsay	Carnegie Mellon Computer Science
Newsgroups: comp.arch
From: stripes@pix.com (Josh Osborne)
Subject: Re: Any new instructions in a i486?
Organization: Pix Technologies -- The company with no adult supervision
Date: Tue, 22 Dec 1992 02:16:09 GMT

In article <WAYNE.92Dec21153140@backbone.uucp> wayne@backbone.uucp (Wayne Schlitt) writes:
[...I wrote I think the cy486 is slower, but I would like to be wrong...]
[...]
>< Intel 486SX:      [...]
><                  Instructions that can be executed in 1 clock cycle if the
><                  destination is a register and the source is either a register
><                  or an immediate value:
><                  ADC,ADD,AND,BSWAP,CMP,DEC,INC,MOV,NEG,NOT,OR,POP,PUSH,SBB,
><                  SUB,TEST,XOR
>< 
>< Cyrix 486DLC       [...]
><                  Instructions that can be executed in 1 clock cycle
><                  if the destination is a register and the source is
><                  either a register or an immediate value:
><                  ADC,ADD,AND,CDQ,CLC,CLD,CMC,CMP,CWD,DEC,INC,MOV,MOVSX,
><                  NEG, NOT,OR,SBB,SHLD,SHRD,STC,STD,SUB,TEST,XOR
>
>So, for most instructructions that the Intel 486 executes in 1 cycle,
>the cyrix 486 does also.  There are some things that take longer,
>there are some things that take less time.

Most impressave.  Ok, I'm enjoying being wrong.  That's what I get for
beleving things I read in Computer Shopper...

>I haven't seen any SPEC*92 info on the Cyrix, but it is my
>understanding that they are about 10% slower than intel's parts at the
>same clock speed.

But most likely quite a bit faster at the same price :-)
-- 
           stripes@pix.com              "Security for Unix is like
      Josh_Osborne@Real_World,The          Multitasking for MS-DOS"
      "The dyslexic porgramer"                  - Kevin Lockwood
We all agree on the necessity of compromise.  We just can't agree on
when it's necessary to compromise.       - Larry Wall
Xref: sparky comp.arch:11848 comp.sys.dec:6585 comp.sys.sgi:18259 comp.sys.hp:14298
From: gezelter@rlgsc.com
Newsgroups: comp.arch,comp.sys.dec,comp.sys.sgi,comp.sys.hp
Subject: Re: Comparison of Alpha, MIPS and PA-RISC-II wanted
Date: 21 Dec 92 15:34:32 GMT
Organization: Robert Gezelter Software Consultant, Flushing, NY

In article <BzKGKB.2Bp@pix.com>, stripes@pix.com (Josh Osborne) writes:
> The we need a way for user level code to tell the OS what file info is
> important to cache, and what isn't.  Then you can be almost as efficent
> as VMS/RMS (you will have extra context switch overhead for the extra
> syscalls), but you will still be able to allow any user to create new
> filetypes.
> -- 
>            stripes@pix.com              "Security for Unix is like
>       Josh_Osborne@Real_World,The          Multitasking for MS-DOS"
>       "The dyslexic porgramer"                  - Kevin Lockwood
> We all agree on the necessity of compromise.  We just can't agree on
> when it's necessary to compromise.       - Larry Wall
-- 
Josh,
 
Important point that you bring up tangentially in your post. 
While VMS does provide RMS as an operating system service, there 
is nothing which prevents you from "folling your own" type of 
file structure. However, every program which wants to read from 
your special file structure will have to be intimately familiar 
with it. Programs which use RMS can process files which were 
created using RMS with no problems.
 
A misnote about the HSC which appeared in this thread. The HSC 
does not really know anything about the content of the disk 
files. However, RMS will do things inside of the CPU, such as 
maintain index caches on a system wide basis, which are a 
signifigant performance improvement. One problem with rolling 
yourself is that, invariably, the management and monitoring tools 
and utilities are bare-bones.
 
- Bob
+--------------------------------------------------------------------------+
| Robert "Bob" Gezelter                       E-Mail:  gezelter@rlgsc.com  |
| Robert Gezelter Software Consultant         Voice:   +1 718 463 1079     |
| 35-20 167th Street, Suite 215               Fax:       (on Request)      |
| Flushing, New York  11358-1731                                           |
| United States of America                                                 |
+--------------------------------------------------------------------------+
From: dswartz@sw.stratus.com (Dan Swartzendruber)
Newsgroups: comp.arch
Subject: Re: branch-and-link
Date: 28 Dec 1992 04:49:40 GMT
Organization: Stratus Computer, Inc.
Distribution: world
NNTP-Posting-Host: redondo.sw.stratus.com

On a related note (vis-a-vis debugging ease) to the branch-and-link issue, another peeve
I've always had is that no commercially available processors (that I know of) make NULL
pointer detection easy withou serious run-time overhead.  Various OS's try by unmapping
the first N pages of memory, which works fine until you run into a chip like the 68030,
which supports huge displacements.  Not to mention if the index register pushes the
effective address out of your protected window, you're hosed.  If you have a standard
base_reg+index_reg+disp format, it would seem to me that having the processor check the
base register for NULL and faulting if it is wouldn't be that hard (or inefficient).
Especially if NULL happens to be zero on that machine.

-- 

#include <std_disclaimer.h>

Dan S.
From: lindsay+@cs.cmu.edu (Donald Lindsay)
Newsgroups: comp.arch
Subject: Re: COMPAQ PROPOSED SCALABLE I/O ARCHITECTURE
Date: 22 Dec 92 21:58:00 GMT
Article-I.D.: cs.BzoL0q.3zr.2
Organization: School of Computer Science, Carnegie Mellon


ajc@pa.dec.com (AJ Casamento) writes:
>  I guess I not as upset by the concept of using an ASIC. Of course, I'm not
>talking about respinning a full custom ASIC for each new design either.

I would expect that the ASICs could become cheap, and would have a lot
in common internally.

However, ASICs have a lead time. If Compaq is serious about spreading
this as a standard, then they should make available a
common-denominator design based on common parts, or on FPGAs.
Something that lets people get their feet wet, at the very least.

-- 
Don		D.C.Lindsay	Carnegie Mellon Computer Science
Newsgroups: comp.arch
From: zrepachol@cc.curtin.edu.au
Subject: Re: Any use for Branch if Even/Odd ?
Organization: Curtin University of Technology
Date: Mon, 28 Dec 1992 12:19:34 GMT

In article <GJR.92Dec11230751@chamarti.ai.mit.edu>, gjr@zurich.ai.mit.edu (Guillermo J. Rozas) writes:
...
> The alpha has those too, but that is not the issue.  If I remember
> correctly, all odd integer values were considered true in BLISS, and
> all even values false.  Using test-for-zero for boolean tests only
> works if zero is the unique representation for one of the boolean
> values (as in C), but this is neither inherent nor clearly superior.

Close, but you have fallen into the hole that the BLISS spec trys to avoid.
The value of the fullword is irrelevent, only the low bit counts. Its value as
an int or float or char is irrelevent to the true/false test. Note that the
odd/even true/false mapping fails with floats or scaled quantities.

~Paul
From: lindsay+@cs.cmu.edu (Donald Lindsay)
Newsgroups: comp.arch
Subject: Re: reentrant
Summary: more than that
Date: 3 Jan 93 02:01:21 GMT
Organization: School of Computer Science, Carnegie Mellon

john@iastate.edu (John Hascall) writes:
>}>The OS world is moving towards multithreading...
>But as far as (popular) commercially available OSes, it would seem not:
     [list omitted]
>    UNIX:  not yet

One can easily multithread programs on lots of "Unix" machines:
Crays, Intel Paragon, KSR/1, Alpha, SPARCstation, Sequent, and so on.
On some of these machines, the vendor rather expects you to do this
(notably, the multiprocessor vendors). On other machines, it is
achieved by using a "threads package" that papers over some
infelicity or other.

Yes, there used to be Unixi where a thread package couldn't be done
properly - as the Ada pioneers found out. [No way to overlap
execution and I/O, for instance.] But Sun has moved towards
threading, and now there's a Posix threads-package standard, so I
felt safe in claiming a trend.

I'd ask Robert how old the idea is, but since it's certainly older
than much of the audience, I'll refrain. 
-- 
Don		D.C.Lindsay	Carnegie Mellon Computer Science