Maybe this is where you are going with this topic, but while 1U cases have an element of flexibility, as you point out, they are thermally quite inefficient. The problem, also as you alluded to, is forcing air across the critical components. Energy is proportional to the square of the velocity, and the smaller cases require air to flow at much higher velocities. By ganging cases together you can use larger, more efficient blowers or fans and save a significant amount of energy. This is one of the major effects that is exploited by various blade designs and IBM's iDataPlex. »

Many years ago we at Floating-Point Systems had a more than serious flirtation with functional programming languages, as you have sometimes promoted as a solution to this problem. We defined a functional programming language called "Flo", developed a compiler and parallel hardware to support that language and declared success. But it never sold (for many reasons, I suppose) so we promptly abandoned the idea in favor of more successful ideas. I'm sure we were neither the first nor the last to do so. Ever since then I have pondered how we solve the problem of managing parallel complexity in large scale programs. Much of the difficulty lies in the nature of specifying what constitutes a correct program. If the specification is too high level, you may get what you asked for but not what you want. But the more detail you supply, the more it becomes like a programming language with all its associated problems and less like a correctness specification. About the most promising approach I have seen so far is the algorithmic skeleton. My first exposure to that was Murray Cole's book "Algorithmic Skeletons". Extending the idea to parallel skeletons is not a far stretch and seems to strike a good balance between high-level specification and efficiency. I'm sure such work is already under way. High level operators are already supported in MPI in the form of reduce, allreduce and other functions. They're ugly syntactically because they are MPI, but the concepts are there. While declaring the ultimate demise of computing due to high levels of parallelism does make for good entertainment, all I would really expect to see is the price of computation fall as parallel resources increase. When that happens we may not have single applications that can span significant fractions of the available compute power, say a million cores in a cluster. But virtually free compute power won't be left idle, either. It will instead be used for lower valued tasks. Douglas Pase, PhD »

To my earlier comment I probably ought to add that IMHO Erlang needs to play nicely with existing software. I know that might add some ugliness to Erlang, but I think excluding access to existing code may create too much of a barrier for wide adoption. When C came out it played in a different space than Fortran, but as it gained popularity eventually it needed to play nicely with Fortran. C++ was inherently compatible with C from the start. Java can interoperate with C/C++ and (even) Fortran. There is a huge mass of existing software that, frankly, the community cannot afford to rewrite just because the language is different. Much of the software is potentially compatible, at least in concept, with functional programming ideals. For example, there are many algebraic functions such as SQRT, SIN, COS and such, that could be interlaced with Erlang relatively easily. On the other hand, much of the existing software deals with access to hardware and hardware inherently manages state, which is more of a problem for functional languages. However this junction is managed, it seems clear that Erlang cannot simply live in its own world. Somehow it needs to play nicely in the sandbox with other software. Maybe it does already, I don't know. Could someone who knows Erlang comment on this? (Dr. Eadline?) Douglas Pase, PhD douglas@pase.us »

As a hard core geek I would love to believe that the main thing required for a programming language to succeed is technical superiority -- good syntax, good concepts/foundations, good run-time environment and good support. Unfortunately, as a former language designer for the HPC community my experience says otherwise. I was co-author on a functional programming language (called "Flo") for a company called Floating-Point Systems in the mid-80's and co-author on the CRAFT Fortran extensions for Cray Research in the mid-90's. Both languages were designed with the HPC community in mind, both had the full support of the companies involved, both had many person-years of effort behind them, and both were received enthusiastically by their community, at least for a while. Neither language lasted more than a few years and reasons cited for their demise were never technical merit. Another functional programming language, Sisal, also experienced a similar fate. Many years of effort were poured into its implementation, a community at Lawrence Livermore National Lab used the language (at least apparently) with enthusiasm. High Performance Fortran (HPF) also rose and fell, as have many others. Having a high-quality language, compiler and runtime environment with all the necessary tools for support, at least in each of these cases seemed to be a necessary condition but by itself it was not sufficient. It also had to somehow be accessible over a wide range of architectures and a long enough period of time to develop the programming skills necessary for wide-spread adoption. It needed to be taught in Universities and it needed to be perceived as something that would be around for a long enough time that substantial SW development in that language would not be perceived as money wasted. I'm not saying this to dismiss Erlang - quite the opposite. I don't know whether Erlang is the answer to our parallel programming needs or not, but I do know intimately the requirements of parallel programming and the merits of functional languages and Erlang sounds like it has potential. If we assume that Erlang is the right combination of features and implementation, my question would be how do we make sure it doesn't fail for some of these non-technical reasons? How do we make it happen? "Build it and they will come" is just wishful thinking. »