intervija ar Dr.Vijay Pande
Janvārī Team MacOS X nointervēja Dr.Vijay Pande - projekta vadošo zinātnieku, kura pārraudzībā notiek visas šīs olbaltumvielu simulācijas. Intervija skar plašu jautājumu loku par projektu, nākotnes prognozes, tehniskas nianses un daudz ko citu. Pašu interviju .mp3 formātā var nopumpēt [ šeit ]. Pavisam nesen kļuva pieejams šīs pašas intervijas atšifrējums.

Varbūt kāds var pārcelt to visu smuki uz mūsu wiki (neaizmirstot atsauci, protams)? Pamatā visa vajadzīgā infa ir šajās adresēs:
http://teammacosx.homeunix.com/forum/cgi-bin/ikonboard.pl?act=ST;f=26;t=1531
http://teammacosx.homeunix.com/Media/transcript/interview.html


Brutāli nozagts no šejienes: http://teammacosx.homeunix.com/Media/transcript/interview.html

Noah Johnson: Lets go ahead and get started on this. On this interview I am going to try to keep it light so that we can make it enjoyable for new folders. But I wanted to make sure that we got some good information too, so that people will be interested even if they have been folding for a while. If there are questions that you can't answer, let me know and we will just mark them off. I will start at the top of the list that I sent you and we will just go down from there. So the first question was: What in your words is the main goal of the whole folding at home project? What milestones have you achieved towards that goal so far?
Vijay Pande: Our primary goal is to understand folding related diseases like Alzheimer's, and Parkinson's, or Huntington's disease. Using computations to do this is actually a very novel approach. For decades, people have dreamed about the idea of using computers to understand disease and biology and to design drugs, and during the same decades they have come up with computational methods which they hoped would be successful. But really it hasn't quite panned out as well as people would have liked, and it is only recently that the algorithms are getting good enough and the computational power big enough that we can actually do this.

It might seem kind of counter-intuitive, but in designing drugs and looking at atomic systems, even though the systems are small in terms of their absolute scale, they are surprisingly complicated. And even though people use computers to design other complicated things like computer chips or bridges, these molecular systems are thousands and millions of times more complex. So, to do something that is really accurate and really useful with molecular systems, one needs to develop new methods - and even with these new methods, to have computational power that is thousands or millions of times greater than what most researchers have.


NJ: So basically there hasn't been as much ground broken as you would hope but things are getting better with the new amber core and stuff like that?
VP: No, actually I was talking about the history before Folding@Home - laying the foundation. Where Folding@Home has succeeded is in coming up with new algorithms and also the necessary computational power. We actually we have more aggregate computer power than all the assets of the (super)computer centers combined and that has allowed us to do things other researchers can't do. In a couple of early milestones that approach has worked out quite well. Our ability to predict the binding of small molecules or drugs to proteins now has gotten sufficiently accurate that it really could be useful for designing drugs for the pharmaceutical industry. The paper on that is about to be submitted for publication and it's something we are very excited about. Earlier than that, even simulating the folding of a protein straight from the most basic information - the protein sequence - that hadn't been done before either. That was one of our early goals. Many of our papers - especially the one in Nature - are on developing methods to do that and checking how our predictions compared with experiment.

The history that I was describing led up to the point where Folding@home came onto the scene and since then we have been able to make enormous strides. We have about a thousand times more raw computer power for calculations than most of our competitors. And if you ask how many years of Moore's law you would have to wait to close that gap, the answer is about 15 years. In a sense we can now do research that other groups could really only do 15 years in the future.


NJ: We are kind of leap frogging the old techniques with this new one?
VP: Yes, it lets us do research several computing generations into the future. Not fifteen thousand years into the future so we can't do everything that we would like, but it is sufficient to do what we need now. I'm sure a lot of people thought it would be impossible and that is the part that gets me excited: we can study protein folding in a way that really couldn't be done otherwise.


NJ: And this has been a really great project for that type of thing from what I see.
VP: Yes, I hope so. Some distributed computing projects, I think, are more interested in just proving the basics of how distributed computing works rather than really caring about the application of all that computing power.


NJ: That might go into our next question, which is: What makes this project different from other distributed computing projects like distributed folding, for example, why should people choose Folding@home rather than maybe one of those?
VP: There are a lot of interesting distributed computing projects out there and obviously I am biased in my view of them like a proud father, or something like that. Discounting my obvious bias in this, there are a couple things I think have set us apart. One is that we are doing work directly related to disease. We have Alzheimer work units and Huntington disease work units and so on - a lot of projects point directly towards aspects of the disease process. We have some experimental collaborations that are looking very promising in that area and will hopefully send out a paper next week with some new results on Alzheimer. So that is one area: we are actively really interested in diseases and the direct link to diseases is a major thrust within our group.

Another thing we take pride in is our track record. Unfortunately nobody ever keeps track of what people have claimed as results in their distributed computing projects and whether they have backed up those claims. It is interesting to look back at the things that we have done and the publications that have come out of it, maybe 15 or now perhaps closer to 20 papers directly from folding at home, and I think that is unmatched by a factor of ten over any other project. So we have been extremely productive and the productivity is not just in terms of claims that we have results but actual results that are peer reviewed, tested and validated by the scientific community. I think those two areas, direct connection to disease and the track record that we have, are the parts that I am most proud of.


NJ: So basically the fact that you actually get results is another good reason why people should join in?
VP: At least for me personally, that is something I do really care a lot about - not so much about the distributed computing per se as much as using it to accomplish something which really couldn't be done any other way.


NJ: Okay, so then moving on with the next question: Being that Team MacOS X, which I am a representative of here, is primarily a team that runs Macintosh computers there are few questions that other team members asked me to ask you about. So we will go ahead and get started on those. The main issue on their minds, of course, is the Tinker work units and I am sure you get very frustrated with some of the stuff that comes down from those. I guess the first tough question I can ask is how important are the Tinker work units to the overall project. For example, I am a new folder and I get a Tinker work unit on my machine and it may take 4 to 10 days or more to complete. Why should I keep at it instead of just bagging the project or throwing that work unit away and hoping for a much faster Gromacs unit?
VP: Yes, certain of our Tinker projects have been running for over a calendar year or maybe two calendar years. These are long term, extremely important calculations that couldn't be completed in a shorter time frame even with Folding@Home. And it's really quite a grand project. I could describe the details but basically they are some of the hardest things we have ever tried. We are hoping to wrap up the first set of results of the long time Tinker projects and send those out for publication in around three months. Actually I am very excited about it, these calculations really push the boundaries of what one would think is possible to do. Many of our newer calculations have been Gromacs; these projects typically run for just a few months and the calculations are different than those done with Tinker. There are certain things that can't be done with Gromacs and can only be done with Tinker. Amber fits somewhere in between. Some of the calculations we now run in Tinker can also be run in Amber and we are thinking about switching some of those over to Amber because it will give us a big boost in speed - in some of the areas of overlap we are going to be running more Amber things than Tinker. The particular scientific calculations that are done in Tinker are actually still very important and have been part of the motivating feature for getting Amber online.


NJ: Okay, and is there a time frame as far as getting Amber over to the Macintosh? As I understand is that they are not exactly ready to go for the Power Macs yet?
VP: I think we want to avoid a scenario similar to the Tinker scenario for Macs. Amber does not have AltiVec or SSE , and it is also written in Fortran code, so we are going to have the exact same issues with Amber optimization as we did with Tinker optimization. For that reason we haven't made a big push to port Amber until we figure out what would be a reasonable compiler to use there and how to optimize it.


NJ: Now we all understand that Tinker's are notoriously slow compared to Gromacs especially on PowerPC hardware and it's said that Fortran is chiefly responsible for the slowness as it is not well optimized for Macintosh. Now, of course, one of our team members is working very diligently on that in a volunteer capacity. Besides him, are there any internal people working on the optimization or will we have to wait and see what happens with our guy's work and then go from there?
VP: Every once in a while we test a few new approaches, but it is a complex problem - there is much more to it than small scale tweaking. I believe it is TommyJay that is working on the optimizing?


NJ: Yes, that is correct.
VP: I have been trying to follow his thread there at your forum. It seems that he has been able to speed it up a little bit, but the available compiler for PowerPC won't be able to bring it to a level with what we can do on the x86 hardware. Is that a fair summary of the current status?


NJ: Yes, that seems to be right ­ we are seeing something like a 24 percent increase in speed, which is reasonable, and good compared to what it was, but still leaves the Mac at a disadvantage.
VP: One of the problems he had with the compiler was that for older versions of OS10 there was a bug in the square root, or one-over-square-root function, and so we could release the faster version but only for OS 10.3. And part of the problem is that we have to distribute code that can run on a variety of Macs. To require prospective folders to have the very latest OS10 version would probably cut some people out.


NJ: Exactly, and that is perfectly understandable. Okay, in terms of the overall project have your servers actually been set to limit the Tinker work units being assigned to Macintosh machines or are Tinkers offered to all machines equally?
VP: We are trying to do everything we can to keep Tinkers away from the Mac, because Macs do so much better with Gromacs. A couple things we have done are first, that Macs are only set to communicate with Gromacs servers and also right now Gromacs is the default work unit which you get when you start up or the when server cannot identify the CPU type.


NJ: Do you know that we have people on our team who fold on PCs as well as Macs?
VP: Yes, I noticed it when visiting the forum and was a bit surprised to see a lot of discussion about different ways to set up the PCs. I thought that was very unusual and actually kind of neat.


NJ: Well, on our team we pride ourselves as being folding-centric rather than being specific "computer type"-centric and so we are trying to make folding the forefront. We just like OS10 better than Windows for various reasons.
VP: What I also liked about that is that there are people like me who use Windows at work for a variety of reasons, sometimes because it has been imposed upon us, but at home, where we get to choose what we use, we have Macs. Actually the only machine I have at home, which my wife uses also, is an iMac.


NJ: Yes it is a very common story that I hear quite a bit. On that issue one of the new technologies that has come out on the PCs, for example, is hyperthreading. There has been a lot of flap about hyperthreading on some of the folding forums and P4's and Xeons have become somewhat of a controversial issue, at least among the user ranks. You have apparently stated that you preferred folders not to use hyperthreading and one of the questions people have is this: how much of a liability is hyperthreading to the overall project? And why should users who are able to run hyperthreading, choose not to?
VP: It is hard to give a good analogy to this situation - the full technical details are in our papers, but to try to make it a little more intuitive a lot of what we are doing is like a race. If you can imagine having a choice between racing with one race car with a really powerful engine that can go, say 300 miles an hour - or two cars that will run slightly faster than half of that -like 180 miles an hour, which one would you choose? Actually that is not a bad analogy to hyperthreading. Hyperthreading is basically taking a really fast CPU and turning it into two slower CPUs that are slightly faster than half the original speed, which gives you only a small increment in power, about 10 or 20 percent running flat out. The problem is that in a race, by having two slow cars instead of one fast car you don't come out ahead even if you do cover a bit more ground in total. In some of our calculations, you have to wait for everybody to finish before you get the answer - so by having people running these slower cars means the whole process takes longer.

Point-wise it is true that hyperthreading produces more points, no question. And we are at the stage where we want to encourage people to fold and if people are more comfortable folding with hyperthreading on, we are fine with it. We really do welcome everything we can get, which has been wonderful so far. If people care about what would be the best thing for the science, they should understand what hyperthreading does and that actually it is not ideal science-wise. Well that is the scenario, but either way we are happy with the wonderful contributions we are getting.


NJ: One of our people asked me to ask if there are plans to limit or eliminate the ability to use hyperthreading or even more generally to limit people from running more than one core per physical processor.
VP: No, actually our plans are just the opposite, which is to have the core detect and utilize all available processors directly, instead of needing to run separate clients for each processor. The new core would run two processes or threads and use both threads to do the calculation and that is the best solution to this because in this way the multiclient thing is just taken care of for you.... Let's go back to the racecar analogy to look at, say, an SMP machine. If you could run a core that uses both processors, instead of having two race cars at 100 percent you would have one race car that goes twice as fast and that's even better. So basically our solution there lies in trying to have the core take care of this. It's in progress but it is really not trivial to do, the scientific calculations are pretty tightly coupled and using two processors at once is tricky to do well. Right now the only software that handles this well is Gromacs in a threaded way, but we have some tests in the lab that are looking pretty promising. So that is the future of it, especially on the Intel or x86 side. There is going to be more need for this once the multi CPU machines are commonplace.


NJ: Yes, that is definitely something, I am sure, that you are eyeing with great anticipation.
VP: Yes, we are trying to keep on track such that before multiprocessor machines come out that we will be all ready. We want to try to make it easier to run on multiple CPUs, yet in a way that is most helpful to the science.


NJ: One of the things that you see as far as when it comes to performance and trying to get a work unit in on time, one of the things that you guys have implemented is a performance fraction. If you look through your FAHlogs you can see this - whenever you return a work unit and get your new one it displays a performance fraction. What significance does this actually have in work unit determination and is there any future use of this that we have not seen implemented yet?
VP: Yes, we use it - if you go to the server status page, the webpage that has all the server information, you will see certain servers have minimum performance fractions. We use performance fractions to direct fast CPUs to certain servers and the slower CPUs to other servers. There are a lot of benefits in doing this. One is that it helps ensure that all clients get work units that can be completed in a timely manner. The other thing is that it's useful for us to have a sort of homogenous set of computers on each project, and grouping them by performance fractions helps us do that.

At our last group meeting on Folding @ Home, we had a discussion about whether it was really working out as well as we would like and how to improve the way we use it although it is much better than most benchmarks someone could have. For example, with a pure processor benchmark, the performance doesn't tell you what average fraction of the CPU a person is using for other tasks besides folding. The performance fraction is probably the most reliable measurement you could have to predict the probability of this person sending their work unit back at a given fraction of the deadline time.

Right now performance fraction is used very heavily and we are trying to be even more creative in how we use it. Every three months we have an internal audit for how efficient Folding @ Home is, where we brainstorm ways to tweak the efficiency without ruining the stability or making it harder for donators or whatever. But performance fraction is rising on our priority list to address.


NJ: That is kind of what I wondered about, about the D-Gro's and the Amber core as far as they becoming a larger part of the project, you answered that in affirmative they will be, as least that is what I got out of it.
VP: Yes, we didn't talk about the Dgro's so much but the Dgro's are for a particular type of drug binding calculation - and our group is about to roll out another big batch of those, so I think they will come back in a little bit too.


NJ: Okay, now in the past there have been people who have cheated to get additional points and in their cheating have actually done things that could cause bad publicity for the project. Are there any pro-active steps that are being taken by your team to protect the good name of this project?
VP: Yes, absolutely. I think the next client version, version 6, will include some pretty wide, sweeping changes to try to handle some of the problems that have occurred. I think so far everything is under control, but this is the type of issue that we have to be pro-active about. Not all of these changes are confirmed in the version 6 roster release time line but there are a couple of things that are going to be there.


NJ: Moving into some lighter more general interest stuff, I don't know if you have these figures in front of you or if you can just rattle them off the top of your head, but what kind of growth has this project seen over, lets just say, the last year?
VP: Well, actually I don't have that figure with me, but the website has a graph of it. Enrollment tends to go in spurts but over the last year we have gone from averaging around 120 thousand (active CPU's) to averaging 170 thousand. It's a pretty big jump, 50K, around 40 percent or something like that. I think there will be even bigger increases in this coming year but we will see.


NJ: One of the other questions here is how many work units are received on average per day but you kind of answered that with how many per hour.
VP: You also can get a sense of that from the server status page. The page is kind of cryptic because it changes so much - in part to explain everything right there - but it displays how many work units have been received by each server and it has totals on the bottom line and each hour, I think the totals are in the order of like 4,000 or 5,000 - a huge number of work units coming through every day.


NJ: Do you have any idea how much bandwidth gets used daily by all those work units coming to and from your servers?
VP: Yes, every once in awhile we get an audit from the university. What is interesting is that we're usually among the top ten biggest bandwidth users in Stanford, but I don't think we have ever been in the top 5. Which is actually something I'm proud of because we are doing everything we can to minimize the bandwidth, not just for Stanford but also for all the donators. I don't know the number offhand, but we probably can guess it: roughly 100,000 work units go through a day and each one on average is like half a megabyte, so that would be around 50 gigs worth of data sent to us and since every time you send a work unit you probably get one it'd be roughly 100 gigs worth of data transferred every day.


NJ: Okay, kind of getting into the bandwidth for the end users type deal, on our team a lot of people ask how do they get their administrators or their work or school systems to start folding and one of the things that they hear is that to the administrators, bandwidth is a concern. They want hard numbers; they want a way to say, okay this is or is not going to be a problem. Does your team provide any information on how much internet or network bandwidth per processor or even bandwidth per work unit that Folding@home would average?
VP: Yes, that is easy to do. Roughly, if you are not going to do big work units, it would be like a megabyte per processor per day.


NJ: So about a megabyte per processor per day.
VP: I think people who are donators who run Folding@Home can do their own estimates. It is not going to vary drastically by more than a factor of 2 or 3. But this kind of bandwidth is really pretty minimal if you have a broadband connection. At home for a while we just had a modem, so I know how feeble that can be even for a few megs. But at a school or office they are not going to have a modem. The bandwidth should not be an issue at all - I think the greater issue may be memory. Many older computers in schools don't have a lot of memory, say 64 megs or something like that, and for those computers Folding@Home could become a problem.


NJ: And staying on another bandwidth issue, more and more people are going to be migrating to DSL and cable modems and things like that for high-speed broadband. You've introduced work units, that can be specially asked for, that are upwards of 5 megs. Are you planning on an increase in the size of those work units if the 5 meg work units are particularly successful?
VP: Yes. Right now the big work unit box says "5 megs or greater". I forgot what the new upper limit is - it is like 10 or 20 - so anywhere within that range of 5 to 20 meg is accessible when you click on the "big work unit" box. We are still trying to keep these things as small as possible, but for some of the biggest ones, the data being sent back is as much as 7 or 8 megs. Just in terms of storage on our side, there is a limit to how big we can make these units, because all the data that people send back has to be stored here and it adds up really quickly. So we are probably not going to get any bigger anytime soon.


NJ: On the 5 meg work units obviously the Ram requirements have exploded as far as what they would use. With the invention of newer and faster machines and cheaper RAM do you anticipate the RAM requirements to keep increasing or have you kind of hit where you are comfortable with at this point?
VP: Yes, given our current mix of calculations the ram requirements are not going to go up very significantly. There is a scoop that I can give you guys: there is a possibility of another core coming online which would be a radically different type of calculation and there the bandwidth is trivial, like Tinker bandwidth or even less, but the memory requirements would be pretty high - more like a gig. And so those will go out as big work units even though they are not big in bandwidth but only in memory. We can make sure that these aren't assigned to machines that don't have enough memory and we want to try to make sure that we don't take all of the memory that people have - unless the donator is running under the "advanced methods" flag and specifically asking for something more complex. So yes, there will soon be units that will easily require one gig.


NJ: Okay well that kind of wraps up all the questions that I have. I really appreciate your time in answering the questions and I guess we can wrap this up for now. Did you have anything else you wanted to say?
VP: Well I really do appreciate all the things that you have done. The article at Apple.com is really great and was a huge help with contributions. And also all your work with the team is a great contribution and I really thank you for all your passion and the help you have to give us. Your team has done great things too. And what I especially appreciate about them is the fact that you guys are proactive about doing things to support the project. Tom's work looking at the Tinker core is a great example of that. Unfortunately I don't have time to do an interview like this for every team, but you guys have done so much for us. It was just a joy chatting with you Noah and I'll hopefully see you guys participating even more in the future.


NJ: Well I really appreciate that, it means quite a lot coming from you, and we will definitely continue our work to make sure that folding is a great success. And I really appreciate your time - and I'm glad we didn't get cut off!
VP: Yeah me too, great and thanks so much, hope to keep in touch.


NJ: Great.
VP: Bye.