geoff@desint.UUCP (Geoff Kuenning) (02/12/88)
All the NeWS proponents seem to think that its biggest feature, in fact
the only one that "clearly" makes it better than the alternatives like
X, is its programmability. Well, I'm not convinced. In fact, I think
the programmability is NeWS's biggest drawback. (It's second biggest
is its capitalization, which gives me finger cramps. :-)
Why don't I like programmability? Because I don't like hard-to-find bugs.
C code is hard enough to debug as it is; I'm not too enamored of the idea
of writing C code which writes Postscript which hangs my NeWS server in
an infinite loop that I then have to try to debug indirectly through C.
No thanks, folks.
This problem is severely aggravated by the fact that Postscript is a
postfix language. While postfix is truly wonderful for some things, like
real-time calculation (I'll never buy a non-HP calculator), it is truly
hell for most humans to think in. We're just too thoroughly trained in
infix notation. As a former PPC member and a veteran of 1500-line HP-41C
programs, I can testify from personal experience about how hard it is to
keep in mind just exactly what you've put on the stack and in what order.
Most people won't bother; they'll just use NeWS remotely like X, and then
where is the big win?
As to performance, especially in mouse tracking (which is the problem that
NeWS fans always love to sieze on), the overhead of interpreting
Postscript is very similar to the overhead of network communication.
See the recent interview with Brian Reid in Unix Review. I guess you can
compile the Postscript, but then you've got an interesting problem trying
to predict whether it's worthwhile, since the server has no way of knowing
whether this is a one-shot download or an often-used subroutine. And I
haven't heard of anybody compiling Postscript yet (though that doesn't prove
Sun doesn't have nefarious plans...).
Finally, there's the "first-vs-better" syndrome. For many people, it
doesn't matter if NeWS is better, because they've already standardized on
X and they're not about to repeat the learning curve. So for them, NeWS
will just be a slower version of X.
--
Geoff Kuenning geoff@ITcorp.com {uunet,trwrb}!desint!geoffmike@arizona.edu (Mike Coffin) (02/13/88)
From article <1677@desint.UUCP>, by geoff@desint.UUCP (Geoff Kuenning): > All the NeWS proponents seem to think that its biggest feature, in fact > the only one that "clearly" makes it better than the alternatives like > X, is its programmability. Well, I'm not convinced. In fact, I think > the programmability is NeWS's biggest drawback. (It's second biggest > is its capitalization, which gives me finger cramps. :-) ... > Geoff Kuenning geoff@ITcorp.com {uunet,trwrb}!desint!geoff I agree with you about the capitalization. Was it Knuth that started this trend with TeX? Arrrrrggghh. I'm a proponent of NeWS --- or at least the design of NeWS, since I've never actually used it. I don't think programmability itself is NeWS's biggest feature. The important thing is that the designers of NeWS realize that the most important constraint on speed in a network window system is bandwidth. And they further noticed that the way to push a lot of information through a very narrow pipe is to send a program. I suspect that the reason NeWS will win over X --- if it does --- is that NeWS applications will use less bandwidth than equivalent X programs. Not just a little less, but orders of magnitude less. You can effectively move the inner loop of an interactive program from the machine where the (perhaps computation-intensive) program is running to the machine where the interaction is taking place. Even if the program is running on the same machine as the server, a bottleneck still exists; IPC between client and server requires expensive context switches. Presumably context switches within the lightweight processes in the NeWS server are much cheaper than UNIX-style context switches. -- Mike Coffin mike@arizona.edu Univ. of Ariz. Dept. of Comp. Sci. {allegra,cmcl2,ihnp4}!arizona!mike Tucson, AZ 85721 (602)621-4252
martillo@athena.mit.edu (Yakim Martillo) (02/13/88)
As far as I can tell, bandwidth like memory just gets cheaper and more available. Futurebus is not too far off and gigabit bandwidth network backbones will probably be available in the near future, which is good because we will be seeing customers that desire network transparent 3d high resolution real-time color graphics. Favoring a system because it might work better over 9600 bps serial links than another seems to evince a serious confusion about goals. Now I have the impression Sun unlike DEC is not doing much research in faster back-planes so that maybe such goals are reasonable for Sun. As for context switching, it would seem that situations could easily exist where NeWS could actually require more context switching than X because in addition to context switching between client and server there would be context switching within the server as well.
mike@arizona.edu (Mike Coffin) (02/13/88)
From article <2936@bloom-beacon.MIT.EDU>, by martillo@athena.mit.edu (Yakim Martillo): > As far as I can tell, bandwidth like memory just gets cheaper and more > available. Futurebus is not too far off and gigabit bandwidth network > backbones will probably be available in the near future, which is good > because we will be seeing customers that desire network transparent 3d > high resolution real-time color graphics. Favoring a system because > it might work better over 9600 bps serial links than another seems to > evince a serious confusion about goals. You won't see *effective* bandwidth anywhere near a gigabit any time soon, especially for small messages like most of those X shuffles around. And it's not the physical bandwidth of the network dominates the cost, it's the CPU time spent packing up messages, doing traps, changing (heavy weight) contexts, fielding interrupts, copying (or mapping) messages into user address space, etc. > Now I have the impression > Sun unlike DEC is not doing much research in faster back-planes so that > maybe such goals are reasonable for Sun. As for context switching, > it would seem that situations could easily exist where NeWS could > actually require more context switching than X because in addition > to context switching between client and server there would be context > switching within the server as well. But context switching within the server is (well, I'm assuming) much faster than between client and server. A context switch between two lightweight processes that share memory amounts to little more than saving one set of registers and loading another. This should be a couple of orders of magnitude faster than a full address-space switch. -- Mike Coffin mike@arizona.edu Univ. of Ariz. Dept. of Comp. Sci. {allegra,cmcl2,ihnp4}!arizona!mike Tucson, AZ 85721 (602)621-4252
martillo@athena.mit.edu (Yakim Martillo) (02/13/88)
>You won't see *effective* bandwidth anywhere near a gigabit any time >soon, especially for small messages like most of those X shuffles >around. And it's not the physical bandwidth of the network >dominates the cost, it's the CPU time spent packing up messages, doing >traps, changing (heavy weight) contexts, fielding interrupts, copying >(or mapping) messages into user address space, etc. The Xlib routines actually buffer up the messages to send to the remote until the process XFlush()'s them into the kernel for transmission. Improperly coded X programs could probably generate zillions of little packets crossing the application kernel boundary but a competent coder would not write his routines that way. Incompetent NeWS programming could probably generate zillions of little NeWS programs for transmission.
mike@arizona.edu (Mike Coffin) (02/14/88)
From article <2940@bloom-beacon.MIT.EDU>, by martillo@athena.mit.edu (Yakim Martillo): > The Xlib routines actually buffer up the messages to send to the > remote until the process XFlush()'s them into the kernel for > transmission. Improperly coded X programs could probably generate > zillions of little packets crossing the application kernel boundary > but a competent coder would not write his routines that way. > Incompetent NeWS programming could probably generate zillions of little > NeWS programs for transmission. Here's an extreme example, just to make a point. Suppose we have a main CPU in a robot on Mars, with a workstation on earth. The communication delay is on the order of minutes. The robot detects an anomalous situation, one that demands a decision from earth. Two scenarios: X) The robot pops up a menu on earth. It pops up a cursor. A human moves the cursor to a selection. Highlighting the each selection takes several minutes, of course, because a message has to be passed to Mars and back to accomplish it. After three or four selections have been highlighted but not picked, the mouse finally makes it to the correct one. Then the human releases the mouse button; a couple minutes later the robot knows what to do. NeWS) The robot sends the entire menu selection program to earth. The entire selection process takes place here, and a single message is sent back. Which interface would you rather use? Granted, most networks aren't that slow. And for all I know, X11 has menus built into the server, making the above scenario moot. Even if that has been done (has it?) it is just a special case; other kinds of interaction will still force X programmers to use XFlush() to cross the client/server boundary much more often than NeWS. The bottom line is that X needs to cross boundary every time visual feedback is needed, unless a special case has been made and built into the X server. -- Mike Coffin mike@arizona.edu Univ. of Ariz. Dept. of Comp. Sci. {allegra,cmcl2,ihnp4}!arizona!mike Tucson, AZ 85721 (602)621-4252
wesommer@athena.mit.edu (William Sommerfeld) (02/14/88)
In article <3851@megaron.arizona.edu> mike@arizona.edu (Mike Coffin) writes: >From article <2940@bloom-beacon.MIT.EDU>, by martillo@athena.mit.edu (Yakim Martillo): >other kinds of >interaction will still force X programmers to use XFlush() to cross the >client/server boundary much more often than NeWS. Use of XFlush() is actually quite rare, primarily because XNextEvent() and similar library routines call XFlush() before blocking. The assertion is commonly made that NeWS can do cursor tracking better than X can. This may well be true, but competantly written X applications provide _very_ good cursor tracking, with updates greater than about 30Hz on a MicroVAX II (with the client and the server on the same machine). The graphics operations are the limiting factor, not the communications time. This was the case under X10, and continues to be the case under X11. The common case is, after all, that the client and the server run on the same machine; rubber-banding for window resizing and the like is done by the window manager process in X11, and that will be local to the workstation under almost all cases. The X protocol was carefully designed to remove most common cases where the client has to block waiting for the server and vice versa. The example given where network round-trip-times are on the order of minutes is irrelevant. If the workstation on earth were using (for example), NFS to get to `files' on the workstation, you would have to wait one RTT for each pathname component of each pathname you look up. Long-latency systems require markedly different protocols. NeWS programming requires you to know two radically different languages (extended PostScript and, presumably, C) and switch between them quickly; X only requires one (for now, C or Common Lisp; other languages such as Ada will presumably be added as well). Some people at USENIX said that NeWS was more fun for hackers because of the interpretive element involved. X is probably as much fun (except for the more limited imaging model) under a C interpreter such as Saber-C or under a LISP interpreter (disclaimer: I've used X under Saber C, but not CLX or NeWS). - Bill
gaynor@topaz.rutgers.edu (Silver) (02/15/88)
> NeWS programming requires you to know two radically different > languages (extended PostScript and, presumably, C) and switch > between them quickly; X only requires one (for now, C or Common > Lisp; other languages such as Ada will presumably be added as well). > Some people at USENIX said that NeWS was more fun for hackers > because of the interpretive element involved. X is probably as much > fun (except for the more limited imaging model) under a C > interpreter such as Saber-C or under a LISP interpreter (disclaimer: > I've used X under Saber C, but not CLX or NeWS). The point about learning and switching languages is invalid for the same reason that a container whose volume is 50% occupied by water is both half full and half empty. You either learn the language (NeWS-extended PostScript) or learn the protocol (the X protocall). Besides, we all know at least two programming languages. I have no problem going from Lisp to C to sh to Pascal to ... ___ \o/ Cheers, V [Ag] _|_
dowdy@apple.UUCP (Tom Dowdy) (02/15/88)
In article <3851@megaron.arizona.edu> mike@arizona.edu (Mike Coffin) writes: >Here's an extreme example, just to make a point. Suppose we have a >main CPU in a robot on Mars, with a workstation on earth. The >communication delay is on the order of minutes. The robot detects an >anomalous situation, one that demands a decision from earth. Two >scenarios: > > [scenarios deleted, they described how slow X would be in this situation vs how fast NeWS would be] >Granted, most networks aren't that slow. And for all I know, X11 has They aren't? The above example is getting a little carried away, but we were able to come up with a much more realistic one very quickly: When the world is a better place and ISDN is everywhere, the possibilities of running windowing applications across the country (or even trans-continental) will be commonplace for people who can afford the line charges. But have you taken a Physics 101 look at the time involved in a speed of light transaction across the country? (And that's assuming no delay, which packet switching would introduce, or heaven forbid, should there be a satelite in there someplace) Now, according to the porting guide, one needs 5 to 50 ms turnaround time to make X work well. You cant do that if you are talking 4000 miles! Now I talked to someone who *had* run X across a satelite, he said that while it was slow it was still workable, and one REALLY only noticed the delay when doing rubber-band type operations. I don't really have an opinion of X vs. NeWS, but anything that requires a high speed LAN and ships billions of bytes of data just to do an interface is up for question in my mind. This is sort of what I call the "CS" mentality. "Well, it isn't fast enough now, but those engineers will figure out a way to make fast CPUs/LANs sometime, and then it will be great. Isn't it so elegant?" Tom Dowdy CSNET: dowdy@apple.CSNET Apple Computer MS:27Y AppleLink:DOWDY1 20525 Mariani Ave UUCP: {sun,voder,amdahl,decwrl}!apple!dowdy Cupertino, CA 95014 "The 'Oo-Ah' Bird is so called because it lays square eggs."
jqj@uoregon.UUCP (JQ Johnson) (02/15/88)
Finally, some interesting observations from the Martillo side of the recent "martillo vs the world" debate. Let me try a reply: In article <2936@bloom-beacon.MIT.EDU> martillo@athena.mit.edu (Yakim Martillo) writes: >As far as I can tell, bandwidth like memory just gets cheaper and more >available. I think I agree. Note, though, that there are several different product spaces. I expect to have 100Mb rates on my campus backbone in 2 years, but will be lucky if I have telephone lines into every student dorm room; if I *do* have telephone lines, it is unlikely that we will be able to afford anything faster than 2B+D ISDN. A fortiori, I don't expect to see data rates to mobile stations (e.g. portable PCs in cars. Rates to/from tanks will obviously be much higher) of much above 9600b for a decade. So I *do* care about having a network windowing technology that works well over slow links! >... As for context switching, >it would seem that situations could easily exist where NeWS could >actually require more context switching than X because in addition >to context switching between client and server there would be context >switching within the server as well. There are different kinds of context switching, obviously, with different overheads. That's the whole point of the lightweight-process argument. Martillo's argument would be stronger if he could demonstrate that the "contexts" necessary in a NeWS server were actually fairly heavyweight.
wesommer@athena.mit.edu (William Sommerfeld) (02/15/88)
I will state in advance that I have never used NeWS; I have used and programmed X. >The point about learning and switching languages is invalid for the >same reason that a container whose volume is 50% occupied by water is >both half full and half empty. You either learn the language >(NeWS-extended PostScript) or learn the protocol (the X protocol). A clarification: You don't have to ``learn the protocol'' in the sense of knowing what the bits going over the wire look like; there are library functions which handle all of the packing and unpacking of data for each request. Xlib provides a procedure-oriented interface to the programmer. However, you do have to understand the higher level protocol of the way events work, but that's going to be there for any windowing system. If you instead use the X toolkit, most, if not all, of the protocol details are handled by the toolkit. My point was not that you don't need to absorb a large amount of information to use X (you do); it is that X uses the language of your choice for both the calls to the window system and the application, while NeWS requires you to know both PostScript and the application language. C uses infix operators and prefix notation (for function calls and control flow). PostScript is _entirely_ postfix, including the control-flow operators; this means that you have to scan to the _end_ of a construct to figure out what it was. It was designed to be easy for machines to interpret and easy to compile to, not to be easy to program in. I'd rather let the compiler or interpreter manage the stack---I've got better things to do than count stack slots. >I have no problem going from Lisp to C to sh to Pascal to ... Neither do I---I've written my share of shell scripts calling awk programs which write C programs. However, there is always a ``context switch delay'' which increases when the languages are as radically different as C and PostScript; whether the alleged advantanges of PostScript make up for this is unclear. I will say that the PostScript _imaging model_ seems to be a lot more flexible and featureful than the X imaging model; however, I can easily see a system which uses an X-like protocol to do PostScript style imaging (with a transformation matrix in the graphics context, among other things); I wouldn't be surprised if in a few years there was a standard X extension which provided this. - Bill
martillo@athena.mit.edu (Yakim Martillo) (02/15/88)
I hardly consider it a flaw with X that it might not work well over ISDN. ISDN is a broken and obsolete technology, and I speak as someone who has frequently taken part in the T1/D1 standards meetings. In any case I remember one of Jim Gettys early demos was running a client doing fast graphics at Berkeley with a server at MIT and the performance wasn't obviously worse than performance across a LAN at MIT. Now the link was probably a 56kbps leased line so I don't think that X will do so bad over 64kbps switched lines.
geoff@desint.UUCP (Geoff Kuenning) (02/15/88)
In article <3835@megaron.arizona.edu> Mike Coffin (mike@arizona.edu) writes: > I don't think programmability itself is NeWS's biggest feature. Frankly, I don't care whether programmability is its biggest or its littlest feature; I still think it's its biggest drawback. (But note that almost all published plaudits about NeWS cite the programmability as the thing that makes it truly different and thus wonderful. Actually, this even extends back to Postscript -- see the "orange book".) > The important thing is that the designers of > NeWS realize that the most important constraint on speed in a network > window system is bandwidth. Only if (a) you run lots of applications remotely that push lots of information across the net, and (b) you are running a net that is current technology. And don't forget the cost of interpreting NeWS, as I pointed out in my original posting. Most published accounts of NeWS demonstrations that I've seen include a "boy, was it slow" component. > Presumably context switches within the > lightweight processes in the NeWS server are much cheaper than > UNIX-style context switches. Personally, I think "lightweight processes" are a foolish idea invented by people who'd like to write their own OS, but aren't in a position to do so. "Process switches are expensive on MY hardware/software combination, so I think I'll invent my on process-switching code." Very satisfying, but hardly good computer science. Much better to spend that energy making ALL process switches faster, or reducing unneeded process switching. In the case of UNIX, I firmly believe that the real problem is the lousy scheduler and swapper, not slow process switching. -- Geoff Kuenning geoff@ITcorp.com {uunet,trwrb}!desint!geoff
neal@druhi.ATT.COM (Neal D. McBurnett) (02/17/88)
I see a lot of good arguments that say that NeWS uses bandwidth more efficiently, and I think they are good arguments. However, the most telling factor for me is that NeWS can also offload the client processor. Picture a time-shared client processor and a server which runs mainly on a PC, workstation or very smart terminal (like the 630 terminal from AT&T). I'm really frightened by the thought of my Vax or Amdahl having to reply to a bunch of tiny interactions, like highlighting each menu selection. Even the vi and emacs editors can grind a system with 50-200 users on it into the ground, so I think the the ability to download an arbitrary amount of the functionality of an application into the NeWS server is a great asset. For applications in which the client and server are both on the same processor, this may not matter much, but if we're looking for a widely applicable standard, I think NeWS is it. Single-user workstations may be the wave of the future, but for a long time, people will want to make use of their larger hosts in combination with smart, cheap terminals. -Neal McBurnett, AT&T R&D, ihnp4!druhi!neal
wm@mucs.UX.CS.MAN.AC.UK ( "temporary login") (02/19/88)
In article <2945@bloom-beacon.MIT.EDU> wesommer@athena.mit.edu (William Sommerfeld) writes: >NeWS programming requires you to know two radically different >languages (extended PostScript and, presumably, C) and switch between >them quickly; X only requires one (for now, C or Common Lisp; ... Just because PostScript went to the trouble to include useful things like control structures, doesn't mean that it is any harder to learn and understand than a large set of C function calls (the X library, toolkit, etc.). Remember, a language is just a set of conventions for communication. The interface to a library is certainly such a language. Indeed, a good case can be made that an extensible, complete language (such as PostScript) is easier to learn than a set of subroutine calls, since desired operations can be built up from a smaller set of primitive operations (an example of this would be some arbitrary dashed line, which might not be provided in a library of dashed lines, but which could always be coded up using an iterator in a complete language). Wm Leler The PIX Project
reggie@pdn.UUCP (George W. Leach) (02/23/88)
In article <2691@druhi.ATT.COM> neal@druhi.ATT.COM (Neal D. McBurnett) writes: >For applications in which the client and server are both on the same >processor, this may not matter much, but if we're looking for a widely >applicable standard, I think NeWS is it. Single-user workstations may >be the wave of the future, but for a long time, people will want to make >use of their larger hosts in combination with smart, cheap terminals. On the contrary. I tend to think that the later is the wave of the future and that networking single-user workstations/PCs is only a temporary situation until a "network" OS emerges to make life easier. I would recommend reading the Position Paper presented by Rob Pike and Ken Thompson at the IEEE Workshop on Operating Systems this past fall. It is only a page and a third long, but it says an awful lot. -- George W. Leach Paradyne Corporation {gatech,rutgers,attmail}!codas!pdn!reggie Mail stop LF-207 Phone: (813) 530-2376 P.O. Box 2826 Largo, FL 34649-2826