Why so little parallelism?
|
From: ChrisQuayle on 26 Dec 2006 08:24 David Ball wrote: > > I usually just lurk since I'm not a chip designer and haven't worked > with debugging boards and writing firmware since the 8080/8085/Z-80 > days. I just wanted to point out that on the linux kernel mailing > list, getting X to be responsive without messing up the rest of the > system seemed to cause an incredible amount of problems in the > scheduler. I think they ended up with a bunch of code to try to decide > if a process was interactive and give it priority for short bursts of > cpu time, then degrade it to non-interactive if it used too much cpu. > IIRC, they spent months tuning it not to starve important processes > and actually degrade the display or mess up things like playing mp3 > files. I don't follow the list as much as I used to so I'm not really > sure if they ever found something they were reasonably satisfied with. > > -- David (8080/Z-80/x86 asm/c/c++ programmer who used to do firmware) > Perhaps the long term answer is to embed the X server and window manager support into the graphics card and just talk to the card using the X protocol, using dma for speed. Download the selected widget set, look and feel etc to the card at login time. It's certainly doable with modern embedded technology and half way house to full redesign, while retaining compatability with present systems... Chris
From: ChrisQuayle on 26 Dec 2006 09:00 Nick Maclaren wrote: > 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. Did a bit of digging and found: http://starynkevitch.net/Basile/NeWs_desc_oct_1993.html Not any info on data flow though the layers and haven't been able to find the mentioned reference manual on the Sun web site. Looks like Sun were going their own way developing a windowing system and tried to integrate X functionality later, when it bacame apparent that X would become the dominant standard. I think the main problem with X now is the window manager, which is really in the wrong place in the stack. It should probably be placed just above the framebuffer driver for perfomance reasons, though this would play havoc with the model... Chris
From: ChrisQuayle on 26 Dec 2006 09:21 Eugene Miya wrote: > > Some one has to design the board and pipelines. The real problem is > modularity. It doesn't help when graphics artists get really confused > with message passing, shared memory, etc. > Agreed, but one of the reasons why graphics is so ubiquitous now is all the gory implementation details are hidden from the creative types of other disciplinee, who just want to make pictures with it. Art for the masses, or what ?. I well remember "high end" graphics systems of the late 80's - 19" rack case full of amd bit slice and fast bipolar memory, hundreds of watts consumption and all you got was a dma interface, a set of io registers and a function library in assembler. You needed to be a competent systems engineer / programmer just to draw a line. I wonder how such systems would compare performance wise with the typical $100 pc graphics card of 2006 ?. The Metheus unit described above cost 10k $ or more iirc... Chris
From: Anne & Lynn Wheeler on 26 Dec 2006 10:56 Terje Mathisen <terje.mathisen(a)hda.hydro.com> writes: > Almost 20 years ago, while we were developing the Oseberg North Sea > oil field, we had a couple of modules under construction in Holland > (Rotterdam/Den Haag), and the two possible alternatives for comms > links were leased SDLC or X.25. recent posts in this thread: http://www.garlic.com/~lynn/2006y.html#0 Why so little parallelism? http://www.garlic.com/~lynn/2006y.html#4 Why so little parallelism? http://www.garlic.com/~lynn/2006y.html#10 Why so little parallelism? my wife had done brief stint as chief architect for amadeus. there was decision about SNA or X.25 ... and my wife went w/X.25. The SNA forces then went into action ... which resulted in my wife being replaced (trying to tip the balance back to SNA). It didn't do any good since amadeus went with X.25 anyway. a hard-copy amadeus design document has a date: 24apr87 (almost 20 years ago) a couple recent posts about other similar run-ins http://www.garlic.com/~lynn/2006w.html#21 SNA/VTAM for NSFNET http://www.garlic.com/~lynn/2006x.html#8 vmshare misc. past posts mentioning amadeus http://www.garlic.com/~lynn/2001g.html#49 Did AT&T offer Unix to Digital Equipment in the 70s? http://www.garlic.com/~lynn/2001g.html#50 Did AT&T offer Unix to Digital Equipment in the 70s? http://www.garlic.com/~lynn/2001h.html#76 Other oddball IBM System 360's ? http://www.garlic.com/~lynn/2003d.html#67 unix http://www.garlic.com/~lynn/2003n.html#47 What makes a mainframe a mainframe? http://www.garlic.com/~lynn/2004b.html#6 Mainframe not a good architecture for interactive workloads http://www.garlic.com/~lynn/2004b.html#7 Mainframe not a good architecture for interactive workloads http://www.garlic.com/~lynn/2004m.html#27 Shipwrecks http://www.garlic.com/~lynn/2004o.html#23 Demo: Things in Hierarchies (w/o RM/SQL) http://www.garlic.com/~lynn/2004o.html#29 Integer types for 128-bit addressing http://www.garlic.com/~lynn/2005f.html#22 System/360; Hardwired vs. Microcoded http://www.garlic.com/~lynn/2005p.html#8 EBCDIC to 6-bit and back http://www.garlic.com/~lynn/2006o.html#4 How Many 360/195s and 370/195s were shipped? http://www.garlic.com/~lynn/2006r.html#9 Was FORTRAN buggy?
From: ChrisQuayle on 26 Dec 2006 17:29
ChrisQuayle wrote: > Did a bit of digging and found: > > http://starynkevitch.net/Basile/NeWs_desc_oct_1993.html Sorry, typos, should be: http://starynkevitch.net/Basile/NeWS_descr_oct_1993.html Chris |