On Fri Apr 17 16:22:55 EDT 2009, blstu...@bellsouth.net wrote: > >> I often tell my students that every cycle used by overhead > >> (kernel, UI, etc) is a cycle taken away from doing the work > >> of applications. I'd much rather have my DNA sequencing > >> application finish in 25 days instead of 30 than to have > >> the system look pretty during those 30 days. > > > > i didn't mean to imply we should not be frugal with cycles. > > i ment to say that we simply don't have anything useful to > > do with a vast majority of cycles, and that's just as wasteful > > as doing bouncing icons. we need to work on that problem. > > I gotcha. I guess it depends on what you're doing. I remember > years ago running a simulation on the 11/750 we had. It > simulated a DSP chip running 2 seconds of real time. It > ran for over a week. (While it was running, I took the time > to write another, faster simulator that was able to run > the simulation in about 2 hours.) For something like that, > we can certainly use all the cycles we can get. On the other > hand, I might look for a faster way to compile a kernel > a while back, but now it compiles fast enough on most > any machine that I'm not too concerned about where to > use the cycles. (I'm speaking of a Plan 9 or Inferno kernel > here; not a *BSD or Linux kernel.) But I suspect that > virtualization and Dis-style VMs are a pretty good use of > cycles we have to spare.
people's ideas about what's complicated or hard don't change as quickly as computing power and storage has increased. i think there's currently a failure of imagination, at least on my part. there must be problems that aren't considered because they were hard. as an old example, i think that the lab's use of worm storage for the main file server was incredibly insightful. what could we do today, but don't quite dare? - erik
