Why so little parallelism?
|
From: ChrisQuayle on 22 Dec 2006 16:50 Nick Maclaren wrote: > In article <Pine.LNX.4.61.0612221821130.13753(a)ask.diku.dk>, > "Peter \"Firefly\" Lund" <firefly(a)diku.dk> writes: > |> > |> > have said. The font manager, window manager, Toolkit and widget designs > |> > (which are horribly entangled in largely unspecified ways) are far > |> > worse. > |> > |> What font manager? > |> What toolkit? > > I keep hearing about these environments that run nothing but an X Server > and some clients, but I have never had anyone told me where they are > used. Today. I know damn well that they WERE used, back before the > rest of the edifice was perpetrated. > > Perhaps you would like to explain why you don't regard them as an > essential part of the X Windowing System? > > |> Actually, I think you /should/ go into details. Your knowledge of X seems > |> to be rather different from mine. Maybe we could both stand to learn > |> something? > |> > |> I, for one, would really like to learn how a mouse click or a key press in > |> an input field causes 10 context switches. In detail. > > It's a heck of a long time ago now, but it went something like this: > > User presses the key, which causes: > * Keyboard driver picks up the I/O event, munges it a bit and passes it to: > X Server to pick up the event, create an X event and passes it to: > [ Window manager, which decides it doesn't need it ] > X client, which creates X request to highlight field and passes it to: > * X Server, which updates screen and passes it to: > Display driver, which actually updates the screen > User releases the key, which causes: > * Keyboard driver picks up the I/O event, munges it a bit and passes it to: > X Server to pick up the event, create an X event and passes it to: > [ Window manager, which decides it doesn't need it ] > X client, which does action, creates X request and passes it to: > * X Server, which updates screen and passes it to: > Display driver, which actually updates the screen > > The lines in square brackets will depend on the window manager settings > and the actual key combinations. Motif (which was the flavour of the > month at the time I did the analysis) more-or-less required all events. > > The lines marked with asterisks can sometimes be 'eliminated' by having > the X server drive the devices directly, but they couldn't be in the > context I was interested in when I first did this analysis. I don't > know how often they can be today. > > HOWEVER, it should also be noted that an upper-case character repeats > most of the above for BOTH the shift key AND the actual key - in fact, > the only steps that the shift key omits are the last two for press and > release. > > Please note that, despite claims by dogmatists, switching in and out > of a driver IS a context switch - I will accept that a mere fast call > interrupt is not, but the costs of switching between an application > and driver and conversely are about the same as switching between two > applications. > > So I make it that the MINIMUM is 6 context switches for any character, > and 10 for an upper-case or control character. And not all systems > will do as well. > > > Regards, > Nick Maclaren. That's a very good summary, though it doesn't seem particularly arduous or inefficient. It may have been in the early days of X, where cpu throughput and memory was limited and a lot of the graphics processing was done in software, (See the dec wrl reports on dumb colour frame buffers and how they optimised the system, for example), but isn't so serious now. You get flexibility at a systems programming level at the expense of efficiency. Must look up the NeWs system to see how it works - can we have a similar summary for that as well ?... Chris
From: ranjit_mathews on 22 Dec 2006 16:40 Nick Maclaren wrote: > "ranjit_mathews(a)yahoo.com" <ranjit_mathews(a)yahoo.com> writes: > |> > > |> > I won't go into details, but one of the features of the ISO VT design > |> > was that it allowed parallelism between windows - i.e. two applications > |> > could interact with two separate windows without serialising through > |> > the GUI server. That is forbidden by the X design. > |> > |> If a particular application designer wants to do it that way, it can be > |> done although the X design might impose a perfomance/ latency penatly > |> tor being used in non-standard ways. Refer to the proceedings of the > |> (circa1990) 5th annual conference on Distributed Memory Computing for > |> an example of the implementation of an X client consisting of multiple > |> processes on multiple computers (or multiple nodes on a multicomputer). > > No, it can't, because the design forces the handshaking between the > X Server and the lowest-level client - if that is what you want to > avoid, you are stuffed. In NEWS, the lowest level client was on the display server. You can do the same thing with X; you can put the lowest level client on the Xserver host and use a higher layer like Interviews/Fresco interactors to hide the fact that the widgets are proxied. > You also don't get the RAS features of a better design, because you > can't stop another client from doing horrible things to you. The new > SSH security extensions for X are based on a separate layer that > clobbers a certain number of such things - but, if a client has a > direct X connexion, they don't help. Isn't it possible, in theory, to do the same thing as NEWS? It seems that if Ghostscript is extended to have the same features as NEWS Postscript rather than only the features of Display Postscript, an Xnews (no relation to the newsreader or SUN's Xnews implementation) client wouldn't have had a direct connection either; it would be the programmable Xnews widgets (or active objects) that have the direct connection to X and programming your Xnews implementation would be just like programming pre-X NEWS. > Oh, and they blow most clients > out of the water as soon as the user attempts to do a cut-and-paste > (for Emacs, even within the same window!) > > Hell, I designed a wrote a distributed client of the sort you are > describing in about 1987, only to discover that the X11.3 Toolkit Do you have some reason to be certain that your particular problems would have manifested themselves on all platforms, especially VMS? > and Motif 1.1 widget set were such bug-ridden heaps of junk as to > be completely unusable. Even if so, you don't need Motif to use X. > It wasn't until the next versions that any > of the distributed clients started to use them, which might indicate > something. The next versions were still X; your earlier comments had seemed to be about X in general rather than one version, one platform and one level of one release. > Regards, > Nick Maclaren.
From: Andrew Reilly on 22 Dec 2006 19:40 On Fri, 22 Dec 2006 19:23:29 +0000, Nick Maclaren wrote: > So I make it that the MINIMUM is 6 context switches for any character, > and 10 for an upper-case or control character. And not all systems > will do as well. Note that while the analysis is largely true, it is not, in fact, a problem, because people don't type very quickly. One of the huge benefits of modern, frame- and network based systems, compared to the tty-based ones of yore, is that all of that effort does not scale linearly with the amount of work involved: requests are batched in both directions. So the task switching overhead winds up being significantly smaller than that, ammortised over the large chunks of drawing effort that generally goes on *after* the user has pressed and released said key. It's hard to imagine any client-server GUI model that could provide the level of interactivity that applications and users require with fewer domain crossings without cutting some pretty serious corners. Well, in fact quite a few of those corners are in fact cut, in various systems. Modern X servers typically *do* do their own graphics driver work, and use memory-mapped buffers to communicate with the client applications, when those share the same machine (which is a pretty common case, now). Compare that to the old tty days, where the OS had to take an interrupt, and maybe a context switch for *every* character in or out of the system. And that didn't give you pretty icons or drop shadows... Cheers, -- Andrew
From: Nick Maclaren on 23 Dec 2006 05:05 In article <jqYih.28100$kM2.27587(a)newsfe7-win.ntli.net>, ChrisQuayle <nospam(a)devnul.co.uk> writes: |> |> That's a very good summary, though it doesn't seem particularly arduous |> or inefficient. It may have been in the early days of X, where cpu |> throughput and memory was limited and a lot of the graphics processing |> was done in software, (See the dec wrl reports on dumb colour frame |> buffers and how they optimised the system, for example), but isn't so |> serious now. You get flexibility at a systems programming level at the |> expense of efficiency. Unfortunately, that would not be so even if the components were implemented efficiently, which they aren't. The problem is in cache and TLB draining, and the impact on OTHER processes running on the same system. I have seen the use of X degrade the throughput by a factor of two, even though there were enough CPUs available at all times! |> Must look up the NeWs system to see how it works - can we have a similar |> summary for that as well ?... I never looked at it in depth; all I noted was that it had some features to alleviate this problem. Sorry. Regards, Nick Maclaren.
From: Nick Maclaren on 23 Dec 2006 05:09
In article <1166823658.614650.21070(a)48g2000cwx.googlegroups.com>, "ranjit_mathews(a)yahoo.com" <ranjit_mathews(a)yahoo.com> writes: |> |> In NEWS, the lowest level client was on the display server. You can do |> the same thing with X; you can put the lowest level client on the |> Xserver host and use a higher layer like Interviews/Fresco interactors |> to hide the fact that the widgets are proxied. Sigh. How on earth did you think that I designed my application? When you do that, you are no longer using the X protocol, because you are saying that all participating clients must be modified. |> Isn't it possible, in theory, to do the same thing as NEWS? ... No. See above. |> Do you have some reason to be certain that your particular problems |> would have manifested themselves on all platforms, especially VMS? Yes. For practical purposes, VMS van be regarded as intermediate between MVS and Unix, both of which I know well and on both of which it applies. |> > It wasn't until the next versions that any |> > of the distributed clients started to use them, which might indicate |> > something. |> |> The next versions were still X; your earlier comments had seemed to be |> about X in general rather than one version, one platform and one level |> of one release. They were and they are. That reference to versions was a statement that the X11.3 Toolkit was hopelessly buggy. Regards, Nick Maclaren. |