On Mon, Dec 19, 2011 at 4:02 PM, Steve Dekorte <st...@dekorte.com> wrote: > > On 2011-12-17 Sat, at 01:17 AM, Eugen Leitl wrote: >> On Fri, Dec 16, 2011 at 02:16:41PM -0800, Steve Dekorte wrote: >>> Is speed really the bottleneck for making computers more useful? >> >> Many major scientific problems or even gaming are resource-constrained. >> I personally would have no difficulties keeping astronomical numbers >> of nodes at 100% CPU for years and decades. > >> Consider what a BlueGene/Q on every desktop would mean. > > > Suppose you want to write an app to help people organize events. > Neither the development or running the app is compute bound > and a machine 1000x faster in itself likely wouldn't much with either. > > However, using a garbage collected OO language would. So in as > much as faster machines lower the cost of higher abstractions, they > are helpful for programming. But we are already at the point where > most of our time programming is sitting in front of an idle machine > trying to tell it what to do. > > I can't make a hard case for it, but I'd suggest that most of the > utility we've gained from computers has been from communication > and organization for more efficient resource allocation, that > the development of tools for these areas is the largest bottleneck > to maximizing the utility of computers and that this is generally > not a compute bound problem.
Everything except the last bit is correct, IMHO. Virtual machines, today, by and large, lack support for first-class scheduling of resources. Reasoning about resources is all about compute bound problems, like how much resources a client is allowed to reserve per server request. We have also yet to put into practice languages which limit the client run-time of an algorithm on a server (assuming the client can parameterize over the server's service in some disciplined way). Solving this problem will eliminate virtually all IT jobs. _______________________________________________ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
