24765
>> Juan Vargas: We're ready to start. And again this panel is
industry and academic collaborations to be effective, and we are going
to have some starting comments from the panelists, and then we will
open the floor for questions. And Joseph would like to do some
thoughts and he prepared some slides. So let's start with Josep.
>> Josep Torrellas: Thank you. So this is going to be very brief. So
the first thing is depending on what type of collaboration are we
talking about. Right? There's many degrees of collaboration. There
is a small collaboration that occurs with a student intern working on a
site, to a medium degree of collaboration where we have one faculty and
a couple of students working remotely.
Or to a large environment where we have a large team of faculty, and I
think the problems occur the more you go down. The earlier part is
easy. Except there's some issues in who controls the student. But the
problem occurs down as you move down here.
Especially when you have one faculty, each of them contributing 100 of
your time. So the main difficulty here is that there is a basic
disconnect. The faculty wants to perform novel research, work on
long-term issues, while the sponsor many times he or she is worried
about IT issues, is worried about the deliverables, and many times they
want to work on short-term issues that are not compatible with longer
term issues.
Of course we tend to gravitate to this thing all the time because we
all get something out of this. For the faculty it gets extraordinarily
rewarding if you have the ability to contribute to the sponsor's work.
Of course, there's a danger of wasting your time and resources to
students doing an interesting and unpublished work. On the sponsor
side, it's also very rewarding, could be, because folks from your
company can gain good knowledge and interact with faculty and students.
It may turn out into a waste
the agenda and so forth. So
you that I've seen this with
HPCS project with IBM, which
of time, loss of control, unable to set
I've seen it many times. So I can tell
the data PCA project with IBM, with DARPA
I was part of as well.
UPC IC internal with Microsoft, DARPA UHPC with Intel as well and DOX
stack with Intel.
So I can perhaps offer a couple of hints of what works and what doesn't
work. So what works is that if we have clear goals as we get into the
project, people know and trust each other on both sides. It works best
if you know you're creating an industry because of same area and you
work with them for a while, perhaps ten years ago or 20 years ago, it
helps if you have a clear definition of the work of each of the
academic PIs.
So each of the ten faculty or three faculty or four faculty has to have
a distinctive role, in my opinion. It works best. It's best if we
agree IT issues would not be in the way. And it works if you have
periodic calls, weekly calls and physical meetings, even if it looks
like a waste of time, deep dives every two weeks on topics and so
forth. And also, of course, it works if academics have a clear value
add for the project. If they don't, then it's not good.
So these are the good things. The bad things, things that will make it
fail, I think, is if the sponsor contact person changes often, that's a
very bad thing. So if we get somebody from a certain company and every
six months we have another person, that's not going to work.
Even influential people in the company are against the collaboration,
of course, and you hear this right away from the beginning. If the
start is an arranged marriage by the government or other entity it's
not going to work either. So oftentimes you have DARPA projects where
you need a total academic or some other person, then it's not going to
work. If you have unclear partitioning between the faculty PIs it's
not going to work with the stump [inaudible] nothing will get done.
And also, of course, there's always the issues of personalities which
you cannot predict from the beginning. So I think for this to work, we
have to emphasize the things that make it work and try to avoid the
stuff that doesn't. Thanks.
>> Juan Vargas:
So who would like to follow that?
>>: Sure. I disagree with a lot of those things, I guess. I don't
think -- I think academics are lousy at doing work in the short term.
I think it's the wrong place to go. We can't deliver on schedules and
stuff like that.
So I don't think we've ever done anything that we didn't think was a
long-term research with industry. People come to us and offer us money
to do things, but I told them we're just in the wrong place to do that.
The way we do these projects is to get -- we use the phrase two feet
in, is that I'm not -- I really am not interested in leading a project
with 100 faculty spending 100th of their time on it.
We want to have a group of people
with the project. And to do that
for those faculty. At least half
don't, then it's pushing strain.
who are signed up, who are committed
we need to get significant funding
of the students are on it. If you
You try and run around and get
faculty, a fraction of the graduate student to get them to pretend
they're working on the thing, it's really hard.
I agree about personalities. We try and put people together who can
work together and there are certainly colleagues who always have worked
independently at Berkeley and probably always will.
They wouldn't be your first choice to put on to a team. But I don't -the tether here at DARPA was I was pretty much on the record of making
clear in my disapproval, and they turned academic researchers into kind
of consultants.
The academics were, I don't know, window dressing or something. And so
I'm sure that was -- I'm sure there was a lot of bad relationships,
awkward circumstances, that I don't think of UPC as -- I don't think
the relationships we have with industry have been like that.
But I think one of the things I liked about it was the surprise about
being industrial funded versus DARPA funding was kind of the program
managers were so much better. It was people who you went to
conferences with who were the people you interacted with and gave you a
peek at.
We're closer to Silicon Valley than Illinois but we don't do weekly
phone calls. The thing that if every time you bump into me ask me
what's the most important thing, I'm going to say retreats. We do
these three-day intensive things, invite lots of people there and give
us a lot of feedback on what's going on.
I guess if it was a very -- if it was a joint project split between
Berkeley and some company and there were groups working simultaneously
on it we'd do something every regular meeting.
But I don't see why that would be necessary in the way we do these
things.
>>: I agree with Dave. I think -- I've had, you know, lots of
university collaborations over the years. I used to be a university
person. And then I became an industrial person.
And all my collaborations have been about long term topics. All of my
collaborations have involved -- well, the only mention of IT is that if
we invent something together, I at least would like to have the ability
to use it either because it's publicly available and not protected in
any way, or I have a [inaudible] from the university or something. But
that's really all that I want.
>>: Absolutely.
use it.
Industry doesn't want to fund it and not be able to
>>: That's right. But it needs to be long term. And typically is
something where the university has at least or the person has at least
half the say or maybe three-quarters about what the subject is. It
just has to be interesting enough for the agenda of the company I'm
working for.
So, for example, when the edict came down in HPCS from Tony Tether that
we weren't going to be funding academic institutions with HPCS funding,
Bob Grabel came around and said okay you've got to pick up some faculty
because industry has to take on this role, I said fine. So I recruited
Bill Dali and Peter Cogi and people like that. And guess what they
worked on, they worked on 10-year problems mostly that I knew were
biting us eventually, not biting us right now. They knew it too. So
all the PIM stuff that Peter was pursuing for our HPSC proposal was
pretty much long-term stuff and pretty bleeding edge safe to say.
But we wound up not doing it because of management decisions, I guess,
I would say. But it was definitely longer term stuff and we shouldn't
be cooperating with universities just try to use them as a labor force
or something like that.
By the same token, I think this idea of being able to transfer
technology immediately from academia into industry is just broken. I
mean, it's not the way it works. And so we shouldn't be asking for
that either.
>>: You mean DARPA ->>: Or anybody else. We shouldn't just sort of say, well, you know, a
particular collaboration with the university is valuable to the extent
that it allows us to transfer the technology developed or the ideas
developed in that collaboration directly with the product. I don't
think that's realistic, either.
>>: You know, I feel bad here, because I usually say that there's
nothing worse than a panel where everyone sits and says well I agree
with you. Makes for a boring panel. I guess we're going to have a
boring panel.
But I did want to bring one angle, because I, too, have been involved
with many, many collaborations over the years. And I have found one
truism over and over again. If the industry people put people in joint
projects where the industry person's monthly status report includes
that collaboration, if they're not going to put that much skin in the
game, they just shouldn't do the collaboration. Period.
And that's to me if I were managing projects at my company with the
universities, it would only be long term. Yes, absolutely. But it
would also be, okay, who is putting the skin in the game in terms of
committing their time to work directly on projects with the faculty.
And if you don't do that, then it's just the industry throwing money
away. So they can say that they're working with this university.
But they're not likely to be acting it out.
>>: Let me change the subject a little bit. So I think given the sort
of composition of the audience it might be worth talking a little bit
about why companies fund this type of work.
And there isn't the simple answer to that. And I think part of the
problems with the centers have been that people have assumed that
there's a simple answer and they've interpreted things that have
happened in terms of their perception of what the companies should have
been doing that put the money into it.
The obvious answer is that we love research and we love giving money to
the best people in the field. And we feel good because they published
lots of papers and advanced the state of the art.
You know, that's not higher on the list than most company's decisions
to spend money. There can certainly be a belief that it's good to
advance the state of the art because everybody benefits from it.
But companies generally
They're looking out for
in this case, Microsoft
when they got the RPURC
are not looking out for the general good.
their own particular good. And in particular,
and Intel had some very specific goals in mind
center started.
We wanted to revitalize parallel computing research, which I think we
were probably pretty successful in it, whether it would have happened
or not without us, I don't know. I mean, some of it certainly would
have. I think we wanted to shift the focus of research away from the
scientific large-scale HPC to other domains, and I certainly would say
we were successful in this case. And somewhat in the larger community.
I don't think that would have happened without us.
We obviously want to train good people even more than we want to see
papers published because we hire good people. And I think that's
certainly happened in both schools. So there's a lot of good there.
Tech transfer, I don't think anybody really realistically -- I'm not
speaking for Intel, I'm speaking for Microsoft -- I don't think any of
us realistically expected anything to come out of either project that
we could pick up. There just isn't a history of that inside of
Microsoft. A code that's produced in universities is not commercial
code.
The ideas certainly can be brought in, but they're typically brought in
by hiring the people and having them come to the company rather than
reading the paper or picking up the code or buying something like that.
And it's way too early to tell. Tech transfer takes years. Even for
people within Microsoft like me who have a blue badge who sort of sit
here, it takes a long time. It's very hard to do tech transfer. So
the expectation that's sort of a new research project that was
producing results for most of the five years, and at the end of five
years would have tech transfers to show for it I think is unrealistic.
And everybody knew that when we got started.
And there's probably -- there were lots of motivations that were going
on. So it's not simple to say why we decided to fund two parallel
computing research centers. And I think that a lot of the
misunderstandings were that people sort of picked one of those reasons
and they said that's why you guys did it, and you're doing this action
that doesn't conform to that particular motivation.
That caused a lot of misunderstandings over the years. So just keep
that in mind when you're working with industry, is that it's not as
simple as going to the government where there is just funding source
where the law says you're giving out money for this reason.
>>: [inaudible] has a comment and I'd like to use your microphone.
>>: Yes, two comments. Obviously you are right. And I think the main
reason is that Microsoft is not a thing. It's a collection of things
interacting with each other. And when you go through the reasons why
things happen in institutions, you can look at the institution and say
black box, and then it seems like it has a mind of its own.
Or you can go deeper and you will see that the outcome is the result of
many forces. And that's probably what you are trying to say, that
there are different interests of people who think in different ways.
And I think what you said is absolutely right. That those objectives,
the ones you mentioned, seem totally reasonable. I am sure that there
are others that has to do with internal politics that we would never
know.
But to me in terms of articulating why this is done, I think, again,
you're right, it seems to me that the function of cooperations in
sponsored research similar to DARPA rather than the National Science
Foundation. So DARPA has a specific objective. They could fund it in
that and that shifted the emphasis of research, and that is good.
So if DARPA has the right vision, they can steer the research community
in the right direction. When they err in the direction, they can waste
immense amounts of resources [inaudible] so in that sense, we assume
that I would have is that was this emphasis a good direction, is
parallel computing in the client side, which is what we were asking to
do research on, was it worthwhile direction for us to embark on or that
is something that is not really going to flourish?
>>: Is that a question?
>>: Yeah.
>>: I think it's an interesting question. And I think there are two
answers to it. Five years ago when we started, that seemed to be a
direction that was extremely important to both companies. And that was
a large part of the impetus for us to get together and fund this
research and to do the other things that I talked about.
That was the best guess at that time. With five years more hindsight,
I would say no, that the world has progressed just fine without
significant parallelism on the desktop. I see some interesting
applications coming out that might change that.
But right now it hasn't changed that.
>>: I think we found disagreement.
>>: We sure did.
>>: That's good. I'm just throwing that out there. But at the time we
made that decision to fund it, I think there was a pretty broad
consensus across both companies that, yes, it was important.
>>: I'd like to add, since we had thanks to the change in DARPA
leadership, I had to figure out how to do industrial funding
immediately. Nothing that Jim said surprised me. I just think that
everybody, not just academics, but industry, too, should appreciate -I agree what you said. We can talk about the things we can evaluate in
the short term which was getting people's attention to work on
parallelism. That happened. Focusing on the client. That was a
really big change.
That was a very different shift, and we brought those apps to like hot
farms, stuff like that, that was a very different set of apps and
different requirements. Those things we can evaluate.
Technology transfer takes time. So I've heard people who were not in
academics who have already evaluated the project without giving the
time to see if technology transfer is going to happen. And I would
like more people to appreciate that what you said. It's too early to
say about the technology transfer piece and evaluate the success.
The other thing that happens with companies is like with universities,
once we get a bunch of students together and head off in a direction,
we can't change as the company's -- as things change for the company.
One graduate student's lifetime. One said is parallelism desktop, new
interfaces, we can't just shift our people and make them work on it, we
get set off like a rocket ship, headed off in this destination, can't
change our direction succeed in the education part.
It was interesting, sort of fussing, wanted the students as much as you
wanted the ideas. That was really clear. So I think are we going to
produce great students. Have we? Yeah. Did we help get people
focused on parallelism? Absolutely. And client side. So we did all
the things that people wanted us to do five years ago, I think of it as
hitting the bull's eye. And it's just a little frustrating now for
people to claim either that wasn't the bull's eye, or we know you
didn't hit it.
Well, the parts we can evaluate, I think we did. The parts about how
significant the impact, it takes years to figure out the impact. The
right thing to do, I actually do this, I do reunions. I bring people
together years later. Kind of this is 2012. 2017, 2020, we'll look
back and see what happened in both companies. We'll need to be able to
know that.
So one of the things reasons this has come up did this one work. Well,
the parts we can measure worked. And we can guess how successful the
transfer is, but ->>: But ->>: In 2017 is ->>: I tend to do that. I was on this big committee on campus and I
said I'd do the reunion. Sure you will, and five years later I held
the reunion. I think it's healthy. I believe in feedback. Right?
How are we going to know -- how are the students, how are the faculty.
How will we know how this works? Really we should get together in five
or 10 years.
>>: But I agree with the unions, the project I worked on, the only
depressing part of it is come back and look at ->>: Yes, yes.
If we could do a cosmetic surgery day or something.
>>: I want to weigh in on something here. I've over the years been
involved from actually both sides as an academic and in industry.
And I just have to say personally this interaction with the Berkeley
folks and UPCRC has been the most satisfying academic industrial
collaboration I've ever been involved with. I think if you're not from
U.C. Berkeley it's worthwhile exploring why it's successful. I'll say
why it's successful. I mentioned one. There were people from Intel,
myself included who put skin in the game. Two, the concept of bringing
all the graduate students and faculty into one physical space getting
most of the faculty to sit with the graduate students, that succeeded
beyond my wildest dreams. That was amazing.
>>: What it meant, when I visited, I didn't have to keep track of the
professor down that hall this professor on that floor, no they were all
in one space. The retreats model, the fact of the matter we got in one
place, including folks from the periphery involved sponsors, all came
together in one place and shared ideas. I just have to say that that's
a model that other universities should study very closely and try to
replicate. Because it really, really worked.
>>: So I should say gee [inaudible] would disagree with what you said
that it was not a good idea? A lot of the tools and things that they
have been developing, right, have some input from the group at
Illinois, yes.
>>: I didn't say it wasn't a good idea. I think David's question was,
was the focus on desktop parallelism the right choice. And ->>: Have another problem with that. And that is that it was on client
parallelism. And in fact micro -- in fact, mobile, the client's
changed in the middle of it.
>>: Yeah, but from the beginning we talked about ->>: [laughter] so it wasn't desktop parallelism in Berkeley's case.
wasn't specifically in Illinois's either.
>>: Intel probably has a slightly different opinion on this, I think.
>>: I'm sure.
>>: And they're certainly welcome to it, their opinion.
>>: [inaudible].
>>: Use mics in case ->>: Apparently not.
>>: I don't think anybody else has slides.
>>: I think that's the first time anybody's said that.
>>: Defend Burton's opportunity to talk.
>>: Wow.
>>: I have a question.
>>: Dave, and that is --
It
>>: Somehow that ->>: Turn it on.
>>: Speak loud.
>>: So asked him on what worked and why. And especially the retreats,
because I didn't go to Berkeley as often as he did. But I did go to to
the retreats, and those worked really well, and both what we looked and
learned and opportunity to give feedback we actually saw, at least I
did, that in the next time things were modified according to our
feedback.
>>: Yeah, it's not just him.
>>: So the question is really a small detail, but just to improve my
understanding of the methodology, you mentioned that you didn't want to
have weekly form meetings. And why is that? What's the downside?
>>: I think Josep -- I interpreted the slide of saying a necessary
condition for success was weekly phone meetings. And I think that's
one way. But that's not the only way.
>>: Okay. So you're not saying that they're evil you're just saying
they're not ->>: I don't think it's a bad idea. That's a tremendous -- that's a
harder commitment to get out of faculty and students and people in
industry. If every one of our sub projects needed to have a weekly
phone call from somebody at Intel Microsoft, that would have been a
hard thing to do.
>>: But that's what we do in our company.
good idea?
Are you saying it's not a
>>: I'm just telling you, these are people taking classes and teaching
classes. And often different time zones. So that's a hard thing to
do. So that's why we like the retreats where we suck you all there for
intensive whatever it is, 48 or 56 hours and you get a lot of
interaction.
>>: Yeah, so I guess I've kind of collaborated a lot with both
companies over the years. I wanted to add to what Tim Madsen said. I
think for me it felt like part of the reason that it was the
collaborations could be so successful in some cases is that it felt, I
did feel like in the case of Microsoft and Intel and our major sponsors
that they were all in and they were going to be around for five years.
And so as far as collaborations go, we didn't have to, it felt like on
either side we didn't have to have short-term thinking. Like Intel
definitely helped me in cases where maybe right away it wasn't going to
help them but because they believe in the project long term. And we've
tried to step out and give them things in the shorter term because you
know that everyone's around for if long haul and that you really want
the whole thing to succeed together. And in the case of more and more
affiliate sponsors never felt like that, because people were coming and
going and you didn't know if they were going to be at this retreat or
the next retreat.
So I think the mindset from the beginning that we're all going to kind
of normalize with these retreats. So we get on the same page, you'll
be around for a while really helped the collaboration and kind of maybe
allowed us to take bigger risks than I think you would if you found a
collaborator were talking about doing a short-term project and maybe
we'll publish this paper in six months or something. I thought that
was something different than what I felt other collaborations be, and I
think that made it really, really neat.
>>: So I agree with a lot of what Suri said. But I want to expand what
we mean by tech transfer. I think right now a lot of what we talked
about is will my particular code go into this particular project. Like
a lot of us did try this. And sometimes it's hard. Like getting into
a browser shipping to 100 million people. There are certain challenges
with that, especially when you don't know what hardware they have.
But there's a really remarkable discussion actually we had with Sara
and a bunch of other people in this room at the last retreat where
we're trying to say, oh, what type of demo should we do for the final
Parlab. Pretty much we went around the table and each person proposed
a start-up that was enabled by the technology we developed in our lab.
That's a different tech transfer. This is like opening up markets
these are types of things we couldn't do on our phones before. Darryl
talked about today we can do a million song, real time stuff on your
phone, essentially. You couldn't do that before. Like I don't care
what company you're transferring that in. But it's an entire class of
project. We were seriously discussing what type of fun games we could
make. Nicole was could we make those games ->>: Wait a second. It's quite reasonable to say the tech transfer
doesn't have to go to Microsoft or Intel. But the amount of effort
that it would take you to go and do this start-up and the number of
years it would take for that actually roll out as a product is very
significant. It's not like just sitting around the table saying we
could do a start-up with this idea as affected. It's the same -- to
actually see the impact, you actually have to form a company, turn it
into a product, sell it. And everything else like that.
That's a lot of work, too. It's probably not that different than
actually seeing some of those ideas being put into a product in one of
the companies.
>>: Actually, we were talking about actually potentially doing like
just apps for phones, which are actually supposed to be generally the
lifecycle is roughly a weekend to two weekends.
>>: But you can always put software out on the Web. Billions of
software projects out there, but how much impact do they have?
>>: So for us tech transfer doesn't mean transfer of code. Even if we
have researchers inside the companies, inside the labs, that are
applicable for the compiler let's say, we're not going to take their
code because they're not going to adhere to our code and conventions,
et cetera. We're going to take their idea and implement it.
At that level we can do it. So the big idea is that we want all those
patterns and we want systems software to turn that into something
efficient and well parallelized and that idea we can take.
And we are not going to take code anymore. Now, that works, is going
to work very differently for a whole number of reasons.
And so to synthesize that idea and make it fit into our stack needs a
lot of thinking but it was an idea worth pursuing. That's one of the
things we talked mostly about in all the fields.
How do we capitalize on circuits and not necessarily by forcing our
existing customer to buy the code.
>>: So some of the software devices that we developed in Illinois make
it to prototypes in Intel. That's tech transfer right there. So the
example I gave about the [inaudible] player there was FPGA design they
have. The operating system all came from [inaudible] how you monitor
the system or you managed the presence.
So that's something -- that is getting into the labs, it's not getting
inside development. But I think it's possible in a couple of years.
>>: That's a great example that you had Intel researcher from PSL
collaborating with you on the project. And so he tied his research
agenda inside the lab to that collaboration. And that kind of brings
buy in and gets a good transfer of ideas. So that was -- that was in
my restricted view one of the biggest successes out of the Illinois
collaboration.
>>: My guess is the executives are trying to evaluate was UPCRC worth
it, looking for their main product line change in some significantly
positive way.
Like I said, if we do a reunion, I think we'll be able to [inaudible]
will we be able to see that or not. That's one or both of these
companies.
it.
That will be the -- that's probably the way they think of
>>: I have no idea since I'm not one of those executives.
>>: Well, I don't know. I mean, I think -- how about this? If that
happened, I think probably they will say it's a success. Maybe if it
doesn't happen they'll still say it's a success.
>>: Next time talking to Paul [inaudible] I'll ask him about that.
get together to kayak all the time.
We
>>: I don't know if Paul knows about this project.
>>: [inaudible].
>>: What was that?
>>: He knows this.
>>: He does know?
>>: So if you have questions, please we have some microphones.
>>: What time does the last class leave?
>>: I have a microphone so I can ask a question, right?
>>: 5:30.
>>: 5:30 bus for those who want to leave.
>>: There's a dinner?
>>: There's a dinner here tonight?
>>: There's the hard choice.
>>: I didn't know that.
>>: It's kind of separate -- it's part of tomorrow's agenda.
>>: I didn't know there was a dinner.
>>: Come here tomorrow.
>>: I actually wasn't a Microsoft employee when this started, but the
external observer of this process in another institution, I felt like
the community was not ready for parallel computing. We didn't have
enough graduate students trained in parallel computing.
We didn't have enough undergraduate education. Intel made a big push
for parallel programming classes and parallelism in the curriculum.
And that a key that we needed -- you need people who understand
parallelism in order for all this to work. And that this infusion
should have been -- should have generated a bunch of well-trained
people who understand parallelism and could do something. Even if
their exact project wasn't a success. And you could say one of Dave's
early projects that produced Jim Morris, this particular thesis work
was not a success, but Jim is a success. Right?
>>: We were just 20 years too early.
stations before the term was --
We were selling multi-core
>>: So for people who were putting the money together, I think a really
important thing, if you're going to do the five-year reunion, is who
was in these projects, what companies are they in, and did that happen.
So you could be altruistic and say we were a success if somebody else
got leverage out of these people and then you could have your selfish
success be we hired people from these projects and they impacted our
company. And so then you could have the more altruistic version of
success and then you could have the self-absorbed version of success
too.
>>: There was levels of that at the beginnings of the program when
Craig Mundie and Justin Rattler deputized me and Andrew Chin to go
wrestle up money to do this.
The motivation in part was to try to energize the academic community on
the subject. And call it altruism if you want, but we think they were
both important companies in the computer business, and what is good for
the computer business is good for U.S. steel or what is it.
>>: U.S. steel is good for the U.S.A.
>>: What's good for the community industry was probably good for Intel
and Microsoft.
>>: Exactly.
>>: Kathryn reminded me of something, as I recollect my career I've
been on ten of these projects or 11. Three of them have been
parallelism. The very first one I worked on when I got to Berkeley I
thought they wanted me to work on parallelism.
That was not a very good project. I learned how to do projects from
that. The one with Jim, the spare project -- what's different about
this one? The educational impact is different. Randy Cats and I
taught the third semester course in architecture and we saw it. We
just couldn't teach it. Not changed a lot in the last five or ten
years. So now it's thoroughly parallelism. So what do they do?
These third semester students, they do MapReduce, use warehouse scaled
computing, MapReduce. They do CND parallelism in x86 instruction set.
They do thread level parallelism. These are sophomores, right? And at
the end, the ones that are really enthusiastic, they do matrix
multiply, the first assignment in Jim's graduate parallelism class, and
the best of them outperform the Intel map fiber. These are sophomores.
So it was like, A, I was more -- I think what we tried to do is aim for
the top half of the class rather than worrying about how little the
bottom half didn't -- what's the minimum that they would get. But I
was very impressed with them. And also wow this time we're really
teaching it. It's not just lip services.
It's mainstream [inaudible] data class, Kathy did a class. I think
parallelism is now part of the curriculum, and that's the first time
that's been true. And once we get into the curriculum, then it's big
numbers of people that are being trained this way.
>>: If I was -- so if you were to go now and try to get from for
parallelism from Microsoft and Intel, do you think you will be as
successful as you were then?
>>: At the moment, I don't know.
>>: Yes or no.
>>: Had some impact.
>>: I don't know -- I don't.
[laughter].
>>: I think the focus is different. I think Intel mostly talked about
energy efficiency.
>>: Yeah, but energy -- the parallelism, a big part of why parallelism
is so critical is energy efficiency.
>>: I wouldn't rule it out.
>>: I wouldn't rule it out at Intel.
to say --
Because we're not in a position
>>: I don't know Microsoft, where is the crisis at Microsoft?
wouldn't -- if you called it parallelism I don't think ->>: I don't think parallelism is the crisis.
efficiency is the crisis.
I
I don't think energy
>>: I think it makes sense for Intel, and I don't think that's the
issue at Microsoft.
>>: We surely have to change the keywords from project to project
otherwise it's not going to work. So I think that's the reason.
>>: I guess to me I know the name of [inaudible] is parallelism but
when I look back think about what the big contributions are it's not
necessarily -- parallelism was a theme that we kind of worked with, but
the things we made aren't just parallelism-related. And it seems like
almost every research project going forward in the next lab or every
research project is continuing in either Aspire one of our other labs,
and so it sort of seems that maybe the answer is, yes, people would
fund it going -- again, because we didn't just solve parallelism. We
did different things. So maybe we need to rebrand the lab or something
for legacy. It seems at least to me it ended up being relevant.
>>: The physical space is called the Parlab.
have a different name.
The next project will
>>: I'm just saying that ->>: Both have par in the name.
>>: It's not like we're stopping this research. Most everything we've
noticed is very valuable going forward. It's strange to say we
wouldn't fund it again.
>>: I think I agree with what you said but I firmly believe what
happens next parallelism will be a key part of it. Even if the name
doesn't say parallelism. There will be parallelism underneath. In
many regards, that's success. That's kind of what we want to do was
make it routine that just of course it's parallel why would you be
stupid enough to do it serial. That's dumb.
>>: We proposed a follow on project that's not parallel because it's
not cool now, I don't think that would get funded.
>>: For example, if you look at the perfect, the DARPA perfect thing.
After parallelism they went into this very low powered thing.
Parallelism is there as the bullet, very important.
>>: [inaudible] high energy efficiency.
>>: Yeah. Very different. But nevertheless ->>: I agree.
Parallelism --
>>: You find parallelism.
>>: Parallelism is obviously you wouldn't do something that wasn't
parallel.
>>: That's the outcome you'd like, yeah.
>>: Another point to focus on -- do we have any other questions from
the audience?
>>: No, this is boring.
[laughter].
>>: We're agreeing too much so...
>>: That was disappointing.
>>: Enough money?
>>: What's that?
>>: Yeah. Yeah.
We got --
>>: Send back whatever you haven't spent, Dave.
>>: How many academics are ever going to say that? It was plenty of
money. It was $2 million, and we got matching funds from the state of
California before it went bankrupt.
>>: [inaudible] enough for the community?
>>: I can't ->>: We didn't fund ->>: I don't know how to answer that question.
answer that question.
I don't know how to
>>: It's a driven -- it's a driven increases in two institutions. So
now you guys supposedly don't ask for as much DARPA or NSF money. So
it frees up more money. And was that -- was there enough -- is there
enough parallelism ->>: Enough to invest in parallelism?
No.
Is that the question?
No.
>>: I think I'm pretty clear on the record that DARPA money was not
well invested for one whole presidential administration. By the
longest serving DARPA director. I feel comfortable defending that.
Suppose that money hadn't been given to extremely wealthy companies,
hundreds of millions of dollars of extremely wealthy companies, I don't
know what [inaudible], and all those guys are getting. They get
support for the next product development. Sun, IBM. Maybe Cray, a
smaller company. Why did IBM need money, hundreds of millions of
dollars to work on DARPA computer architecture. Suppose that money had
been invested in universities on parallelism in 2000, which is what the
original -- suppose that maybe, suppose one quarter of that money gets
plowed in universities to work in 2000, instead of whatever, 2004, 5
when we got emergency started. This decade might have been very
different.
>>: I've been complaining to NSF in particular, but other agencies as
well, about very poor support for systems work by which I mean
architecture, compilers, operating systems and general the
infrastructure of computing.
And in parallelism and distributed computing, maybe even worse at the
moment are very important emerging requirements and systems that are
not being addressed by the academic community to solve these long term
problems, precisely systems research involves fairly serious amounts of
money of people and projects and so on. And NSF has lost the taste for
funding that as DARPA had and maybe still does, I don't know. So
that's a really serious problem.
>>: The other thing, Kathryn, is that this project was deliberately not
designed to fund the community. I mean, it was very explicit
originally it was only going to be one school then it was expanded to
two. And it was not intended to fund parallel computing in the
universities in general.
There are lots of -- there are lots of ->>: Intel and Microsoft worked over and over.
>>: Lots -- we wouldn't have. We wouldn't have done that funding
model. But I think lots of other universities were able to take the
evidence that this was important enough to Microsoft and Intel and go
to the government and say: You should be funding our research because
it's important to companies that are important ->>: So I think it was very exciting to have this big chunk of money.
For the two universities it was very good. I feel that we lost an
opportunity to excite the rest of the funding agencies to join in.
>>: I agree.
>>: So you can see that there hasn't been another push. There was SRC,
semiconductor, partnered with NSF to have this program on multicores,
but NSF didn't come up with a big program, DARPA didn't come up with a
big program.
>>: They had a huge program they just gave it all to industry.
>>: How much was -- when I criticized Tony Tether, he said look at how
much I'm investing in industry and spending on. It's not just through
university.
>>: That's true. One interesting, follow up from DOE or NSF or DARPA
with big chunks of money to many universities. That we didn't see.
>>: Fred Johnson had a fast OS project when he was at NV Research, but
he's one of the few government funding sources historically that funded
universities doing systems.
>>: I remember there was a time when you guys maybe some of you went to
Washington to speak with NSF people.
>>: Like me. I talked to Rita Caldwell about it. I talked to Argen
Babet about it, I talked to Janette Wing about it and Regina Moxie
about it, just about everybody who would listen at NSF.
>>: That was the time to come up with NSF programs.
>>: Yeah. They didn't do it, though.
>>: It may happen still.
>>: So one measure of success that I'm looking for is when do you think
our customers will start writing parallel code?
>>: They already are.
>>: The advantage I have working on the intercompiler of let's say
working on Microsoft compiler is I know all of my customers whose
middle name and mother's name and don't ask.
>>: And they're not yet writing parallel code?
>>: Some of them started, but I can't say we caused the harm.
>>: This is why I assert this is not a finished problem, because
there's a lot more work to be done. And that it concerns me when I
hear companies that should know better suggesting that it is a problem
that's not critical and doesn't need a lot more attention. It concerns
me.
>>: May take another decade for ISVs to kind of catch up.
>>: The other thing to remember is that if you have a large, important
software, piece of software, it doesn't change very fast. So Microsoft
introduced the language C# well over a decade ago, which is clearly an
improvement over C and C++. And for the longest time I would get
questions from people: Are you rewriting all your software in C#.
That's sort of a nonsensical question.
>>: It is, because the answer is no, you're not going to rewrite it in
C and C#. Just because the costs are huge and compatibility issues are
huge.
I think parallelism is at least as radical a change in the architecture
of software as it is moving to a managed language. And it's going to
be gradual, happen at a slower rate. The new stuff can pick it up
faster because it starts smaller and can be architected the right way
from the first. But the big companies with the big important pieces of
software are going to be slower.
>>: I guess the frame of reference is which companies you consider
being important. And, by the way, size is not your friend, right? So
clearly a big company don't change the software infrastructure often,
but ->>: When I say big, I mean big software company.
>>: Right. We have data showing that actually is in the context of
adoption of Windows 8. And the target market for that is spending 38%
of their time on new applications. Third generation applications. And
37 percent on less than five even. So this is not your HPC crowd,
right? It keeps fixing bugs and fixes the software all the time.
>>: So another thing is in my opinion, this is my opinion. A lot of
companies are distracted with cloud computing now. Porting their codes
to the cloud and all the rearrangements that require to the code,
hoping that they'll get better and faster.
But eventually maybe they'll find that it is not the way to get the
stuff faster and they need the speed and then they'll deal with
parallelism. That's an optimistic view.
>>: So your apps don't have a parallelism that will take advantage of
the cloud, is that what you think?
>>: Yeah, exactly. So they will find if they want speed there's the
need to parallelize. I know many companies now reorganizing the
software for the [inaudible].
>>: But I think they're doing that for economic advantages.
>>: That's right.
>>: Not performance.
>>: But they're distracting, they're focused on this at this point,
yeah.
>>: The software deployment and economic model and if that's it you're
going to be in trouble, right? That's driving industry.
>>: The other part is mobile. Neither Intel nor Microsoft has a big
visibility in the mobile space as they would like. That's the polite
way of putting it.
>>: Very well put. Good job for the [inaudible] director.
you were even more successful.
You wish
>>: About what's happening in that space, in terms of that development.
That's only new code, right.
>>: It's all new code but the platform is not very parallel. And I
think you could argue that it will be. But it's not there yet. And
part of it is a chicken and egg problem.
>>: But that would be -- that's part of the let's wait five years
argument, right?
>>: But if you wait five years all these sort of new apps, the legacy
apps there.
>>: Well I guess that would be -- I only take bets when they're sure
things. But I'm sure there would be some kind of bet about in five
years will the apps that are being developed for the mobile devices be
exclusive parallel, that would be the ->>: Depending on how you quibble over the definition of exclusively
parallel, I think they will be. And once again it's power. It's all
power. Heterogeneous, parallel, mobile platforms.
>>: I assume if we did a vote, we would think that would be true.
>>: No, I know it will be true.
>>: I think there will be applications of parallelism and mobile
devices to support user interfaces and have multiple service requests
outstanding at the same time to various resources to deliver what it is
they'll deliver.
>>: There will be concurrent apps to which there are parallel apps and
it's all going to have to fit together. And those doing research and
fundamental technologies for underlying parallelism and concurrent
applications are in no danger of running out of work.
>>: You're not going to run out of work.
>>: It would be really -- will they embrace some of the ideas that both
schools have talked about, like patterns? Do all that?
>>: In my completely unbiased opinion, sure.
>>: But what's the ideas that seem incredibly vital now to make
progress will be embraced over the time, will be fun to watch.
>>: Yeah, it will be fun to watch.
>> Juan Vargas: So it's five minutes to.
you very much, everybody.
[applause]
Thank you very much.
Thank