"They built supercomputing before anyone heard of the cloud."
Minor historical pontification on my side: The term 'cloud' is only the current term for an old idea. Before cloud there was 'grid'. Before that was the Amoeba OS and other distributed OSes. Long before that, a 1960s hope for Multics was that it would be:
> ... a utility like a power company or water company. This view is independent of the existence or non-existence of remote consoles. The implications of such a view are several. A utility must be dependable, more dependable than existing hardware of commercial general-purpose computers. A utility, by its nature, must provide service on demand, without advance notice in most cases. A utility must provide small amounts of service to small users, large amounts to large users, within very wide limits. ... http://www.multicians.org/fjcc3.html
That's shortly after the CDC 6600, and before the DOE really got into the supercomputing business.
In any case, I don't know the politics of supercomputing, and my experience in that field is even older than yours. When I look at current clouds systems, and try them out, I throw my hands up, because they don't handle the types of architectures I use in my research. I do compute-heavy work on medium-sized data, with algorithms that works best with stateful nodes in a boss/worker system. Luckily for me, I don't need low latency, so building something on top of ZeroMQ is good enough for what I want, and easy to do.
Exciting to see someone that remembers all those good, old systems! I've been studying them in recent years to solve modern problems that... they already solved. Yeah, some of the techniques go way back. To be honest, I've been thinking of re-implementing a version of Globe toolkit with modern security engineering techniques to deal with our Internet apps issues.
What do you think of that? Worthwhile to leverage such an architecture?
> Exciting to see someone that remembers all those good, old systems! I've been studying them in recent years to solve modern problems that... they already solved
I saw a presentation from one of the VPs of Cray at ORNL. He spoke on the current wave of GPGPU and how similar it is to the old massively vectorized architectures in supercomputers (in particular Cray ones, since he was from Cray) from the late 70s through the early 90s. Apparently they've been able to leverage a lot of their old code in the Cray compilers for their newer GPGPU features.
Bam! Another example of people applying lessons of the past to make the present so much easier. Glad for them. Unsurprising with Cray given they're quite innovative and led the way in SIMD processing.
Minor historical pontification on my side: The term 'cloud' is only the current term for an old idea. Before cloud there was 'grid'. Before that was the Amoeba OS and other distributed OSes. Long before that, a 1960s hope for Multics was that it would be:
> ... a utility like a power company or water company. This view is independent of the existence or non-existence of remote consoles. The implications of such a view are several. A utility must be dependable, more dependable than existing hardware of commercial general-purpose computers. A utility, by its nature, must provide service on demand, without advance notice in most cases. A utility must provide small amounts of service to small users, large amounts to large users, within very wide limits. ... http://www.multicians.org/fjcc3.html
That's shortly after the CDC 6600, and before the DOE really got into the supercomputing business.
In any case, I don't know the politics of supercomputing, and my experience in that field is even older than yours. When I look at current clouds systems, and try them out, I throw my hands up, because they don't handle the types of architectures I use in my research. I do compute-heavy work on medium-sized data, with algorithms that works best with stateful nodes in a boss/worker system. Luckily for me, I don't need low latency, so building something on top of ZeroMQ is good enough for what I want, and easy to do.