HDTenEightyP/NetNews huggingface dataset:
From: ivie@cc.usu.edu (CP/M lives!)
Newsgroups: comp.arch
Subject: Re: Graphics Systems
Date: 27 Jul 92 17:02:17 GMT
Organization: Utah State University

In article <1992Jul24.164933.11591@hal.com>, lindzey@hal.com (Gardner Lindzey) writes:
>>
>>Where will it END?
>>Where WILL it end?
>>
> CPU->Monitor

It's been done. Ever here of the Williams Tube?

Roger Ivie
ivie@cc.usu.edu
From: vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
Newsgroups: comp.arch
Subject: Re: bcopy (was Re: CISC Microcode)
Date: 25 Jul 92 18:50:06 GMT
Organization: Silicon Graphics, Inc.  Mountain View, CA

In article <l71bboINN4en@exodus.Eng.Sun.COM>, narad@nonsequitur.Eng.Sun.COM (Chuck Narad) writes:
> ...
> This can also be used to bfill/bzero pages efficiently.  This allows us
> to accelerate relatively- aligned copies in kernel space, which covers
> many of the interesting cases including page copy, copy-on-write,
> networking buffers, etc....


> ....The answer is that sometimes you want the data now, and sometimes 
>you don't.  For example, moving data through several layers of network protocol
> stacks,...


Ha!  Finally I get not one but two openings for my $0.02.

The Right way to fix network bcopy()'s is to not do them.
In a wrong system, bcopy() and the consequent cache hassles dominated.
In a right system, TCP or UDP user data goes from the wire to main RAM
to disk or video or the reverse without ever seeing the CPU.

The common network benchmarks I know of do not examine the data on the
receiving end nor change it on the transmitting end.  This means that a
Right system can go a lot faster on those benchmarks.  yes, that is
one reason why we get several dozen Mbit/sec out of FDDI than some
other guys.


Instead of getting a headache pill because hitting your head with a
hammer hurts, "don't do that."



Vernon Schryver,  vjs@sgi.com
Newsgroups: comp.arch
From: rthomson@mesa.dsd.es.com (Rich Thomson)
Subject: Re: Graphics Systems
Reply-To: rthomson@dsd.es.com (Rich Thomson)
Organization: Design Systems Division, Evans & Sutherland, SLC, UT
Date: Thu, 23 Jul 92 00:00:14 GMT

In article <4398@rosie.NeXT.COM>
	pgraff@next.com (Peter Graffagnino) writes:
>Actually, we have no such coprocessor, all compositing (blitting) is done  
>with the host CPU.  Our model is to have a high-bandwidth memory subsystem  
>where VRAM and DRAM are peers with the same performance characteristics.   
>Since NeXTSTEP tends to draw in window backing stores (DRAM) just as  
>frequently (if not more) than VRAM, its hard to see how a graphics  
>accelerator can help (unless it has its own DRAM/VRAM virtual memory  
>subsystem with a CPU/MMU (ala NeXTdimension)).  With this CPU-centric  
>graphics architecture, your graphics performance rides the same (steep)  
>curve as your general CPU performance -- customers like it when  
>*everything* gets faster when they upgrade to a faster CPU.

Of course, everything is also as slow as the CPU.  Isn't this the kind
of system that caused people to create graphics accelerators in the
first place (i.e. the central CPU was the bottleneck)?  What does NeXT
plan to do when people's thirst for graphics rendering increases?
Now that NeXT will be supporting 3D applications with NeXT Step 3.0
with "quick renderman", they may find that relying on the CPU will not
get them the performance needed to render many thousands of polygons
interactively.  On the other hand, NeXT may not consider these kinds
of 3D apps to be their market.

							-- Rich

PS: how can I obtain a specification of "quick renderman"?  Calls to
    Pixar routed me to the NeXT tech. support line which would only tell
    me that they will be offering a "3d kit" in release 3.0.
-- 
	Repeal the personal income tax; vote Libertarian in 1992.
Disclaimer: I speak for myself, except as noted; Copyright 1992 Rich Thomson
UUCP: ...!uunet!dsd.es.com!rthomson			Rich Thomson
Internet: rthomson@dsd.es.com	IRC: _Rich_		PEXt Programmer
Xref: sparky comp.arch:8497 alt.folklore.computers:11638 comp.benchmarks:1227
From: smith@sctc.com (Rick Smith)
Newsgroups: comp.arch,alt.folklore.computers,comp.benchmarks
Subject: dinosaur horsepower - Numbers
Date: 31 Jul 92 19:34:20 GMT
Organization: SCTC


These are excerpted from tables originally published in Vol. 10, #4 of
the Annals of the History of Computing (1989). Both tables are sorted
by add speed. In all cases, machines with "average" add speeds are the
ones that use some form of rotating memory.

Some Early Prototype-like Dinos:

Name		Add Speed (microsecs)	Storage (total bits)

Whirlwind	40			 32,768
Binac		800			 15,872
Seac		850 (average)		 23,040
Manchester #1	1200			 10,240
Edsac		1500			 18,432
ERA 1101	8500 (average)		393,216


Some Commercial Dinos, big and small:

Name		Add Speed (microsecs)	   Cost
IBM 7090	4			$3,630,000
PDP 1		5			$  110,000
IBM 704		24			$1,994,000
IBM 709		24			$2,630,000
IBM 650		2736 (average)		$  250,000
Librascp LGP 30 5500 (average)		$   55,860
Bendix G-15	7520 (average)		$   77,300

Most of these were introduced in the mid to late '50s, except the
first two which appeared in the early '60s.

Rick.
smith@sctc.com      arden hills, minnesota
Newsgroups: comp.arch,alt.folklore.computers,comp.benchmarks
From: smith@sctc.com (Rick Smith)
Subject: Re: dinosaur horsepower
Organization: SCTC
Date: Tue, 28 Jul 1992 15:58:52 GMT

sysmark@helios.physics.utoronto.ca (Mark Bartelt) writes:

>... 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 put together a few tables of such data for "favorite" machines a
few years back and I'll try to post them.

>But, in general, I think it would be fun to see MIPS/MFlops (KIPS/KFlops?
>IPS/Flops?) values (at least, moderately authoritative ballpark estimates)
>for some of the machines we grew up with.

Most speed info from the Good Old Days simply reported how long it took
to do an Add and maybe a Multiply. On particularly weird machines
(i.e. those with drums instead of RAM) these were sometimes reported
as min, max, and average speeds.

The classic source is Weik's Survey, which I think was last updated
in 1961 for the Aberdeen Proving Grounds.

>By the way, if the history project does succeed in emulating some of the
>older machines, will it also provide an emulator for an 026 keypunch? ;-)

I was a fan of papertape myself. (5 points: can you spot the pun?)

Rick.
smith@sctc.com        arden hills, minnesota
Newsgroups: comp.arch
From: henry@zoo.toronto.edu (Henry Spencer)
Subject: Re: CISC Microcode (was Re: RISC Mainframe)
Date: Thu, 23 Jul 1992 17:42:13 GMT
Organization: U of Toronto Zoology

In article <2369@nic.cerf.net> davsmith@nic.cerf.net (David Smith) writes:
>All CPUs I have seen to date (not every CPU by any means - if you know
>of counter examples, please post) cannot do asynchronous address
>generation.  When they request a word of memory they want it *NOW* or
>within a cycle or two and will block until it arrives...

Uh, you are very much behind the times.  Few modern CPUs will block waiting
for a memory access unless/until they actually need the data.  Admittedly,
a lot of them can't initiate another memory access meanwhile -- or at
least, another data access -- but some can, and buses that support multiple
simultaneous memory transactions are old news.  The SBI bus on the VAX 780
could do this, for example.

Moving back to the global issue, it's trivially obvious that you can always
build a memory system that a given CPU can't use fully, just by stacking up
more and more parallelism in the memory.  But next year's CPU will go a
long way toward catching up with your memory, and parallelism is expensive.
You don't normally spend lots of money just to justify a pre-established
decision to include a DMA box.  You buy memory bandwidth to meet your needs.
My contention is that making all of it available to your CPU, and choosing
a CPU that can use all of it, tends to leave no room for a DMA box to be
cost-effective... unless you've got response-time constraints (my item 3)
that the CPU can't conveniently meet.

>Caches on interleaved memory systems can do pre-fetching, however there
>is a trade-off that must be made between pre-fetching too little and
>too much.  Caches tend to fetch in blocks so the start-up latency is
>spread across a number of words, but the size of the block must be
>large to make the latency cost trivial.  There are a number of problems
>with fetching large blocks.  Thus, it is difficult to get full bandwidth
>out of an interleaved memory system while going through the cache.

No, it is difficult to get full bandwidth out of an interleaved memory
system while going through an *uninformed* cache.  There is no reason
the cache can't vary its fetch size depending on the requirement.
Fetching too much is not an issue if you know how much you'll want
and can communicate this to the cache.  Simply telling it "normal" or
"bulk transfer" ought to be adequate.
-- 
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
Newsgroups: comp.arch
From: glew@pdx007.intel.com (Andy Glew)
Subject: Re: Request Info Re Bus Trends & Intel 486s
Organization: Intel Corp., Hillsboro, Oregon
	<GLEW.92Jul23192755@pdx007.intel.com>
	<1992Jul25.053124.14505@e2big.mko.dec.com>
Date: Mon, 27 Jul 1992 04:08:41 GMT

    |>[Burkhard Neidecker-Lutz]
    |>Can you explain which *desktop* applications need peer-to-peer communication ?
    |>I.e. what is wrong with going through main memory ?
    |>>
    |>>[John Theus]
    |>>To use today's favorite buzz word: multimedia.
    |>>
    |>[Andy Glew]
    |>First you'll put video on your screen.
    |>
    |>Then you'll want special effects: things like zooming in on a
    |>particular speaker (or the papers on his desk) in a video conference,
    |>things like cropping speakers from different video inputs and
    |>superimposing them into a virtual conference room.

    I assume from the tone of his note that Andy is arguing for peer to peer...

Not really.

Peer to peer has a performance advantage (if it can be achieved).

But if you want to do more processing than either of your peers can
handle, you'll want to go to the CPU.

So I'll take my typical waffling stance:

(1) I will never base a computer system architecture [*] on the assumption
    that peer-to-peer communication for things like video is the only
    important thing.

(2) I will try to optimize communication involving the CPU as much as
    possible.

(3) I will also try not to *prevent* peer-to-peer communication from
    being used.

[*] Not if the architecture is intended to stay up for several years.
    If it is a purely one-shot deal, I guess that the thing to do
    is to look at the technology wheel and try for the optimal solution
    projected for your delivery date.  But the wheel turns at a rate
    that approaches 1 turn/2 years (with major cycles of 1/8),
    so if your design is going to be on the market that long plan for both.

It is wise to avoid self-fulfilling prophecies.  E.g. if you cripple
your CPU by not providing the mechanisms to do fast bcopy, because you
are assuming that extrernal hardware can always do it better, you have
stuck yourself in a hole that it will be difficult to get out of when
the technology wheel turns.  Conversely, if you don't put the features
to do good peer-to-peer without CPU intervention in your bus, then you
won't be able to get the performance boost it provides.

Best of both worlds?: TANSTAAFL. Emphasize the aspects that will be
most important during your critical market window.  
--

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: mash@mips.com (John Mashey)
Newsgroups: comp.arch
Subject: Re: MVC and MVCL (was Re: RISC Mainframe)
Date: 22 Jul 1992 21:27:25 GMT
Organization: MIPS Computer Systems, Inc.
NNTP-Posting-Host: winchester.mips.com

In article <1992Jul20.154604.12548@bcars64a.bnr.ca> schow@bqneh3.bnr.ca (Stanley T.H. Chow) writes:

>Clearly then, you belong to the compile-code-for-each-different-machine
>school of administration. I think I will start a disk drive company to
>supply your disk requirements :-)

1) Some systems support dynamic-linked shared libraries for a lot of
other reasons; that's one way to do it.

2) if it really makes a difference, it's not all that hard to have
a function that checks once to see which machine is there, andthen choose
one of several versions of the code, 8after* checking to see that the
move-length is long enough to be interesting.
-- 
-john mashey	DISCLAIMER: <generic disclaimer, I speak for me only, etc>
UUCP: 	 mash@mips.com [soon to be mash@sgi.com, but not quite moved yet].
DDD:  	408-524-7015,  or 524-8253
USPS:	(soon) Silicon Graphics, 2011 N. Shoreline Blvd, Mountain View, CA 94043
Newsgroups: comp.arch
From: peter@ferranti.com (Peter da Silva)
Subject: Re: CISC Microcode (was Re: RISC Mainframe)
Organization: Xenix Support, FICC
Date: Mon, 27 Jul 1992 12:41:44 GMT

In article <55117@mentor.cc.purdue.edu> hrubin@pop.stat.purdue.edu (Herman Rubin) writes:
> In article <id.YGRR.V_5@ferranti.com> peter@ferranti.com (Peter da Silva) writes:
> >In article <54638@mentor.cc.purdue.edu> hrubin@pop.stat.purdue.edu (Herman Rubin) writes:
> >> >		1) The compilers can't figure out how to use them often.

> >> We keep hearing that compilers can do as well as humans.

> >They do, but not in the same way. Similarly there are optimisations compilers
> >will use that humans can't.

> If an optimization involves extensive calculation, a superfast sub-imbecile
> can do it better than a human.

I'm glad you noticed it. We're agreed then that these idiot savants generate
code that is as fast as a human can write, if not the same sort of code. 

> >> >	or	2) Most realistic code doesn't lend itself to the mode.

> >> What is realistic code?  I will code differently if there is hardware
> >> auto-increment for addresses.

> >I won't.

> Why not?  Because this would involve using an optimization not in the
> usual set?

Because allowing the compiler to find machine-specific optimisations is more
cost effective than doing it myself. Because the code I write runs on Sparcs,
68000s, 80386s, 80286s, VAXen, and 68020s. Because next month it might be
running on MIPS or 88000. Next year it might be running on Supersparc or Alpha.
Because optimising when you don't need to is a waste of resources.

If I'm writing a Forth inner interpreter loop in assembly, I'll use "JMP (IP)+"
or "LDA IP; PLO PC; LDA IP; PHI PC; SEP PC" or "MOV [IP]++,PC". If I'm writing
even a small complete program, I'll let the compiler worry about whether to use
a multiply or a shift.

> >I expect any good programmer to code for the abstract machine defined for
> >the language. Remember, software longa, hardware brevis.

> This might be reasonable if we had a language produced by people who have
> some respect for the capabilities of humans.

We do. We have dozens of them.

> An analogy to the present
> programming languages would be a car-controller in which one could feed
> in a destination, but would not allow manual control.

Analogies are like instant coffee, but what you want is a little more primitive
than that. I don't know about you, but I'm glad they don't make cars with
manual chokes any more, or that need double-clutching when you shift.
-- 
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
From: eoahmad@ntuix.ntu.ac.sg (Othman Ahmad)
Subject: Bit-level parallelism
Organization: Nanyang Technological University - Singapore
Date: Tue, 21 Jul 1992 06:59:57 GMT

Has anybody heard of the term bit-level parallelism in any publication?
Usually it is called fine-grained parallelism, but I prefer the word
bit-level.
	A lot of work has been done on this: my main references were Shlomo
Waser and M.J. Flynn book which uses Winograd Theorem.
	Another was a book which uses ICL DAP bit-parallel supercomputer.

I only use text books for that search. I may continue to the paper search
especially for recent developments.

May I know what key words should I use?

Any information would be appreciated. Thank you.

--
Othman bin Ahmad, School of EEE,
Nanyang Technological University, Singapore 2263.
Internet Email: eoahmad@ntuix.ntu.ac.sg
Bitnet Email: eoahmad@ntuvax.bitnet

From: emagnuso@sherpa2.lan1.eldec.com (Erik Magnuson)
Date: Tue, 28 Jul 1992 17:46:28 GMT
Subject: Re: Re: What's in a name? (cross-posted to SGI since mentioned)
Organization: ELDEC Corp
Newsgroups: comp.arch

zstern@adobe.com (Zalman Stern) writes:

> There are examples of better ways to do things as well. On the extreme edge
> there is the HP3000->precision architecture and DEC VAX->Alpha. 

I don't think it is valid to compare the backward compatibility
solutions of *systems* vendors like HP and DEC to a *microprocessor*
vendor like Intel (w.r.t. the x86 line.)[*] When you provide the
entire box (processor, other hardware and OS) you have a bit more
freedom in how compatible you have to be. However, you you only the
supply the processor (and perhaps a few support chips) your options
are far more limited.  

DEC has to support VMS, OSF/1 (aren't they dropping Ultrix?) and (in
the future) Windows NT. (Two of these are designed to be "portable"
OS's.)  Systems built around the Intel line have to support MS-DOS, DR
DOS, Windows, OS/2, Unix, and tens or even hundreds of variations on
the above most of which are intimately tied to the architecture. Not
to mention that the price points of the system (and the total units
shipped) involved are an order of magnitude or two different.

> 3) The performance anomalies in which the previous generation of an Intel
> Arch. run MS-DOS software faster. Especially so when there are much faster
> clockspeed variants to be had. like the AMD 286 and 386 parts vs Intel 386
> and 486. (If your goal is to run old software fast, then you better had do
> that.)

I think this is expressed a bit backwards. Many older programs exploit
"features" of the previous implementations to maximize performance on
a limited resource machine (i.e. 8088). These same tricks are often
not the fastest way to do things on a 486. What's your point? Some
people will always write for the lowest common denominator and some
will kill for an additional 10%. (Now where have I heard that before?)

When Intel want to make existing software run faster, they introduce a
new part. AMD makes faster copies of existing parts (although it's
hard to call a 40 MHz 386 *much faster* than a 33 MHz 386.) The PC
Mags claim that systems built around a 20 MHz 486SX run DOS software
as fast as systems using a 40MHz AMD 386.  It seems that both
companies do a good job at making existing S/W run faster even for
about the same price point. However, Intel offers 25, 33, and 50 MHz
parts as well that go even faster.  AMD will undoubtably catchup and
then Intel will cut the price on the P5 and the wheel will go on.

[*] Yes, I know that Intel makes some systems and DEC wants to sell
Alpha chips. But that's not currently where their primary markets are.
 
> --
> Zalman Stern               zalman@adobe.com                 (415) 962 3824
> Adobe Systems, 1585 Charleston Rd., POB 7900, Mountain View, CA 94039-7900

-- 
Erik Magnuson
ELDEC Corp.
sherpa2!emagnuso@sunup.west.sun.com
...!hpubvwa!sherpa2!emagnuso
From: jfc@athena.mit.edu (John F Carr)
Newsgroups: comp.arch
Subject: Re: Solaris (was: Sun 600MP Benchmark Anomaly)
Date: 25 Jul 92 14:24:35 GMT
Article-I.D.: athena.1992Jul25.142435.9821
Organization: Massachusetts Institute of Technology

In article <14pkdrINN5ni@uk-news.UK.Sun.COM>
	adrian.cockcroft@uk.sun.com writes:

>I have run a two processor S600MP with a Solaris 2 beta release with
>both CPU's at over 95% system time (to show that it can be done).

How much of the 95% is spent in the locking code?  How much is spent
waiting for locks?

--
    John Carr (jfc@athena.mit.edu)
From: vhs@darkcube.radig.de (Volker Herminghaus-Shirai)
Newsgroups: comp.arch
Subject: Re: What's in a name?
Date: 22 Jul 92 17:02:28 GMT
Reply-To: vhs@darkcube.radig.de

In article <1992Jul20.181618.18981@crd.ge.com> 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*.

--
Volker Herminghaus-Shirai (vhs@darkcube.radig.de)

If I had intel inside(tm), I'd throw up...
Newsgroups: comp.arch
From: glew@pdx007.intel.com (Andy Glew)
Subject: Re: What's in a name?
Organization: Intel Corp., Hillsboro, Oregon
Date: Fri, 24 Jul 1992 06:52:43 GMT

> |> 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*.


12 years ago, my dream was to build cheap high performance RISC
processors that brought really high performance computing power to the
masses. My parents (non-computer nerds) in particular.

Through all of those years, there was never built a cheap high
performance computer system using a RISC that my parents would want to
use.  (Sure, I know about the BBC Micro - I mean *use*, not play
with.) All of the RISC companies concentrated on high margin
workstations that only companies and universities could purchase.

In the meantime, the IBM PC and family kept delivering higher and
higher performance, until somewhere between the i386 and i486 it
crossed the useful threshold. And it was cheap!

So now I'm building cheap high performance processors that bring
really high performance computing power to the masses.

Funny what the loss of one adjective can do.



--

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: feivel@riese.informatik.uni-frankfurt.de (Christine Gross)
Newsgroups: comp.arch
Subject: Cache Coherence
Date: 23 Jul 92 12:04:23 GMT
Distribution: world
Organization: Johann Wolfgang Goethe-Universitt
Originator: feivel@gautama


Can anybody give me information about caches and methods to get cache coherence ?
  Thanks in advance , Christine !
Xref: sparky comp.arch:8400 alt.folklore.computers:11337 comp.benchmarks:1204
From: zebee@ucs.adelaide.edu.au (Zebee Johnstone)
Newsgroups: comp.arch,alt.folklore.computers,comp.benchmarks
Subject: Re: dinosaur horsepower
Date: 28 Jul 92 23:25:09 GMT
Followup-To: comp.arch
Organization: Information Technology Division, The University of Adelaide, AUSTRALIA

sysmark@helios.physics.utoronto.ca (Mark Bartelt) writes:

>By the way, if the history project does succeed in emulating some of the
>older machines, will it also provide an emulator for an 026 keypunch? ;-)

Who needs an emulator?  I've got the real thing!
-- 
----------------------------------------------------------------------
     Zebee Johnstone  DoD #605   | You don't own an Italian motorcycle 
     Adelaide City Council       |  - you merely have the privilege 
    zebee@itd.adelaide.edu.au    |    of paying its bills.... 
Newsgroups: comp.arch