From: Nick Maclaren on 14 Nov 2006 04:50 In article <4558e6f4$1(a)darkstar>, eugene(a)cse.ucsc.edu (Eugene Miya) writes: |> |> >This is getting boring. If you can provide evidence for the above claims, |> >please do so. |> |> Gee Nick, that's commonly asked of you, and you never seem to provide either. I do agree that I often don't respond to people who ask rudely, which is why you have often not had a a response. But, excluding that, why don't YOU provide evidence for YOUR claim? You have been asked to do so often enough, and have never responded with more than insults. Regards, Nick Maclaren.
From: Eugene Miya on 14 Nov 2006 17:03 In article <ejc3ht$nn9$1(a)gemini.csx.cam.ac.uk>, Nick Maclaren <nmm1(a)cus.cam.ac.uk> wrote: >|> >This is getting boring. If you can provide evidence for the above claims, >|> >please do so. In article <4558e6f4$1(a)darkstar>, eugene(a)cse.ucsc.edu (Eugene Miya) writes: >|> Gee Nick, that's commonly asked of you, and you never seem to provide either. > >I do agree that I often don't respond to people who ask rudely, which >is why you have often not had a a response. Zaldans do not like shallow expressions of courtesy. Like I keep pointing out: it It's not merely me but also Gombosi, desJardins, and others. >But, excluding that, why don't YOU provide evidence for YOUR claim? Sure I do. Easily grepped from old posts using refer (%[A-Z]). >You have been asked to do so often enough, and have never responded with >more than insults. See prior sentence. Your excuse now? --
From: Terje Mathisen on 19 Nov 2006 15:30 Nick Maclaren wrote: > In article <4qq5elFof9pgU1(a)individual.net>, > "Del Cecchi" <delcecchiofthenorth(a)gmail.com> writes: > |> Performance can be provided. As the hot rodders say, performance costs > |> money. How fast do you want to go? > > Yup. Fast, cheap, reliable. Pick any two. Only in a perfect world: Often you're reduced to picking just one of those. :-( Terje -- - <Terje.Mathisen(a)hda.hydro.com> "almost all programming can be viewed as an exercise in caching"
From: Nick Maclaren on 19 Nov 2006 18:03 In article <xdSdnZ_Ga_NiI_3YnZ2dnUVZ8tidnZ2d(a)giganews.com>, Terje Mathisen <terje.mathisen(a)hda.hydro.com> writes: |> Nick Maclaren wrote: |> > In article <4qq5elFof9pgU1(a)individual.net>, |> > "Del Cecchi" <delcecchiofthenorth(a)gmail.com> writes: |> |> > |> Performance can be provided. As the hot rodders say, performance costs |> > |> money. How fast do you want to go? |> > |> > Yup. Fast, cheap, reliable. Pick any two. |> |> Only in a perfect world: Often you're reduced to picking just one of |> those. :-( Or even the best approximation to one that you can find :-( But I have a great deal of sympathy for designers who are told that their product must be fast, cheap, reliable, ready by tomorrow, with specifications to be finalised next week. It is scarcely surprising that the result usually fails on all its targets .... Regards, Nick Maclaren.
From: Anne & Lynn Wheeler on 4 Dec 2006 13:46
eugene(a)cse.ucsc.edu (Eugene Miya) writes: > Over lunch I did get the story of IBM's dumping of AI research in > 1955-1956 from McCarthy (until the mid-80s). I wonder if it will > appear in Wikipedia and history books? I think we want to go a > little beyond the chewing gum walking stage. We can barely get a > car to go 100 miles w/o a driver. There was a development group in Menlo Park in the late 80s. I think it grew to a couple hundred people and some number of people from Stanford worked/consulted there. My vague recollection was that the whole thing was eventually shutdown .... again it is from fading memory, but I believe the reason was over patent issues. old email from somebody in the menlo park knowlege based group. To: wheeler Date: 16 February 1988, 13:33:42 PST Lynn, I am looking for pathlength guidelines for the interactive frontend (scrolling, window moving etc) for the knowledge based systems project. We currently think the pathlength for a scrolling operation may be as much as 40-50K instructions, and are concerned that will result in very sluggish operation on what we assume will be a loaded system (the knowledge processing itself should be compute bound and non-interactive.) Do you have any rules of thumb I can pass on to our developers? Thanks for your help, .... snip ... While the mvs/vtam pathlength may have been on that order ... the VM issue was different (the actual scroll pathlength was significantly less). A terminal I/O would have "boosted" the processing into the "interactive" queue ... where it would get around 100K instruction execution. The long ago, original CP67 scheduler ... and the initial VM370 schedulers ... would just give absolute interactive priority "boost". The fair share scheduler that I did as an undergraduate in the 60s for CP67 would change the granularity of the execution bursts based on interactive or background gueue ... however, the actual priority was based on recent resource utilization vis-a-vis target (the scheduler label came because the default "target" was fair share) ... aka a particular process's execution rate would be based on competition for the processor. This was later re-introduced as the Resource Manager product for vm370. http://www.garlic.com/~lynn/subtopic.html#fairshare which also included a bunch of other features related to performance, like paging http://www.garlic.com/~lynn/subtopic.html#wsclock for some completely other drift ... the 23jun69 "unbundling" announcement started charging for application software (somewhat in response to various litigatioin by the gov. and others). however, the system/kernel software was still free ... based on the argument that it was required as part of operating the hardware (which the customer would have already paid for). however, by the time it came along to release my resource manager ... attitudes was starting to change ... in part because of clone processors being able to take advantage of free kernel software. the resource manager was chosen to be the guinea pig for kernel software charging. misc. past posts mentioning unbundling and starting to charge for kernel software http://www.garlic.com/~lynn/subtopic.html#unbundle and for something completely different: II03052: RERUN MAY CAUSE THE TERMINAL TO HANG WHEN USING A VCNA TERMINAL ON VM. http://www-1.ibm.com/support/docview.wss?uid=isg1II03052 the Resource Manager actually had a bunch of (other) code having to do with reliability and eliminating all known cases of hung/zombie users .... some related posts here having to do with stress testing of the Resource Manager in preparation for product ship http://www.garlic.com/~lynn/subtopic.html#bench however, various later kernel work introduced new hanging problems. actually there was some amount of work involving Sowa (when he was at IBM) and semantic networks in the 70s. http://www.jfsowa.com/ and for other drift ... a page by sowa referencing john boyd http://www.jfsowa.com/talks/challenge.htm and then of course some number of past boyd posts http://www.garlic.com/~lynn/subboyd.html#boyd and various other boyd URLs from around the web http://www.garlic.com/~lynn/subboyd.html#boyd2 |