xanthian@well.UUCP (Kent Paul Dolan) (09/22/89)
BANDWIDTH WASTERS HALL OF FAME
for articles in
/usr/spool/news/comp/arch
Thu Sep 21 20:03:49 PDT 1989
Bytes Volume Offending
Wasted Share Articles Guilty Party
23682 8.79% 7 mash@mips.COM (John Mashey)
12301 4.57% 2 ggw@wolves.uucp (Gregory G. Woodbury)
10782 4.00% 1 wright@usceast.UUCP (Steve Wright)
10324 3.83% 1 mcg@mipon2.intel.com (Steven McGeady)
9445 3.51% 4 mmm@cup.portal.com (Mark Robert Thorson)
8500 3.15% 5 lamaster@ames.arc.nasa.gov (Hugh LaMaster)
8494 3.15% 2 cliffhanger@cup.portal.com (Cliff C Heyer)
8121 3.01% 2 melvin@ucbarpa.Berkeley.EDU (Steve Melvin)
7445 2.76% 4 ok@cs.mu.oz.au (Richard O'Keefe)
7410 2.75% 5 baum@Apple.COM (Allen J. Baum)
6803 2.52% 3 hascall@atanasoff.cs.iastate.edu (John Hascall)
6107 2.27% 1 rfk@dukee.egr.duke.edu (Robert F Krick)
5315 1.97% 3 hankd@pur-ee.UUCP (Hank Dietz)
5255 1.95% 3 roelof@idca.tds.PHILIPS.nl (R. Vuurboom)
4941 1.83% 4 les@unicads.UUCP (Les Milash)
4708 1.75% 2 johnl@esegue.segue.boston.ma.us (John R. Levine)
4675 1.74% 2 barry@PRC.Unisys.COM (Barry Traylor)
4534 1.68% 1 retrac@titan.rice.edu (John Carter)
4404 1.63% 2 daveh@cbmvax.UUCP (Dave Haynie)
4372 1.62% 1 mark@mips.COM (Mark G. Johnson)
4031 1.50% 2 bruce@tolerant.UUCP (Bruce Hochuli)
3770 1.40% 2 roy@phri.UUCP (Roy Smith)
3761 1.40% 3 colin@watcsc.waterloo.edu (Colin Plumb)
3645 1.35% 1 suitti@haddock.ima.isc.com (Stephen Uitti)
3632 1.35% 2 scott@bbxsda.UUCP (Scott Amspoker)
3501 1.30% 1 glen@sunscreen.UUCP (Glen Ivey)
3473 1.29% 1 kquick@simpact.com (Kevin Quick, Simpact Assoc., Inc.)
3348 1.24% 2 aglew@urbana.mcd.mot.com (Andy-Krazy-Glew)
3322 1.23% 1 jesup@cbmvax.UUCP (Randell Jesup)
3261 1.21% 2 preston@titan.rice.edu (Preston Briggs)
3161 1.17% 1 albaugh@dms.UUCP (Mike Albaugh)
3038 1.13% 1 rfg@ics.uci.edu (Ronald Guilmette)
3029 1.12% 1 ECULHAM@UALTAVM.BITNET (Earl Culham)
2991 1.11% 2 andrew@frip.WV.TEK.COM (Andrew Klossner)
2759 1.02% 2 chris@mimsy.UUCP (Chris Torek)
2692 1.00% 1 dik@cwi.nl (Dik T. Winter)
2522 0.94% 1 bmw@isgtec.UUCP (Bruce Walker)
2508 0.93% 2 swarren@eugene.uucp (Steve Warren)
2315 0.86% 1 jwmills@iuvax.cs.indiana.edu (Jonathan Mills)
2211 0.82% 1 mat@uts.amdahl.com (Mike Taylor)
2181 0.81% 1 sbf10@uts.amdahl.com (Samuel Fuller)
2045 0.76% 1 daryl@hpcldko.HP.COM (Daryl Odnert)
2029 0.75% 1 brent@uwovax.uwo.ca (Brent Sterner)
1839 0.68% 1 eric@snark.uu.net (Eric S. Raymond)
1823 0.68% 1 jonah@db.toronto.edu (Jeffrey Lee)
1815 0.67% 1 mcdonald@uxe.cso.uiuc.edu
1776 0.66% 1 katin@skylark.Sun.COM (Neil Katin)
1712 0.64% 1 rang@cs.wisc.edu (Anton Rang)
1707 0.63% 1 mbutts@mentor.com (Mike Butts)
1587 0.59% 1 mslater@cup.portal.com (Michael Z Slater)
1539 0.57% 1 jab@dasys1.UUCP (Jeff A Bowles)
1529 0.57% 1 david@daisy.UUCP (David Schachter)
1464 0.54% 1 eifert@oakhill.UUCP (Jim Eifert)
1426 0.53% 1 rodman@mfci.UUCP (Paul Rodman)
1425 0.53% 1 stevew@wyse.wyse.com (Steve Wilson xttemp dept303)
1422 0.53% 1 mccalpin@masig3.ocean.fsu.edu (John D. McCalpin)
1333 0.49% 1 jgd@csd4.csd.uwm.edu (John G Dobnick)
1271 0.47% 1 dfields@urbana.mcd.mot.com (David Fields)
1253 0.47% 1 levisonm@qucis.queensu.CA (Mark Levison)
1249 0.46% 1 henry@utzoo.uucp (Henry Spencer)
1180 0.44% 1 ttl@astroatc.UUCP (Tony Laundrie)
1159 0.43% 1 bmacintyre@watcgl.waterloo.edu (Blair MacIntyre)
1158 0.43% 1 karl@ficc.uu.net (Karl Lehenbauer)
1155 0.43% 1 gcaw@otter.hpl.hp.com (Greg Watson)
1154 0.43% 1 friedl@vsi.COM (Stephen J. Friedl)
1144 0.42% 1 pkh@vap.vi.ri.cmu.edu (Ping Kang Hsiung)
1093 0.41% 1 phil@diablo.amd.com (Phil Ngai)
1044 0.39% 1 firth@sei.cmu.edu (Robert Firth)
978 0.36% 1 amos@taux01.UUCP (Amos Shapir)
964 0.36% 1 dheeraj@nile.cs.umd.edu (Dheeraj Sanghi)
951 0.35% 1 perl@step.UUCP (Robert Perlberg)
944 0.35% 1 rod@venera.isi.edu (Rodney Doyle Van Meter III)
893 0.33% 1 cassel@sce.carleton.ca (Ron Casselman)
877 0.33% 1 BEAR@S34.Prime.COM
731 0.27% 1 lilja@uicsrd.csrd.uiuc.edu
585 0.22% 1 UTB100@PSUVM.BITNET
415 0.15% 1 junien@prls.UUCP (Junien Labrousse)
-------- ------- ----
269438 99.98% 122 Totals for 77 authors
(Roundoff fuzz may make total share < 100.00%)
(Sorry, if you posted from more than one site, you got more
than one entry. It's unavoidable; think about it! But even
though your subtotals look smaller, we know who you are!)
[A shar file of the scripts used to create this article was
posted to alt.sources by the author, Kent Paul Dolan.]firth@sei.cmu.edu (Robert Firth) (09/22/89)
> BANDWIDTH WASTERS HALL OF FAME > for articles in > /usr/spool/news/comp/arch This seems like a good opportunity for me to express my thanks to all contributors to this newsgroup. Over the past few months, I have learned more interesting, relevant technical detail from this group than from any other source, including books, journals, and conferences. The contributions made here by its prominent posters are clear, objective and fascinating. The debates on major architectural issues have been sharp, technically informative, and conducted almost invariably with exemplary courtesy. Please continue the good work. Long life to you all, and may your branch shadows never grow less. Robert Firth
axaris@cs.buffalo.edu (Vassilios Axaris) (09/23/89)
I second the opinion expressed that the discussions have been elightening and utterly interesting. Well, I happened to delve into the area of stack machines. I have not seen too much going on, except the RTX 2000. Why is there this lack of interest in the designer community, when the architecture offers some clear advantages when considering code compaction, context switching, and the like? Especially for high level languages that execute around the stack. Any insight will be greatly appreciated. Yours, Vassilios E. Axaris axaris@marvin.cs.buffalo.edu v999nzwr@ubvms.bitnet
preston@titan.rice.edu (Preston Briggs) (09/23/89)
In article <4186@bd.sei.cmu.edu> firth@sei.cmu.edu (Robert Firth) writes: >> for articles in >> /usr/spool/news/comp/arch > >This seems like a good opportunity for me to express my >thanks to all contributors to this newsgroup. >Robert Firth Hear, hear! Even the postings that I disagree with (sometimes violently) are useful in that they help me define my own positions. Keep up the great work. Preston
khb%chiba@Sun.COM (chiba) (09/23/89)
In article <10732@eerie.acsu.Buffalo.EDU> axaris@cs.buffalo.edu (Vassilios Axaris) writes: >I have not seen too much going on, except the RTX 2000. Why is there this lack >of interest in the designer community, when the architecture offers some clear >advantages ... When the world was young(er) :> , stack machines, register machines, and direct memory machines (e.g. TI) battled for domination. Before reasonable register allocation algorithms were discovered stack machines were nifty ... but now having a lot (use your own figure of merit :>) of registers and good allocation is generally conceeded to be the short path to good performance. The recent discussion of adaptive caching reminds me of the remark (anyone know who originated it ?) "registers are compiler allocatable caches". Bottom line: A stack machine derives less benefit from locality of data reference. Keith H. Bierman |*My thoughts are my own. !! kbierman@sun.com It's Not My Fault | MTS --Only my work belongs to Sun* I Voted for Bill & | Advanced Languages/Floating Point Group Opus | "When the going gets Weird .. the Weird turn PRO"
scott@bbxsda.UUCP (Scott Amspoker) (09/23/89)
In article <13744@well.UUCP> xanthian@well.UUCP (Kent Paul Dolan) writes: > > BANDWIDTH WASTERS HALL OF FAME > for articles in > /usr/spool/news/comp/arch > Thu Sep 21 20:03:49 PDT 1989 > >[deleted count of *offending* articles poster considers wasteful] > I'm disappointed I wasn't anywhere near the top of the list. I guess since I don't know as much as some other readers of this group I enjoy learning from the informative postings of others. Next time I want Mr. Dolan's opinions about the quality of postings in this group I will ask for them. (Yes, that's a flame). -- Scott Amspoker Basis International, Albuquerque, NM (505) 345-5232
sl@van-bc.UUCP (Stuart Lynne) (09/23/89)
In article <13744@well.UUCP> xanthian@well.UUCP (Kent Paul Dolan) writes: > > BANDWIDTH WASTERS HALL OF FAME The above article was the worst waste of bandwidth I've seen in this group for a while. (With the possible exception of this one.) -- Stuart.Lynne@wimsey.bc.ca uunet!van-bc!sl 604-937-7532(voice) 604-939-4768(fax)
davisp@marina.CWRU.EDU (Palmer Davis) (09/23/89)
In article <13744@well.UUCP> xanthian@well.UUCP (Kent Paul Dolan) writes: > > BANDWIDTH WASTERS HALL OF FAME > for articles in > /usr/spool/news/comp/arch > Thu Sep 21 20:03:49 PDT 1989 > > Bytes Volume Offending > Wasted Share Articles Guilty Party > > [ incredibly long, wasteful, and inane commentary on people's net usage ] > This is the second newsgroup I've read today upon which you have inflicted this mindless drivel. For all your self-righteous posturing about wasters of bandwidth, your ENORMOUS postings of irrelevant, misleading, and utterly useless information are costing hundreds of sites across the continent (Thank GOD you didn't send this worldwide! The Australians would have had you shot!) thousands of dollars in transmission and storage costs. How can you so irresponsibly abuse such a valuable resource? >(Sorry, if you posted from more than one site, you got more >than one entry. It's unavoidable; think about it! But even >though your subtotals look smaller, we know who you are!) As Tanto said to the Lone Ranger when the Apaches started attacking, "What you mean 'we,' paleface?" IMHO, the articles I've seen posted from the gentlemen you've impugned have been relevant, to the point, and quite instructive to an undergraduate Comp. E. major like me. This is, in fact, the REASON we HAVE Usenet -- to exchange information and views! An outraged -- Palmer Davis -- Palmer T. Davis | The opinions expressed herein are my own Case Western Reserve University | and do not necessarily represent the truth. davisp@skybridge.scl.cwru.edu | Flame away to your heart's content.
barry@PRC.Unisys.COM (Barry Traylor) (09/24/89)
In article <10732@eerie.acsu.Buffalo.EDU> axaris@cs.buffalo.edu (Vassilios Axaris) writes: >I second the opinion expressed that the discussions have been elightening and >utterly interesting. Thank-you very much. Even though I'm relatively new at this, I seemed to finish in the top 25. >Well, I happened to delve into the area of stack machines. >I have not seen too much going on, except the RTX 2000. Why is there this lack >of interest in the designer community, when the architecture offers some clear >advantages when considering code compaction, context switching, and the like? >Especially for high level languages that execute around the stack. >Any insight will be greatly appreciated. Thank-you, thank-you for mentioning stack machines. The little beastie I work on happens to be one. It is also concurrent per processor AND multiprocessing. The machine? The Unisys (formerly Burroughs) A17. Early published literature can be found on an ancestor, the B6700. The book was still in print about 8 years ago: "Structure and Architecture of the B6700" by Elliot Organick. I may be a little off on the title. Processor architecture reference manuals for current products can be ordered from Unisys, but I'd be hard pressed to tell you how. Barry Traylor Unisys A Series Engineering barry@prc.unisys.com (when I can dial in)
barry@PRC.Unisys.COM (Barry Traylor) (09/24/89)
In article <125156@sun.Eng.Sun.COM> khb@sun.UUCP (chiba) writes: > >When the world was young(er) :> , stack machines, register machines, >and direct memory machines (e.g. TI) battled for domination. Before >reasonable register allocation algorithms were discovered stack >machines were nifty ... but now having a lot (use your own figure of >merit :>) of registers and good allocation is generally >conceeded to be the short path to good performance. >... >Bottom line: A stack machine derives less benefit from locality of > data reference. Stack machines OPTIMIZE locality of reference. By doing such, a processor does not need to have massive quantities of registers available. On a context switch, or better yet, a process switch (which on most machines involves 2 context switches), how long does it take to store and restore all of those registers? I remember reading in this forum that on a 40Mhz SPARC machine, it took about 70microseconds to do a context switch. It takes much less than that on a 16MHz A17. At the worst, a process switch costs 20microseconds. A context switch into the operating system costs less than 5 microseconds. A large part of the savings comes from the ability of the PROCESSOR to schedule internal registers and make sure that ONLY those that are needed immediately are valid. Top of stack is then chained through operators with a different top of stack register set for each pipelined operation. If an interrupt occurs, only those registers representing the current top of stack for the interrupted operator need to be pushed, not the entire register set. The registers allocated for operations subsequent to the interrupt are merely returned to the available pool. Options are my own. Measurements are approximate, but not far off. Barry Traylor Unisys A Series Engineering barry@prc.unisys.com
cik@l.cc.purdue.edu (Herman Rubin) (09/25/89)
In article <11539@burdvax.PRC.Unisys.COM>, barry@PRC.Unisys.COM (Barry Traylor) writes: ................................ > Stack machines OPTIMIZE locality of reference. By doing such, a processor > does not need to have massive quantities of registers available. On a > context switch, or better yet, a process switch (which on most machines > involves 2 context switches), how long does it take to store and restore > all of those registers? ............................... How long does it take to get all those items on the stack, and to read them off the stack? The CDC6x00 and related machines had no programmer context switch; it was necessary for each part of the program to make sure that the contents of its important registers were not clobbered by any calls. This involved a great deal of loading and storing, far slower than context switch hardware would have been if it were available. Of course, it there was nothing to save and later restore, this cost would not be incurred, but it was frequently quite high. -- Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907 Phone: (317)494-6054 hrubin@l.cc.purdue.edu (Internet, bitnet, UUCP)
tim@cayman.amd.com (Tim Olson) (09/25/89)
In article <11539@burdvax.PRC.Unisys.COM> barry@PRC.Unisys.COM (Barry Traylor) writes: | Stack machines OPTIMIZE locality of reference. By doing such, a processor | does not need to have massive quantities of registers available. Except that the locality of reference for stack machines is too narrow, mainly restricted to the first few items on the top of the stack. Compiler optimizations such as common subexpression elimination and loop-invariant code-motion want to stuff useful values into fast-access locations for reuse, but if you don't have a mechanism for specifying these locations in the instruction set, then the benefit of these optimizations is reduced. | On a | context switch, or better yet, a process switch (which on most machines | involves 2 context switches), how long does it take to store and restore | all of those registers? The tradeoff here is how often you perform a context switch vs. how often you perform some other operation that can benefit from general-purpose registers (and whether the context switch time meets any real-time requirements placed on it). -- Tim Olson Advanced Micro Devices (tim@amd.com)
cliffhanger@cup.portal.com (Cliff C Heyer) (09/26/89)
There must be some error in the bandwidth waste calculation algorithm. I added up 32KB I've posted in Sept, in which case I'd be in first place. But according to the post, I posted only 8.5KB at 7th place. (You might be thinking of the above as tongue-in-cheek, but it's not!) A quick scan of the bandwidth waster list shows ALL the writers in comp.arch. Which would lead one to conclude that the title "wasters" is tongue-in-cheek. You folks that thought otherwise, think before you post!
asg@pyuxf.UUCP (alan geller) (09/29/89)
In article <4186@bd.sei.cmu.edu>, firth@sei.cmu.edu (Robert Firth) writes: > > BANDWIDTH WASTERS HALL OF FAME > > for articles in > > /usr/spool/news/comp/arch > > This seems like a good opportunity for me to express my > thanks to all contributors to this newsgroup. > > Over the past few months, I have learned more interesting, > relevant technical detail from this group than from any > other source, including books, journals, and conferences. > The contributions made here by its prominent posters are > clear, objective and fascinating. The debates on major > architectural issues have been sharp, technically informative, > and conducted almost invariably with exemplary courtesy. > > Please continue the good work. Long life to you all, > and may your branch shadows never grow less. > > Robert Firth Hear, hear!! Thanks, everyone!! Alan Geller t h i s w i l l l e t m e p o s t !