 We're here inside the cube for special exclusive coverage, extended coverage of HP's project moonshot press event. I'm John Furrier with my co-host Dave Vellante. Dave and I are on the ground doing the analysis and the commentary and talking to folks who were in the room, on stage, part of the HP big press event. I'm sure the journalists, Wall Street Journal, Reuters, all those guys are running out, banging out stories. We've got our post up, I wrote a post. I think it should be up. We've got pictures. Nile, you're with Canafits Gerald, which is up there kind of as a testimonial, right? You guys also do a lot of market analysis, but you're kind of demoing or talking about the benefits. Well, yeah, we're really excited to be evaluating the technology and there's a lot of trends driving our looking at it. Dave mentioned that high-frequency trading isn't necessarily the first application that might come to mind and certainly a high-frequency trader. The first thing that comes to mind is I care about low latency. Send me your biggest, baddest machine, make it go as fast as it can and it's all about reacting to each event as quickly as we can. For the other guy. One trend they didn't talk about on stage and talked about all the buzzwords. I actually used the word Web 2.0, which I kind of was like, guys, FYI, that's kind of history now. I wouldn't use that buzzword if I was HP in the marketing, but anyway, they talked about cloud, they talked about big data. I didn't hear real-time and now you guys have focused on real-time. Well, we're focused on real-time, but you have to follow the data through its life cycle. We have our algorithms running and we're trying to react to market data as quickly as we can. But when you've got billions of events every day and you need to run analysis in the course of a day over all that data, that's a lot of data in memory. But then what happens is, well, we want to run that same analysis or some new ideas over all the days in history. So there's a transition point there where we go from being really latency-focused to being really throughput-focused. So we want to research some ideas. You have some quantitative analysts who's thinking about, okay, this model, maybe I can look at the data in this way and they want to run an experiment. What if simulations? Exactly. So they want to run an experiment and what they want to do is say, okay, grab all the data we have and run this experiment. So immediately they have a huge appetite. So take us through the sausage factory as we were making the sausage. We're going to go through the whole range where you guys do all this stuff. What goes on to make that happen alternatively to what was announced today? Because people are trying to make sense of this announcement. Why is it such a game changer? What's the old way and how this new way changes that? They mentioned 10 racks down to a half a rack. And you just paint a picture of how this all works. Sure. So people that build teams like ours and build high-frequency trading systems, we are very concerned with a few different types of metrics. We've talked a lot about the low latency one, but that's just one metric that we care about. So at each point in the data life cycle we have systems that we write and typically we write all our own software to do this type of processing where we need to say look at performance or we need to look at, okay, can we keep all the data in memory and can we process it quickly and it might be very compute intensive. So we'll look at, say, GPUs or we're really excited about Intel Microprogram. But when you get to the throughput problem it's really about how quickly can you get through all of this data, right? So it becomes something that looks quite like the traditional scale out. Well, I say traditional, but you know. Today's a ton of servers. Exactly. And then what you care about are metrics that involve dollar signs. So can we be cost effective about doing this, right? So, you know, a third of your cost is really coming from power for whatever reason, right? It's somehow linked to the power. That's one of the biggest costs when you're operating at scale. So anything you can do to have higher throughput while keeping your power the same or even better lowering your power usage while you're raising your throughput is a good thing. It's a huge deal. It's a huge deal. Not a little deal. You multiply it out by all the simulations you want to do and all the machines that you'd like to have to run those on. So it's coming like Facebook, for example. I mean, what's their power challenges? I mean, they must have massive. They have 800 million people on the network. So that's an example of someone who would take advantage of this. Exactly. And they will have partitions of their global infrastructure that are dedicated to these kind of throughput tasks. So some will be dedicated to the web-serving, the parts that you interact with directly. But there will also be other partitions that are analyzing all that data that are doing their offline analytics. And it's much the same kind of challenge that we would face. So we have a lot of people watching here that this is new to them. So we're here with Nile Dalton, who's with Cantor Fitzgerald. He runs High Frequency Trading. We're talking about using a new form of processor, low power processors to solve big data problems, really, is what you're talking about here. What exactly are you doing with these processors, CalZeta and HP? It wasn't clear from your remarks today. You actually have them in-house and you're testing them? You're actually using them in production? Can you talk about that a little bit? No, we're not using them just yet. So I've actually been looking at ARM for a while now, because it was clear to us that when you look at low power high throughput, that ARM was going to play a part. So even before we started talking about CalZeta, we were already looking to ARM and we brought up a little piece of our software on ARM processors. And it's actually remarkably straightforward when you have a standard Linux environment and the standard tool chain. So you see compiler and you do buggers. It's actually pretty straightforward for a good programming team to bring up their code in this environment. So, you know, we have done some experiments and we've been talking with CalZeta really about the fact that you genuinely do need to build a server class chip, right? So if I take a prototyping board with an ARM processor, they're not built for high throughput. They don't really have the IO capacity. The chips don't have large caches. They don't have the kind of integrated high bandwidth low latency interconnect that CalZeta are building into the chips. So I've been talking a lot with CalZeta really about what needs to be different when you're taking that low power technology and really scaling it up to a server class processor. So we're still in the middle of that. So that's the secret sauce that they bring in. They're obviously in the lead or they wouldn't be here on stage with HP. Now we talked about energy instead of a third of the cost or probably at least a third of the cost over the life of these systems is goes to energy and power and cooling and all the infrastructure surrounding that. What about software cost, software development cost to optimize the software to take advantage of these new processors? Can you talk about that a little bit? Have you considered that? We certainly have considered it, but can you share some metrics with us? We're very focused on that. I think the thing to remember is when you need to drive performance inefficiencies across this data lifecycle, so it's not just a challenge in the throughput end to optimize our code. We also look at optimizing our code for better performance on hardware we already have but also where the hardware is going. So there are new extensions to the X86 and we'd like to be very aggressive about adopting those. So when Intel innovates with a new vector instruction set we're wanting to take advantage of that straight away. So it's very much a process of understanding where the hardware is going and understanding that you need to have an ongoing process of tuning your software and tracking your metrics and making sure that over time you're getting closer to where you need to be. If you look at some of the places where, for instance, you might be very floating point intensive, compute intensive to kind of a place where you'd be tempted to use a GPU, you have exactly that same problem. And that's one of the reasons, for instance, I'm excited about the Intel Mic Program, is that they're promising to make that easier by using standard instruction set for us. So really across that lifecycle and particularly in throughput when I look at ARM, it's an ongoing thing you want to do to improve your metrics. Now, what's really important is the ability to get your code up and running quickly. And that's why we depend on standard environments. So having Linux, having the standard tool chain that lets us get up and running quickly. And from there you can start iterating. And that's just not something you do once. It's something we actually continuously do as we change our code and fine tune it for the particular platform and platforms over time. So it's an ongoing process, not just a one-off thing. It's the same for all the platforms, as far as I'm concerned. All right, Niall Dalton, thanks very much for coming on theCUBE. We're on a very tight schedule. I appreciate you stopping by. And good luck with...