1 00:00:00,000 --> 00:00:06,440 We are at RSCC 2008 in Orlando, Florida. We have another special guest. Would you like 2 00:00:06,440 --> 00:00:07,440 to introduce yourself? 3 00:00:07,440 --> 00:00:12,020 No. Yes, I will, of course. Sorry, it's been a really long week. 4 00:00:12,020 --> 00:00:14,920 I imagine so. I'm starting to feel the fatigue myself. 5 00:00:14,920 --> 00:00:20,940 Hi, I'm Grady. What is my title these days? So I'm an IBM fellow, which means I'm kind 6 00:00:20,940 --> 00:00:21,940 of a free radical. 7 00:00:21,940 --> 00:00:22,940 That's right. 8 00:00:22,940 --> 00:00:27,520 And I moved over to IBM Research, and so my official title is Chief Scientist of Software 9 00:00:27,520 --> 00:00:32,020 Engineering for IBM Research, which basically means I keep doing the same thing I've been 10 00:00:32,020 --> 00:00:33,520 doing the last multiple years anyway. 11 00:00:33,520 --> 00:00:37,520 Absolutely. I see why you gravitate towards more of a homegrown title like Free Radical. 12 00:00:37,520 --> 00:00:38,520 Free Radical, yeah. 13 00:00:38,520 --> 00:00:39,520 It's much faster to say. 14 00:00:39,520 --> 00:00:40,520 Exactly. 15 00:00:40,520 --> 00:00:43,520 Well, when Nick D'Onofrio told me I was to be a fellow, he said, "Grady, you've got two 16 00:00:43,520 --> 00:00:47,520 jobs. Invent the future and destroy bureaucracy." That's a great job. 17 00:00:47,520 --> 00:00:51,520 So we were just in a meeting with a bunch of analysts, which there was some exciting conversation 18 00:00:51,520 --> 00:00:54,520 there. And one of the things I wanted to ask you about, because you've mentioned it several 19 00:00:54,520 --> 00:01:00,520 times, was to, everyone seems to be sort of freaking out about multi-core stuff. And, you 20 00:01:00,520 --> 00:01:05,520 know, first off, I mean, what do you think, where's that freaking out coming from? Like, 21 00:01:05,520 --> 00:01:10,520 what's the motivation for it? I mean, it almost seems to be, it's sort of like a Y2K level 22 00:01:10,520 --> 00:01:13,520 of like, things are going to fall down. Like, get your water now. 23 00:01:13,520 --> 00:01:18,520 I think the freaking out bit, much of the fear comes from simply the fear of the unknown. 24 00:01:18,520 --> 00:01:25,520 People do see a cliff they're about to either jump across or fall down. And that cliff being 25 00:01:25,520 --> 00:01:30,520 the end of the frequency scaling wars. It's quite clear that we're getting to the point in 26 00:01:30,520 --> 00:01:35,520 the foreseeable generation that we really can't push our processors that much faster or make 27 00:01:35,520 --> 00:01:40,520 them that much smaller. As I spoke about in my keynote the other day, you know, right now you 28 00:01:40,520 --> 00:01:45,520 can put a transistor within about a hundred atoms by ten atoms. And we see the technology 29 00:01:45,520 --> 00:01:50,520 ahead of us where we can push it down to one transistor for every ten atoms. Once you start 30 00:01:50,520 --> 00:01:56,520 getting to that point, which is not going to be that far away, you run across quantum effects, 31 00:01:56,520 --> 00:02:01,520 which we're actually starting to see already, as well as problems of heat dissipation. And so when you get to that, 32 00:02:01,520 --> 00:02:07,520 you just can't pump these things any faster. And that means we see a tailing off of the available 33 00:02:07,520 --> 00:02:13,520 computational cycles. You know, Vista version 25, it's probably not going to run on our existing 34 00:02:13,520 --> 00:02:18,520 processors. We won't comment about the current version of Vista, but that's another story unto itself. 35 00:02:18,520 --> 00:02:23,520 So as you look at that cliff and say, hmm, I'm going to reach a plateau of computational cycles, 36 00:02:23,520 --> 00:02:28,520 yet I'm doing so many things to eat those cycles. Things like, you know, XML eats a lot of cycles. 37 00:02:28,520 --> 00:02:33,520 That's why we see specialized coprocessors for it. Just the fact that I have more transactions 38 00:02:33,520 --> 00:02:39,520 I need to push out all the time. The fact that I'm processing so much more data. I spoke of the 39 00:02:39,520 --> 00:02:43,520 trends in the storage of the fact that we'll see things like racetrack memory, which will 40 00:02:43,520 --> 00:02:48,520 push us to around perhaps 20,000 gigabytes per square inch. And once you have that amount 41 00:02:48,520 --> 00:02:53,520 of storage, it requires a whole lot of processing. And people are therefore fearful of saying, hmm, 42 00:02:53,520 --> 00:02:57,520 how do I take my applications and move them to this more intimately concurrent model? 43 00:02:57,520 --> 00:02:58,520 Right. 44 00:02:58,520 --> 00:03:02,520 We don't have the people that know how to do it. We don't have the tools to do it. We don't have the processes. 45 00:03:02,520 --> 00:03:04,520 There's a tremendous fear of the unknown. 46 00:03:04,520 --> 00:03:07,520 For a long time sort of software, sort of led hardware, if you will. 47 00:03:07,520 --> 00:03:08,520 Yeah. 48 00:03:08,520 --> 00:03:12,520 But it seems like the fear here is that the hardware people have come up with something that's 49 00:03:12,520 --> 00:03:18,520 way ahead of the software people's abilities, which is -- and so the machines that people will be writing software for, 50 00:03:18,520 --> 00:03:22,520 they're not really used to that kind of thing, and there's not -- there won't be another option. 51 00:03:22,520 --> 00:03:27,520 There won't be another option. Right. This is an irreversible trend. And the organizations 52 00:03:27,520 --> 00:03:32,520 that have been hit with this first are the gaming communities, because the current generation of 53 00:03:32,520 --> 00:03:38,520 game consoles, the PlayStation 3 and the current Xbox and all this, are all based upon the cell 54 00:03:38,520 --> 00:03:42,520 processor, which is an 8-way asymmetric processor. So this is a community that, for a variety of 55 00:03:42,520 --> 00:03:47,520 reasons, has been pushed in the direction. They eat a lot of cycles, and they're the first ones to face the 56 00:03:47,520 --> 00:03:51,520 problems of multi-core development. And there will be others who are not far behind them. 57 00:03:51,520 --> 00:03:57,520 Another factor that's pushing people in this direction is the sheer energy costs. That having a server 58 00:03:57,520 --> 00:04:02,520 farm, a data center, that has, you know, tens of thousands of servers, generates a lot of heat and 59 00:04:02,520 --> 00:04:07,520 eats a lot of cash in terms of energy. So there are opportunities for actually, you know, greener computing 60 00:04:07,520 --> 00:04:13,520 as you move to multi-core as well, and that economics will push people in that direction. Yet again, we're not, you know, 61 00:04:13,520 --> 00:04:19,520 well suited as an industry to know how to deal with this. Is it languages? Is it just algorithmic skills? 62 00:04:19,520 --> 00:04:23,520 Is it pattern libraries? Is it pushing into the middleware or compilers? 63 00:04:23,520 --> 00:04:23,520 Right. 64 00:04:23,520 --> 00:04:25,520 Probably all four of those things. 65 00:04:25,520 --> 00:04:29,520 You know what I mean? It makes me think of another interesting question. I mean, what's sort of the, like we were 66 00:04:29,520 --> 00:04:33,520 talking about people won't know how to deal with this and so forth and so on, but what do you think the baseline 67 00:04:33,520 --> 00:04:37,520 is of what we do know how to deal with as software developers? 68 00:04:37,520 --> 00:04:41,520 I mean, not to ask an impossible to answer question. 69 00:04:41,520 --> 00:04:43,520 The common mediocrity is we know how to bang rocks together. 70 00:04:43,520 --> 00:04:45,520 Right, right, right, right. 71 00:04:45,520 --> 00:04:51,520 Well, you're asking a question like how does one make sausage? You really don't want to know the answer to that question. 72 00:04:51,520 --> 00:05:02,520 You know, the web has led us to the point where a large amount of the community is really comfortable with programming in the presence of relatively loose concurrency. 73 00:05:02,520 --> 00:05:03,520 Right. 74 00:05:03,520 --> 00:05:16,520 And modest, you know, time kind of requirements. In most of the things we do, the delays of the web transactions themselves are overwhelmed or actually overwhelm the amount of computation that goes on. 75 00:05:16,520 --> 00:05:17,520 Yeah. 76 00:05:17,520 --> 00:05:29,520 So we have, you know, we have some sloppiness there. And to some degree, the amount of computational cycles we have in this abundance of bandwidth and abundance of storage has enabled us to be very sloppy. 77 00:05:29,520 --> 00:05:30,520 Right. 78 00:05:30,520 --> 00:05:35,520 And the problem is with the end of the frequency scaling war is we can't be as sloppy and that's what's scaring people. 79 00:05:35,520 --> 00:05:42,520 Yeah, that is interesting that there does seem to be the web introduced, like you're saying, sloppy programming. I mean, it worked, right? 80 00:05:42,520 --> 00:05:43,520 It works. 81 00:05:43,520 --> 00:05:50,520 And now it seems like there's a challenge of maybe we have to get back to more precise programming to pick some adjective that's, you know, anonym for sloppy. 82 00:05:50,520 --> 00:05:53,520 Right. And, well, I don't mean sloppy in a pejorative fashion either. 83 00:05:53,520 --> 00:05:54,520 Sure, sure. Absolutely. 84 00:05:54,520 --> 00:05:55,520 It just means one can be loose. 85 00:05:55,520 --> 00:05:56,520 Right. 86 00:05:56,520 --> 00:06:04,520 And in fact, if you do any studies of systems works, there's a delightful work by Herbert Simon in his book, The Science of the Artificial, 87 00:06:04,520 --> 00:06:08,520 in which he talks about resilient systems tend to be loosely coupled systems. 88 00:06:08,520 --> 00:06:15,520 And that's one of the reasons why I think the web succeeds so well, because it is a good example of those kinds of systems. 89 00:06:15,520 --> 00:06:25,520 And yet, as you start finding greater constraints, in this case, you know, fewer computational cycles and unit processors, then that changes the perspective for us. 90 00:06:25,520 --> 00:06:26,520 And that's what's scaring people. 91 00:06:26,520 --> 00:06:27,520 Right, right. Yeah, that makes sense. 92 00:06:27,520 --> 00:06:33,520 And it's not that we have to become, you know, more precise. Well, we do have to become more precise, just less loose. 93 00:06:33,520 --> 00:06:39,520 Google's a good example in this and they've, you know, invested a lot in intimately concurrent systems. 94 00:06:39,520 --> 00:06:44,520 They love multi-core systems because they have a problem that's easily optimizable to that point. 95 00:06:44,520 --> 00:06:49,520 That there is a tremendous amount of natural concurrency that goes on within the Google problem domain. 96 00:06:49,520 --> 00:06:55,520 The difficulty is that there is not so much natural concurrency that exists in your average enterprise transactional system. 97 00:06:55,520 --> 00:07:05,520 Right, right. So the last question I was interested in saying, and another thing that you talked about in the little conversation or the, I always think it's funny they call it a round table, but we're here at a rectangular table. 98 00:07:05,520 --> 00:07:06,520 We're at a rectangular table, yes. 99 00:07:06,520 --> 00:07:08,520 At the rectangular table discussion. 100 00:07:08,520 --> 00:07:17,520 Was, you were talking about how when you had done the initial work with UML, you weren't intending it for it to be a programming language. 101 00:07:17,520 --> 00:07:25,520 Or even if I can, like, maybe put words in your mouth, sort of a direct way of, I don't know how you would, whatever, model-driven programming. 102 00:07:25,520 --> 00:07:30,520 And I wonder, I mean, you didn't necessarily allude to what you're thinking of that is nowadays. 103 00:07:30,520 --> 00:07:38,520 And I'm curious, like, what you think of the idea of something other than typing in, you know, the language that you're doing when you're coding. 104 00:07:38,520 --> 00:07:42,520 Sure. Well, the notion of domain-specific languages is, I think, what you're alluding to. 105 00:07:42,520 --> 00:07:52,520 I believe it to be the case, and I've always felt this, that the UML is quite suitable as an execution language for certain narrow domains for which the semantics are well-defined and the platform is well-defined. 106 00:07:52,520 --> 00:08:00,520 That's why UML, in terms of model-driven development, has gotten traction in the embedded space where state machine semantics are very, very well understood. 107 00:08:00,520 --> 00:08:08,520 As you start moving toward more difficult domains like business engineering, well, there's the whole BPEL versus UML controversy. 108 00:08:08,520 --> 00:08:14,520 I always thought that was kind of curious because I found the UML semantics to be quite sufficient to express business rules. 109 00:08:14,520 --> 00:08:18,520 It was just different than what that culture normally expected. 110 00:08:18,520 --> 00:08:25,520 The difficulty there in using the UML as a direct execution language is we don't have control over the platform against which this runs. 111 00:08:25,520 --> 00:08:28,520 Those platforms are so complex and so heterogeneous. 112 00:08:28,520 --> 00:08:35,520 You may be able to do it for specific instances, but to have a generalized solution is very, very difficult indeed. 113 00:08:35,520 --> 00:08:44,520 That's why I find, and I've always found, greater power in UML simply being a language to use to reason about systems that transcend the code. 114 00:08:44,520 --> 00:08:51,520 The code's the truth, but it's not the whole truth, and we need to understand that truth through other means of visualization, and that's what I always intended the UML to be. 115 00:08:51,520 --> 00:08:54,520 Hearing you talk also always reminds me I need to say the UML. 116 00:08:54,520 --> 00:08:55,520 The UML. 117 00:08:55,520 --> 00:08:56,520 Not just UML. 118 00:08:56,520 --> 00:08:57,520 That's right. 119 00:08:57,520 --> 00:08:58,520 It's always a subtle distinction. 120 00:08:58,520 --> 00:08:59,520 That's right. 121 00:08:59,520 --> 00:09:02,520 In fact, a little quick story at the end here. 122 00:09:02,520 --> 00:09:08,520 The February 22nd episode 2007 of the CBS show Numbers. 123 00:09:08,520 --> 00:09:09,520 Did you see that clip? 124 00:09:09,520 --> 00:09:10,520 No, no, no. 125 00:09:10,520 --> 00:09:11,520 Okay, so this is a great one. 126 00:09:11,520 --> 00:09:21,520 So the premise of Numbers is you've got this genius mathematician, his cop brother, and the genius mathematician comes in and helps him solve crimes through scientific means. 127 00:09:21,520 --> 00:09:27,520 Well, the February episode then was one called 24 in which there was a kidnapper, and this kidnapper is leaving clues behind. 128 00:09:27,520 --> 00:09:31,520 So the genius brother says, "Oh, this is just like a state machine." 129 00:09:31,520 --> 00:09:37,520 So he's sitting around talking with all his interns, and somebody says, "Oh, yeah, we could model it like a state machine." 130 00:09:37,520 --> 00:09:41,520 And the genius guy says, "Using the unified modeling language." 131 00:09:41,520 --> 00:09:44,520 Blew me away to see a pop culture thing happen. 132 00:09:44,520 --> 00:09:45,520 Absolutely. 133 00:09:45,520 --> 00:09:49,520 But I was pleased to see they properly put the article V in front of it. 134 00:09:49,520 --> 00:09:50,520 That's right. 135 00:09:50,520 --> 00:09:51,520 It's even Hollywood knows. 136 00:09:51,520 --> 00:09:52,520 Even Hollywood knows. 137 00:09:52,520 --> 00:09:53,520 That's right. 138 00:09:53,520 --> 00:09:54,520 Absolutely. 139 00:09:54,520 --> 00:09:55,520 Well, great. 140 00:09:55,520 --> 00:09:56,520 Well, thanks for taking the time to talk with us today. 141 00:09:56,520 --> 00:09:57,520 I appreciate it. 142 00:09:57,520 --> 00:09:58,520 Thank you.