Thank you very much.
Was this on?
Yeah, great.
Ladies and gentlemen, thank you for giving me
the opportunity to talk to you about our strategy and plans.
And this is striving for efficiency.
And for us, NEC, efficiency simply
means sustained performance on real applications per TCO.
That includes the cost for purchasing,
as well that this includes the cost for the power consumption,
for instance.
This works.
Now, this implies, and this is what our customers are telling
us, that we have to choose the appropriate hardware
for each type of application.
In the past, already since the last 10 or 15 years,
there was almost no site which just owned one big system.
And we are pretty aware of the fact
that there are applications which are particularly
suitable for a certain kind of architecture,
be it a cluster, be it a vector machine,
or be it a GPU type machine.
So for us to do this kind of business
and provide such kinds of hybrid solutions,
it clearly calls for a complete product portfolio, which
might be a scalar cluster or a scalar huge S&P.
We have this, which might be GPU nodes.
Matsurokasan has this.
And we successfully contributed to TYTEC2.
And there might be the need for a vector system.
Now, the last one is the thing where NEC probably
caused some irritation in the past.
I can clearly tell you, as I did the last two years,
this will continue.
And altogether, this only makes sense
if there is a seamless integration
to ease the usage of the system for system administrators
and users.
Now, why are we still believing in vector machines?
This is a little bit old.
This is Earth Simulator 2 and Jaguar
before Steve Scott just said they upgraded it.
So this is the old Jaguar.
But what you see there is that in terms of peak performance,
the Earth Simulator was certainly not favorable.
In terms of FFT, it was OK.
In terms of stream, we were slightly off.
But nonetheless, we had a nice, high sustained performance.
But if you then scale this to the power
consumption of the two systems, you
find that the SX system, the Earth Simulator 2,
was more power efficient, much more power efficient,
on the FFT.
And it was equally power efficient on the stream.
So what does this tell you?
For me, a real application is sort of a spectrum.
The worst case is memory very intensive, the stream.
And the other one is relatively well-behaved.
That is something like an FFT.
So a real application should ideally
be in between those two factors, between 1 and 2.
So this tells you that a vector system can
be pretty power efficient.
We know this pretty well because there
are two cases in Germany where we sold an SX8 and an SX9
where we won because many vendor could provide the performance
requirement within the budget.
But we were the only one to provide the performance
requirement within the power envelope of the site.
That's largely unknown, but it's a fact.
Now, we want to go for better power efficiency
with the next generation.
And that is relatively easy because we
know from the SX9 it was a huge SMP,
and 70% of the power consumption was in the memory interface.
Now, the system already had a high sustained performance
on real applications.
I told you, we won with this.
And it was been by efficiency, as I have
proven by this comparison before.
Now, we have to go on.
We have to proceed.
We will enhance the system.
It will have an enhanced vector architecture,
but it will be the same kind of architecture, namely vector.
We will certainly look for technological innovation.
And we have to slightly adapt to parallelization paradigm
because we are going to save on these 70% of power consumption
in the system.
Now, it doesn't work.
Because the 70% were in a huge crossbar.
That was a big SMP type system with huge memory bandwidths,
a totally flat shared memory.
So that was a total 560 LSIs.
16 of those were CPUs.
The rest was crossbar.
Now, the idea is we make a multi-core vector chip,
and then we save on the crossbar.
And therefore, we can save at least those 70% plus what technology
will add to this on top.
So the next generation system will be a single chip multi-core SMP node.
Each SMP node is one chip.
It will be attached to standard DIMMs, and memory controller,
and all these things are on chip.
It will have four cores and feature 250 plus gigaflops.
The single core will be in the range of 60 gigaflops.
Now, whoops, that was too fast.
Now, you know what the features of the old conventional SX6 series was?
That was always the compatibility from the generation.
It was a vector architecture.
It was always featuring large bandwidths.
This is the virtue since ages of vector machines.
It was the high performance cores.
Our individual cores typically were on well-suited applications
much faster than anything else, and this is the first step
to tackle scalability issues of user codes.
They were featuring large shared memory and high-sustained performance
in the double-digit range.
Now, the future is slightly different.
Almost everything is taken over, but we will have this one chip SMP node,
which is sort of a smaller type SMP, and we will have, therefore,
to scale to higher numbers of nodes in the future.
That should not be a problem.
Now, how do we position this?
The next generation will have a core, which is about as fast
as an earth simulator one node.
For me, this is somehow surprising and exciting at the same point,
the individual core.
I mean, I was there when we had the earth simulator.
And the whole chip will be in the range that we had before with an SX8.
So it's somehow exciting, because I know both systems, they were damn healthy,
and we have good reasons to believe that the next generation
system will also be very healthy, means very balanced architecture.
And then, the typical architecture for the individual core and four cores
will make up one chip, and therefore one SMP node.
They will be connected with a 256-something gigabyte-per-second bandwidth
to the main memory.
And the memory controllers and the RCUs, that is our interface
to the crossbar, to the messaging for MPI, and the interface for the IO.
This will be all on one die, and therefore it will be pretty efficient
in terms of power consumption, in terms of latencies,
in terms of utilization, and all this.
And what is important is we keep one byte-per-flop bandwidths.
We still want to continue to be the bandwidth leader in the industry.
And altogether, these systems will then be equipped with IXS interconnects.
We will have a standard cluster with 512 nodes, which is 131 teraflops.
But please don't forget, we don't strive for peak.
We want real user performance.
And if you want to compare us on LIMPAC, we will always be in bad shape.
But if you take real user code, that is OK.
And then there will be an enhanced cluster, which is somehow just
a different kind of IXS topology.
And that will be a four-petaflop machine with 16K nodes.
This IXS is our proprietary IXS interconnect.
It's not infinite band.
And it has some features.
For instance, it has a fast global communication.
And that is how the packaging looks like.
Each individual node, which is one chip, comes on a card with 31 centimeters
by 11 centimeters.
On the back side, you have the memory dims, which are standard memory.
Eight of those are packaged together to connect to the IO cards, PCI.
And the individual chips of the CPUs, they are cooled by water.
That way, about 50% of the cooling comes by water cooling.
The other 50% will be air cooling.
This is something which is increasingly important.
Cooling is very often, nowadays, limiting at the side.
You might be in this situation where you cannot install more just because you
don't have the cooling capacity.
And 64 of those nodes, that means eight of these eight node units,
will make one rack, which is 16 teraflops.
Please don't compare this to a rack of Westmere or something.
And this will be 30 kilowatts.
And that way, it's about 10 times more power efficient than the SX9 was.
You see, that is really our focus, the power efficiency.
This should be a green machine.
And then we have something which is really striving for our future.
I told you, the real site needs everything.
It needs a little bit of scalar.
It needs scalar nodes with GPUs.
That can be a very good machine.
And there is no application portfolio which can only fit to one machine.
And therefore, we are thinking about usage environment where you
are combining these things.
This is a huge requirement for software.
This means the batch scheduler needs to know about it,
and you have to have a parallel file system.
So that is all in the works, and it will be delivered with the next generation.
Now, the most important thing, I think, the NEC top management
has advised the development to investigate further.
We know that we really caused confusion in the market.
We are now already starting to think about the generation
after the next generation.
And we will carefully think about everything, and we know our user input.
Everything is on the table.
That means technology, choice, architecture, and also issues of market economy
are something that we are going to think about.
Thank you very much.
Many thanks, Dr. Fischer.
The first question, please, Satoshi.
So bandwidth is very important, as Seymour Craig put it,
who invented vector computing.
And machines like Safari 2, we have a number of applications
that are sustaining petaflock range performance already.
In fact, many of them.
Amenable, those are pretty much realize the fact
that we have bandwidth in a system sustained by effective processing
that's modern version being done by GPUs.
Now, when I look at your parameters that you presented today,
they don't look very attractive at all to me.
Because I can't tell you, because I'm under NDA and all that.
But when I look at the numbers, none of the numbers I see
are compelling enough that I should be investing
into a proprietary architecture, whereas I can get very similar performance
or even better on GPUs and mics.
So what would be your real strategy, given that now you have competitors
and the vectors in this commodity field, which could be as good or even better
than yours?
First of all, if you look at the pure numbers,
I can understand that they are not compelling to you.
Nonetheless, I believe that this architecture, also
the usability of this architecture, is appealing enough
to make us win in quite some projects with a set of user codes.
You are right.
We have to be very cautious, and we have to be very good.
Also, our benchmarkers have to be very good.
But we wouldn't do this if we wouldn't believe that we could not win.
Nonetheless, there will be competition.
It will be fierce fights.
We are aware of this, and we are looking forward to it.
The second question from Happy Cetole.
Thank you, Dr. Fischer.
I think you are closing remarks that you bring in confusion to the market.
I'm one of those people who are confused.
I think NEC has been doing very well with vector machines,
and your success, especially with the Earth Simulator 1, it's quite evident.
And why would you really start getting into the oversubscribed x86 market
whilst you had such an advantage rather than focusing on what you know best?
Sorry, perhaps I didn't fully understand.
This was about x86-type memory bandwidths per performance.
That is your point here.
OK, thank you.
Well, in fact, in terms of power consumption as well as in terms of cost,
the bandwidth is a very important thing.
It's a very important contribution.
And we learn that we are fighting there in a way which is sometimes not profitable.
So we have to adapt, and therefore, since ages, this is being reduced.
Now we are forced even more by the power consumption.
We could build machines which have a better ratio,
but then you have to think, for instance, about the pin count and such things,
because interface to the board is important then.
You have seen this with x69.
So that is a difficult way to go, and it's a costly way to go.
So we have to find other things.
Now, we are not totally neglecting this.
We had with the x69 our first implementation of what we call the ADB.
Think about it as a vector cache, but it's programmable.
We didn't want a pure cache, because this somehow is hard to control by the user sometimes.
This vector cache, the next generation will be in this NGV.
And we learned quite some lessons.
To be honest, we learned also lessons that were not so pleasant.
But the next generation ADB will definitely be improved.
And moreover, our software, our compiler, will learn more about automatically using it.
So that way, you are using locality in codes.
And most codes that I personally know from physics and meteorology and such things,
they exploit some data locality.
So if we think about, let's say, a factor of two of cache re-usage,
which is normal on good code on scalar machines,
we are in fact something like two byte per flop and not just one byte per flop.
So I believe that this data re-usage in this ADB is a key to the future performance
for our machine as well.
It is present in codes.
It's present basically in the physics.
It's a matter of physics that there is data locality.
So I think we have a good hope to cope with this.
Otherwise, it's going to be very expensive.
We could build something more like eight byte per flop, but nobody wouldn't buy.