Why so little parallelism?
|
From: Nicholas King on 21 Dec 2006 20:37 BDH wrote: >> It needs to be written in some form, you don't need to prove its >> correctness although that helps :) but you do need to come up with it >> and write it down in some form that other people can understand within >> the 20 minutes otherwise you can claim all the time you want. > > The point is not that I want to come in for some sort of exam. The > point is that English is the assembly language of thinking. The point is that you made a claim that you are unwilling to back up. If you had any integrity at all you'd admit that it was bullshit. You have to remember that you are the one who said you could do it in 20 minutes. Extraordinary claims generally require proof. >> Personally i wonder what sort of competent algorithm designer >> doesn't know about basic complexity theory. > > Well, in all the things I've done P-completeness never came up. Do you > find that surprising? It's interesting, but in terms of actual > application... > If you can prove something is P#-Complete or someone has already done it then you can avoid the time spent finding a parallel algorithm for your problem. I don't know about you but most algorithm designers like to know all they can about problems and complexity , so they know which tools and methods are likely to be successful. If i know a problem is similar to others then I'll look at what techniques were successful for them and try them.
From: Nicholas King on 21 Dec 2006 20:40 Nick Maclaren wrote: > Unfortunately, too much of modern IT is pure Blair-type salesmanship, > and all of the mathematics and engineering is regarded as subsidiary. It seems the way the world is going unfortunately, towards form over function so much that function doesn't matter. > > Nicholas King <zeddie(a)internode.on.net> writes: > |> Personally i know enough to know that I'm a novice. > > And so am I, even though I have been consulted on this area for 30 > years - the more I know, the more I know I don't know :-) I dread the day that I'm not a novice, the fun of computer science is what you don't know :) Nicholas King
From: ranjit_mathews on 22 Dec 2006 05:23 Nick Maclaren wrote: > In article <KDAfh.15787$HV6.7154(a)newsfe1-gui.ntli.net>, > ChrisQuayle <nospam(a)devnul.co.uk> writes: > |> > |> X is a system killer though, not because of bad design, it is quite > |> elegant, ... > > Heaven help us! X's design is utterly ghastly from start to finish, That means that if one writes a new XServer from scratch, preserving only compliance with the XProtocol and ICCCM, one's new XServer would necessarily be ghastly because it preserves these parts of the design. Is this what you mean or do you mean something less than "start to finish"? > though most of the aspects of that are irrelevant to this thread. > However, two of them are relevant. > > The way that keyboard and mouse interactions have to be sent the > whole way back to the application before they take effect forces > the c. 10 context switches, many more page touches / TLB misses and > innumerable pipeline drains. NeWS was a lot better. Without getting all the way back to the application, how do you know whether any action need to be taken? Only the application knows whether an event on a widget is of interest to it.
From: Nick Maclaren on 22 Dec 2006 05:52 In article <1166782987.149611.76710(a)a3g2000cwd.googlegroups.com>, "ranjit_mathews(a)yahoo.com" <ranjit_mathews(a)yahoo.com> writes: |> |> That means that if one writes a new XServer from scratch, preserving |> only compliance with the XProtocol and ICCCM, one's new XServer would |> necessarily be ghastly because it preserves these parts of the design. |> Is this what you mean or do you mean something less than "start to |> finish"? Yes. The X Server is not the worst part of the X morass[*], by a long chalk, and the reason that ALL X Servers are ghastly is for the reason you have said. The font manager, window manager, Toolkit and widget designs (which are horribly entangled in largely unspecified ways) are far worse. |> > The way that keyboard and mouse interactions have to be sent the |> > whole way back to the application before they take effect forces |> > the c. 10 context switches, many more page touches / TLB misses and |> > innumerable pipeline drains. NeWS was a lot better. |> |> Without getting all the way back to the application, how do you know |> whether any action need to be taken? Only the application knows whether |> an event on a widget is of interest to it. See if you can find anything on NeWS, the ISO Virtual Terminal work or IBM's Common User Access implementation design (i.e. the one that gave rise to Presentation Manager and hence Microsoft Windows). There are doubtless other, comparable designs that I don't know about. The executive summary is to provide a high-level, semi-programmable interface between the application and the GUI. For example, the former says "This window is an editable field for a single-line ISO 10646 string, initialised to ..." The latter will then handle the editing and return just the result or a cancellation when the user commits the changes. One of the defects of the X Windowing System design is that it uses that sort of level for output, but one of TWO levels below for input! 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. [*] It's approaching Christmas. I sometimes use a harsher word. Regards, Nick Maclaren.
From: ranjit_mathews on 22 Dec 2006 06:34
Nick Maclaren wrote: > "ranjit_mathews(a)yahoo.com" <ranjit_mathews(a)yahoo.com> writes: > The executive summary is to provide a high-level, semi-programmable > interface between the application and the GUI. For example, the former > says "This window is an editable field for a single-line ISO 10646 > string, initialised to ..." The latter will then handle the editing > and return just the result or a cancellation when the user commits the > changes. > > One of the defects of the X Windowing System design is that it uses > that sort of level for output, but one of TWO levels below for input! > > 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). > [*] It's approaching Christmas. I sometimes use a harsher word. > > Regards, > Nick Maclaren. |