mcdonald@uxe.cso.uiuc.edu (03/28/89)
In article <977@quintus.UUCP> lawrence@quintus.UUCP (Lawrence Byrd) writes: >This question is motivated by the increasing complexity of window systems >and the obvious need for ways of speeding them up. It is depressing that >one needs a system in the 5 to 10 MIP range before the newer window systems >(such as various toolkits on top of X) start responding crisply... Henry spencer replies: >The cynic would say that we need less-baroque window systems. The one on >AT&T's Blit responds crisply with a lousy little 68000 running it. >Now that we've got RISC hardware, the next thing we need is operating >systems and window systems to match. Ah! How about this as a discussion/flame topic: Resolved: Layered software functionality is sluggish, and therefore undesirable. Doug McDonald
grunwald@flute.cs.uiuc.edu (03/28/89)
In article <46500057@uxe.cso.uiuc.edu> mcdonald@uxe.cso.uiuc.edu writes:
....
Resolved: Layered software functionality is sluggish, and therefore
undesirable.
I'd state it as `layered software sacrifices speed for portability, and
therefore keep CPU architecture employed.'
While Henry Spencer is correct in stating that the Blit software was
responsive, I'll bet you ducks to donkeys that:
+ it only runs on Blits
+ it can't run over a network, like X
+ it probably didn't handle color
+ it's not used anymore
The advantage of ``layered software,'' like X windows or PHIGS is that you
can have a reasonable amount of sucesss in porting from brand X to brand Y
equipment.
--
Dirk Grunwald
Univ. of Illinois
grunwald@flute.cs.uiuc.edujack@cwi.nl (Jack Jansen) (03/28/89)
In article <GRUNWALD.89Mar27224353@flute.cs.uiuc.edu> grunwald@flute.cs.uiuc.edu writes: >In article <46500057@uxe.cso.uiuc.edu> mcdonald@uxe.cso.uiuc.edu writes: > .... > > Resolved: Layered software functionality is sluggish, and therefore > undesirable. > >I'd state it as `layered software sacrifices speed for portability, and >therefore keep CPU architecture employed.' Actually, layered software doesn't *have* to be sluggish. However, it takes quite a bit of work to build an efficient layered product. You have to design an initial version, use it for a while, measure it, redesign it (possibly moving features between levels), use it for a while, measure it, etc etc etc. Measuring should also include making instruction traces across all levels, especially for the 'most-common-case'. This will often lead you to functionality that is cheaper to provide at a different level. Also, using caching at each level can also give you a layered product a performance that is only slightly worse than that of a non-layered one. This method should give you good performance and a maintainable product. Unfortunately, it will be years in designing.......... -- -- Een volk dat voor tirannen zwicht | Oral: Jack Jansen zal meer dan lijf en goed verliezen | Internet: jack@cwi.nl dan dooft het licht | Uucp: mcvax!jack
henry@utzoo.uucp (Henry Spencer) (03/29/89)
In article <GRUNWALD.89Mar27224353@flute.cs.uiuc.edu> grunwald@flute.cs.uiuc.edu writes: >While Henry Spencer is correct in stating that the Blit software was >responsive, I'll bet you ducks to donkeys that: > > + it only runs on Blits True, although there are three different pieces of hardware that come under that generic term (the original Bell Labs one, the 5620, and the 630). > + it can't run over a network, like X What precisely do you mean, "over a network"? If you mean, with the graphic interaction remote from the application process, that is *exactly* how Blits work, necessarily so, because the Blit is a terminal and is not capable of running the application code. > + it probably didn't handle color No, although there's no fundamental reason why it couldn't have. One of the fundamental costs of color is more bits to push around; this is a good reason to avoid it if you don't need it. > + it's not used anymore It's in daily use in many places, although it is not as ubiquitous as X. -- Welcome to Mars! Your | Henry Spencer at U of Toronto Zoology passport and visa, comrade? | uunet!attcan!utzoo!henry henry@zoo.toronto.edu
wcs@skep2.ATT.COM (Bill.Stewart.[ho95c]) (03/29/89)
In article <GRUNWALD.89Mar27224353@flute.cs.uiuc.edu> grunwald@flute.cs.uiuc.edu writes: > While Henry Spencer is correct in stating that the Blit software was > responsive, I'll bet you ducks to donkeys that: The software really was two things - the operating system / graphics package for the terminal, and the protcol for the communication link. > + it only runs on Blits Layers runs on three flavors of AT&T terminals (real BLIT prototype, WE-32000-based DMD5620, 68000-based AT&T 630), a hacked-up Atari ST at UToronto (68000), and the AT&T 6300 PC-Clone (hacked a bit, since you've got that MS-DOS in the way, and the graphics doesn't use a contiguous linear memory space.) The protocol also communicates with a couple of AT&T terminals that don't have a full graphics/os on the terminal but support the standard terminal emulators.) Oh, and also on Suns, though I'm not sure if it's runnign on top of Sunview or not, and I think you need the V9 OS. > + it can't run over a network, like X How well does X run over RS-232? (yeah, I know it's been done) This is strictly a terminal-to-host protocol, not a WS-to-WS, (though the Sun runs both halves). It's not network-transparent, though most of what you need can cross arbitray networks. Ether-Networks were too expensive when the BLIT was designed, and cheapness was an objective. There are network implementations being done, though I understand Rob doesn't approve. > + it probably didn't handle color BLIT is short for "bitblt". Bitmaps only. The Gnot does gray-scale. > + it's not used anymore Wrong-o. The DMD 5620 was priced too high, so it mostly sold internally and got given away to universities, but the 630 is reasonably-priced (<$2K, 1024x1024 screen) and the partial implementations are dumb-terminal priced. Even Doug Gwyn has some. Disclaimer: most of this is accurate, but I got up early today and I'm not near my regular office, so parts of it are from old memory. -- # Bill Stewart, AT&T Bell Labs 2G218 Holmdel NJ 201-949-0705 ho95c.att.com!wcs # Washington, DC. Raining. Long, cold, heavy rain. Been raining for days. # I was here last year in the spring. It was raining like this then, too. echo This article public domain unless posted to an att.* group.
jkrueger@daitc.daitc.mil (Jonathan Krueger) (03/30/89)
In article <1989Mar28.164428.20458@utzoo.uucp>, henry@utzoo (Henry Spencer) writes: >> + [blit] can't run over a network, like X > >What precisely do you mean, "over a network"? If you mean, with the >graphic interaction remote from the application process, that is *exactly* >how Blits work, necessarily so, because the Blit is a terminal and is not >capable of running the application code. I believe he meant not necessarily connected to a specfic host. -- Jon --