 From London, England, it's theCUBE. Covering Discover 2016 London. Brought to you by Hewlett Packard Enterprise. Now, here's your host, Dave Vellante and Paul Gillis. Welcome back to Excel London, everybody. This is HPE Discover 2016. Paul Gillin and I are here with theCUBE. For three days theCUBE is the worldwide leader in live tech coverage. We're at the events. We're extracting the signal from the noise. Kirk Brezniker is here. He's a fellow and chief architect at Hewlett Packard Labs and very much focused on the machine. Kirk, good to see you again. Thank you. Glad to be here. Welcome back to theCUBE. So, you guys may get a lot of play. Both the labs, now part of the EG organization and obviously the machine. We've seen it evolve over the last several years. Martin gave that awesome keynote several years ago. We were all squinting in. Much has been written, but give us the update on where we're at with the machine. Sure, it's teams made astounding progress. When Martin announced at Discover Las Vegas in 2014, he had those nice 3D printouts, basically plastic block diagrams that were nice because he could walk around them. And now it's all working. We have taken that, those original concepts and turned them into our first working prototype. We call it memory fabric test bed. And all the pieces are there. High performance system on a chip microprocessors. Memory fabrics connecting up compute devices with memory devices. High performance memories. Photonic interconnects allowing us to scale tens, hundreds of terabytes of fabric attached memory in just the right amount of compute to tackle some really amazingly new workloads. Well, go ahead Paul. What were some of the top technical works of magic that you had to pull off to get to where you are? You know, the first thing is just focusing in on just what you want to do first. You know, we sort of had a couple of simple ground rules learn as much as you can, as fast as you can. But we really wanted to demonstrate all those pieces coming together. An SOC, system on a chip microprocessor, high performance microprocessor, fabric attached memory. Memory of a large pool, addressable as memory. Memory fabric to stitch it all together and then a photonic link to allow us to scale to the capacity and an energy and a foot point that we could afford. So we said that's the memory fabric test bit. Let's make sure that we're demonstrating that. Then we'll take Linux as an operating system, adapt that and generate new categories of applications that show it off. So at some degree the challenge is not trying to bite off too much but then hone in on exactly what we needed to learn as quickly as we needed to learn it and then prototype that at a scale that's interesting and with a real customer driven workloads that are meaningful. So you designed the microprocessor. No, no, we had a partner who was designing a microprocessor. What we did was design a bridge that took that microprocessor and instead of sticking it next to some memory and some IO devices and then creating a server or a blade out of it, we took that microprocessor off the shelf, wrote brand new firmware with for it and then put it on the memory fabric. So we created a memory fabric bridge taken off the shelf microprocessor and we chose one but it could have been literally any computational device bridged onto the memory fabric that adds the first element, computation, scalable computation onto a fabric. So this will work, I'm sorry Dave, this will, your design will work with any microprocessor then. I mean I assume you're talking to Intel and they're very interested in what you're doing. Absolutely and so what we've also done is we found several like-minded partner companies, system vendors like IBM and Dell and Huawei, component manufacturers like AMD and Western Digital, SandDisk. We've formed a consortium called the Gen Z Consortium, a group of companies that understand that open fabric interfaces ignite innovation and we are working together. Now the work that my team has done, the research and advanced development on our machine memory fabric prototype, that's informing what we're contributing and to with our peer group to say what should these memory fabrics look like? How should they scale? What kind of characteristics do we need them to do? So this is a long-term innovation enabler across the industry. Kirk, for decades we've drawn the storage hierarchy as a pyramid and that hierarchy has become more and more granular, different levels of caches, obviously DRIM and now of course flash and different spin speed disk drives all the way down to tape. Even one day there was optical in there and maybe still is, I don't know. One of the fundamental premises I believe of the machine is you're collapsing that hierarchy, maybe not to a single level, but you're collapsing it quite dramatically. Is that correct and can you add some color to that? Absolutely, so when we think of, we call it memory-driven computing because that was sort of the heart, understanding how memory scales and we talk about scaling memory, we really talk about scaling opportunity when we have a world's information, huge volumes of data created from IoT, industrial IoT, data rich analytic applications. What we really need to be able to do is go through this huge volume of information in a timeframe that matters and hook just the right computational devices to this memory pool to do highly accelerated super energy efficient operations on it. So our first task is to create memory that's affordable and memory arrays that we can scale to every size that we find interesting. So yeah, there certainly is that abundance of memory. But it's more than just that, it's also the well connectedness of memory. Some applications like deep neural net or machine learning algorithms, they don't need a lot of memory, but what really enables acceleration is having graphical processing units doing high performance floating point computation, general purpose processors doing shepherding and management of data resources, all pointing at the same piece of memory so they can all update things simultaneously and that's where that team gets a breakthrough. So it's all about the characteristics of memory, how we create memory arrays of different sizes and characteristics that really ignite performance increases, dramatic performance increases on existing applications. Why is persistent memory so important? So there's a couple elements of the persistence. One element is that with persistent memory, we don't have to worry about certain classes of failure. We can redesign the traditional stack that we would have database where we have application tier, middleware tier and then we get to a database tier to perpetuate business logic and business conditions and we use a database because it's a proven technology, we understand it. But it's also, it's an expensive technology, there's a lot of license costs, there's a lot of server costs, there's a lot of software too and as well as we try to write software without bugs or security loopholes in them, it's just hard. If I can take that whole tranche of software out that I'm saving customers money, I'm increasing performance and I'm using persistent memory to perpetuate business logic rather than database techniques. Now that's just one aspect. Another aspect is actually energy. If I want to retain not just terabytes of memory but petabytes, hundreds of petabytes of memory and I want to retain it in perpetuity, then what I need is a technology that doesn't take energy unless I'm actively reading or writing the memory. I don't want to have to pay a refresh tax. So you can imagine, it doesn't seem like much at the beginning, just adding a little bit of recess cycle but if you have to do it forever and on a very large memory array, it becomes material. So that's the second aspect about persistent memory, non-volatile memories that we find so attractive. So there's a lot of data in databases. So you envision like a 30 to 40 year attrition process? Well, you know, it's interesting. We think about data in databases but to date what we have is systems of record. We record just enough information to perpetuate a business logic. I'm old enough to remember having my past book and I filled out my deposit slip, I slipped it under the teller's window and she had a nice conversation as she keyed into the 10 key and she updated my account. We only did deposit balance. But now we're talking about, we have new categories of systems, systems of record, systems that are driving social media, huge volumes of data but we don't actually record that much about it. We don't require it to be mission critical. The kind of systems we're talking about now are going to generate huge amounts of data but they're also going to be mission critical because they're going to run autonomous vehicle fleets. They're going to run intelligent power grids. We need them to be reliable, available and be able to analyze incredible volumes of data in near real time. So you can decide, should the car break or should it accelerate? Should I switch on this power generation subsystem or should switch on another power generation subsystem? Totally different characteristics of data and we just really believe that when we have eight billion people, 20 billion mobile phones, 100 billion smart things, there will not be a lack of raw data. What we need to have is insight and time to make good decisions from having all that raw data. My research colleagues at Wikibon asked me for this machine segment. A couple of questions they asked me. I asked, one is of course cost. It's a big concern that people have is the cost of whether it's memristor, this architecture. Can you address cost? I mean, flash has taken the world by storm because of the consumer adoption. Can you as an architecture compete with that kind of cost and what gives you confidence? So I think the first thing that we find very competitive is that we aren't hooked to any one memory technology. As memory technologies come on, part of the real benefit of a memory fabric, something that treats whether it's a computational device, a memory device, a communication device, with one simple load store memory semantic model, is that as technologies mature, as they become cost effective, it's very quick and very easy for us to bring them into the fold. Also, I can choose the right memory technology, the right computational technology and pick and choose, but still have the performance of a purpose built memory system that's combining all those things. So for me, the ability for us to choose the right memory for the right job is very important. Something we don't really have today. Today, you buy a microprocessor and there's a memory interface on it. And different point in time, it's a different memory interface, but the microprocessor designers made a choice on computational devices and the cores, memory devices and the memory interfaces, IO devices and the embedded NICs and PCI Express. They had to make those decisions all at one time and if they want to bring anything new, they have to make all those decisions all over again and usually it's like a two year design cycle. By having a memory fabric, I can break apart those decisions, allow us to make the right decisions, just the right time enabling innovation and all those individual pieces to occur as quickly as those industries would like to do. Paul, follow up if I may. So by that logic, if you're, if for example, Memrister is less costly than DRAM and it's persistent, then you can in theory anyway, replace the DRAM and then affect the rest of the storage hierarchy because you've got a persistent layer in there. Is that the right logic? I think that is the right logic and we really come back to the application. Some applications really love the persistence of memory. Some applications love the sheer volume of memory that can be entered in. Some that well connectedness, adding their GPUs and the CPUs, all pointing to the same memory. And some applications love the fact that I can go from megabytes to terabytes to petabytes and have one simple programming model that spans those whole distances. So for me, it's always going to be a question of what application do I have, what kind of memory, compute and communications does that application demand and how quickly and economically can I pull those features together to create a solution? Addressable memory has historically been limited by the processor and the operating system. Have you broken that mold? So right now we are borrowing play that was well earned when we moved from 16 bits to 32 bits, 32 bits to 64 bits. We do windowing, we do aperture, so we take the solutions we've used before. Now what we're also doing is giving a gentle hint to our microprocessor vendors to say, you know, the window works, it helps us out, but if it wasn't there, we'd be faster, we'd be simpler. Why don't you consider addressing more memory? So instead of 16 to 64 terabytes, how about four petabytes? And it's a case of balance because right now when I add in the photonics, I end the memory capacity as we anticipate that next generation of processors. If you give me four petabytes, I think I can make a really nice balance system, one to four rack, scale, four petabytes of memory, microprocessors directly accessing every single byte without windowing, without aliasing. So if there are any microprocessor vendors out there, I'd like to give them a hint. You know, 52 bits sounds really nice to me, right after the next couple of years. The other question my colleagues wanted me to ask you is our understanding is you had to develop certain development tools to develop the machine. First of all, is that correct? And how will those development tools find their way to market and SDKs and what's the ecosystem look like? Absolutely. So one of the things we're committing is not surprising, you know, we're committed to open source community driven development and that's both on the hardware side with the GenC consortium, as well as in the software side, the Linux and the extended open source communities around free and open source software. But it's not just like we're going to write the software and we're going to abandon it on the doorstep of some open source foundation. We really wanted to be a community driven. So that's why we announced back in 2014 to start that conversation. And we've also wanted to continue the conversation around coding and technology. And the best way to have a conversation about code is to put something out on GitHub. And that's really what we've been doing. We've been pushing out tools and technology, the things that our development teams, our analytics team, algorithm teams have been using for the last two and a half years. They're out there on the GitHub and people can go to them, can download and start to experience what our teams have done. What is it like to program in large memory? What's it like to put up memory on a memory fabric to have multiple microprocessors all talking to the same memory? And we really want to make sure that we're having that conversation so that they can be just as excited as our teams are on this technology. IBM now says that quantum computers are a matter of when and not whether. Is that going to be an enhancement, a complementary to what you're doing, or is it an alternative direction? So for me, it's very much complementary. I want to enable us to choose the right computational device, put it next to this huge pool of data, aggregated data from all those things. And if I need a computational quantum annealer to do a traveling salesman optimization, I want the data to be there and put the quantum computer right there. If I want to do a GPU base, a DSP, an FPGA, a custom crypto ASIC, I want all these things to be accomplished on a memory fabric so I can quickly pick and choose assemble solutions economically that don't have the waste, don't have the overhead of the solutions that we have today. Okay, we have to leave it there, but before we go, how much does the machine cost? If we should, before we go and describe it, that HPE has sort of indicated that it's going to, the machine is not a box that you're going to buy, it's something that's a technology mainspring that's going to be utilized throughout the product portfolio, right? Yeah, I certainly agree. You know, there are technologies that we will drive sooner rather than later, like the Vixel-based X1 Photonic engine that we developed for the prototype. We're seeing, and that's an advanced development for being evaluated in the synergy, composable infrastructure. So you'll see some of these technologies sooner rather than later, but I also think that you will see, over time, more whole-cloth implementations of machine technology, high-performance compute, data analytics, those are the areas I think are most likely to be fruitful first. Great. All right, thanks very much, Kirk, for coming to theCUBE. Appreciate it. Appreciate the update on the machine. Congratulations, and best of luck, Gilmour Ford. Thank you. All right, keep it right there, everybody. We'll be back with our next guest. This is theCUBE, we're live from Discover 2016. We'll be right back.