So, good afternoon. I'm the last speaker, I guess. So, I'm here to talk to you a little
bit about some of the work that we're doing on the software front because, as been pointed
out and discussed for several years, it's really the application people that are taking
the brunt of this scaling problem. So, we are – I'm going to tell you a little bit
about what we're doing to try to make that as painless as possible and allow for experimentation
for some new methods that might be required to actually make this jump up to the next
level. And so, part of what we're doing is trying to make the future available today.
And we are coming up with a common software stack structure that spans across all of our
platforms. And it starts, really, with a focus on the application people. And we want to
be able to support a variety of programming models and programming styles and some of
the new PGS languages, maybe even in combination with MPI, right? What is the right way to
actually try to conceptualize an application into this space? And so, we are trying to
standardize what the application people see from the tools and the workbench, their development
environment, allow us to work on some of the new application models and languages,
and to allow the most flexibility in how we do that piece of the work. We are making the
middleware across all of our platforms consistent. So, if somebody wants to start experimenting
with a new language or just experimenting with UPC, they don't have to choose which
one of our platforms they wanted to experiment with. They can write their UPC code and they
can run it on a power system or a blue gene system or an X86 system. You could take advantage
of the various characteristics. Maybe when you're doing proof of concept of your science,
you might use the power system because it might be easier to work on. Or you might pick
the X86 system because you know of ISV codes or libraries that will help you, right? And
then when you want to start thinking about, so how would I actually scale this out, because
I need to get to somewhere on the order of a billion threads by the time I'm finished,
how would I start scaling out? You can start running some of this on your blue gene system
and see what restrictions you run into and how you might think about it differently.
So we're trying to make this all common with this common runtime library. Now, another
thing that we're doing inside that's not actually a function of the application people
so much, but there will be a feedback, is what are we doing about energy usage? Because
energy optimization at the application and at the hardware system level is going to be
one of the key challenges. So part of what's in here as our low-leveler resource manager
and monitor is something that is monitoring the energy utilization as your application
runs. And we are turning on the hooks to look inside the CPU, inside the memory, what are
you doing with IO? And we will give you files of profiles of what's happened to your application
as you run on these various platforms so that you can start to experiment with, is there
a way for me to restructure how I actually do my coding that helps me minimize some of
these bottlenecks? Because if you don't have a feedback loop, you actually won't know if
you're making progress. So part of what we're doing in that blue middleware is to try to
expose as much as we can the things that will become required when we get to exascale,
but we can actually experiment and run with them now on the current set of hardware. So
another thing that we're doing with this common runtime is trying to take use of the best
we've had on these various platforms. So for instance, the new API I'll show you about,
it includes non-blocking communication on all of our platforms. We have it on BlueGene,
we didn't have it on Power, so now we'll have it everywhere. And another important
piece I think of this experimentation, and I use PGS and MPI as the example, but I think
we want to be able in the runtime to allow application people to mix how they use the
various programming styles inside of one application. And so this API that we've developed that
I'll talk to you a little bit about, allows you to actually play with this at the language
level, at the compiler level, and across all of our platforms. So we call it the parallel
active message interface, or PAMI, and we currently have two versions of MPI running
on it. We have an APGAS, so APGAS is an asynchronous extension to PGAS that we are working on. And
so all the PGAS languages are being written, and the compiler is being written, to run
on that interface that runs over our API, that lets you run on any of our platforms
using the same code. And we've made it available so that the API is known to other language
styles, and so you can develop experimental languages or experimental programming models
to run on any of the platforms to see how some of your ideas might work. And we're trying
to do that to minimize the amount of work you need to do if you want to see if it's
platform dependent, how your thing works. You can try it on the various platforms without
having to change your code. All right, so another thing we're doing with that same set
of software is we are looking to see, so what would you do in a cloud environment? Because
a lot of the requirements in that middleware actually are usable in a cloud environment.
So if I take that picture, and I'd now draw an oval around the pieces that are the system
manager part under XCAT, the resource manager and scheduler under load leveler, and the
file system under GPFS, and I pick them out, I can extract that from the software stack
and build a cloud management system out of that same piece. Now, what's important in
the cloud, right, is the ability to put usable APIs from both the user and the administrator
into the view of the system. So the provisioning engine and the workflow manager both are accessible
through APIs up to this variety of services that include the standard, you know, sort
of configure and load and launch pieces. But we're putting the energy monitoring and management
into this interface as well, because even in the cloud environment, we think people
are going to want to know what kind of energy they are using. You could even think of putting
in some provision to charge people by the energy they use rather than the flops that
they use. If you want to try to modify behavior, it's often good to have some kind of forcing
function. And so if we want people to think about energy, then making them aware of the
energy usage is a way to start that. So that's part of what we have, and it's available upwards,
and it's available downwards. And it's available currently on the iDataPlex, but with Blue
Gene and Power as follow-on. So we have a cloud system built around the same set of
software where one of the interesting things I think about the way this cloud could evolve
is the notion of a multi-cluster cloud, right? Because in our systems, in our big systems,
in the data centers, load leveler and GPFS have always been multi-cluster, right? For
ease of management, for ease of use, we've always liked the idea that you could have
visible, a single work queue that by job class divides itself into work queues for the various
machines or clusters in your data center. We like multi-cluster GPFS because it's very
useful to have your data visible by all of your applications. So if you have a file system that
spans the clusters, then you can create the information from the results of work running
on one cluster and make it available to applications visualization or analysis or
analytics on another cluster. And so this notion of a partition LAN inside of the cloud
lets you create isolated clusters that you can look at, manage, provision, and charge back to
in separate ways across your organization. And the workflow manager would know about
where these pieces are, which kind of job class you would like to be using. So if one of the
clusters was an x86 cluster and one was a power cluster, you make them different classes,
and when you submit your job, you can decide which one it goes on to. The provisioning engine
would know about the characteristics of both sides. And so this looks like a way that you
could make use of your entire data center and partition your users away from each other if you
wanted to. So I've got 30 seconds left, but thanks. Thank you, Dr. Grice. First question now to
Hepizitouli. Thank you, Dr. Grice. I think your announcement of a unified
management of clusters is music to my ears, especially I've got a zoo of IBM systems,
PowerSeries through Bluegene, and it has been a nightmare to manage allocation of those resources.
But this music also gives me a little bit of scare. What's going to happen with the license
now when we do this? Especially that you mentioned here like the collaboration with Open Source,
and I think also on that, are you aware of, say, on the energy optimization, some of the existing
tools that do similar sort of tasks? So that's a multifaceted question. So I don't actually do
pricing, and I'll get you one of our pricing people to let you know what the policy would be for
pricing. But in terms of trying to make it easier to use and minimizing the resources that you
physically have to have, I think we can do that. In terms of the Open Source, the tool set actually
has the ability for putting plug-ins in to make use of exactly what you said. There are advances
happening everywhere, and part of why we wanted to open this up was to be able to get contribution
from the community faster than trying to do it ourselves. Where I think the value to our resource
manager is in the ability to get close enough to the hardware to collect the information,
and then we'll put the file out, and then anybody that's got analyzers of what that means,
you can plug it into the data and have at it and make progress. So I don't think we're trying to
get a lock on what you do with the data. We are trying to make it available to the users so that
they can figure out what's going on, because it looks like a critical piece of trying to move
forward. And the last question of our inquisitors from Mr. Schumann. Thank you very much for your
presentation. When I look at that, I have to say that's how it has to be, right? But I ask myself,
why isn't that today, and why wasn't it like that in the past? The answers to that presumably are
manifold, and some of them might be technical reasons, some that one didn't have a strategy
of seeing it all together when one developed these tools. But I'm simply asking myself,
are these obstacles that were reasons in the past of why the software stack doesn't look like that,
are they overcome? Why now? Why not before? So I think there are a couple of reasons of why now.
I think for the few years prior, we were more in a computer science exploration phase, right? We
really didn't know what the structure of being able to move forward would be. And so we didn't
tie the sort of features of the machines down in a way that would sort of inhibit
the forward progress. Where we think we are now is we understand the architectures to some extent,
and the features we need to go forward. But it's clear that the application software
is going to be the problem. So we want to make sure that we now enable that interface as a standard
so that we can make as much forward progress as fast as possible on the scaling and application
end. And we will maybe be a little less efficient in how fast we can migrate underneath, but I
think it would be the right trade-off, right? It's to slow down features you might put into
the hardware to make sure that it's consistent when you look up.