August
Back to top
August 9, 2013
It's been clear for a while now that we won't get Phoenix++ running on VSoC while I'm still working on the project. I was pretty dejected about this for a while, but someone (actually, probably many someones) once told me that I can learn from my mistakes. I tried to look at my attempts as a learning experience, and now I'm much more satisfied. This is the cool thing: none of them are in any way specific to computer science research. Here is what I have learned:
1. If someone tells you to do something, write it down. I know my mother is going to read this and think, "Seriously, Abbie? I've been telling you this for years!" Hi there, Mom. This one is for you. Every week, I meet with my professors, and we come up with things to try. I noticed that I only ever remembered about 50-75% of what we talked about, and that occasionally the same idea would be brought up two weeks in a row. On a related note, if you suddenly have a bunch of ideas, write them down before you try any of them. If you're anything like me, you'll probably forget what you were thinking as soon as you start doing something else.
2. My high school teachers (and college professors) weren't just giving me busy work when they made me plan out my projects. I always figured the teachers were just trying to make sure everyone was on track, or maybe trying to punish students that blew off small assignments like proposals. I always preferred to take research and programming projects by the seat of my pants, and in school, I always succeeded. But not in real life. I tackled porting Phoenix++ on VSoC by literally just plopping the Phoenix++ directory into the VSoC apps directory, and hoping for the best. I thought I could succeed with the same process I use for small programming assignments : continually attempting compilation, and making small fixes for any errors that occurred. The problem with this method was that Phoenix++ and VSoC were enormously more complicated than anything I had ever dealt with before; every time I fixed one thing, another thing broke. Also, I didn't write any of the code myself, so I didn't have the same level of familiarity I am used to when debugging. If I could do it again, I would make a detailed plan first.
3. If you can't solve a problem, make it into a simpler problem. I learned this in math a long time ago, and have found it very helpful. I've used this method a lot in algorithms class, but I never thought of applying it to programming. This is related to good planning. Not only should I have made a plan, I should have made a plan that broke up the task of porting Phoenix++ on VSoC into smaller, simpler, more manageable tasks.
4. Document your efforts. Because I was a grading teaching assistant from early on in my computer science career, I've always been conscious about making good documentation in case anyone else needed to read my code. I should have realized this applied to research. I'm not writing much of my own code, but there will still be someone essentially reading my experience. It will be extremely valuable to my successor to have a complete record of what I tried, and what happened when I tried it. As it is, I can barely remember half of it. My predecessor will be stuck with a vague description of some of the things we did, and will end up stuck down a lot of the same wells.
5. Analyze your mistakes and write down a list of things you learned from them so you can do better next time. Haha. Before I wrote this post, I still felt dissatisfied and disappointed with my work. That's really not helpful at all. Now that I have understood and put into words what went wrong, I can be a better member of a team working on a big project.
A final note: I have a feeling my dad is going to read this and go "You know, I've always told you that" for at least half of these. I am pretty sure that someone has told me every single one of these things at some time in my life or other. If you were one of those people, thank you, and I'm sorry I didn't listen the first time. But sometimes it takes a real experience to drive the message home.
August 5, 2013
Once again, the reason I haven't posted in a week is because we have still not made any progress on getting Phoenix++ running on VSoC. We haven't even seen any different error messages in about a week. Every time we try to compile, we get an error with the linker that is something like, "libg.a uses hardware FP whereas kmeans uses software FP." We've tried just about everything we, or anyone on the internet can think of to no avail. I've read so many help forums on this that I'm starting to recognize the names of people who post about it a lot. We tried everything from messing around with the Makefiles, to running a script to build a new version of the cross-compiler we're using. We have had no luck whatsoever, so one of the grad students is going to write to the people who made VSoC and ask them if they ever encountered this problem. I'm starting to get nostalgic for that time I spent one whole day (oh, the horror!) googling error messages (see my blog post on June 20).
Last week was also extremely busy because I had to make a poster for a poster session. This was really valuable because I had lost sight of the big picture, and making the poster helped me to rediscover what my work has been building towards. The drawback is that there were no results I could really put on the poster (there still aren't). Luckily, everyone acknowledges that this is an extremely difficult task, and that I'm not expected to finish it quickly. I now have about two weeks left, and I'm starting to get nervous. I want to get Phoenix++ running on VSoC because I really want the chance to play around with the parameters of VSoC and see the results of the hardware profiling. Then I'll be able to compare them to the graphs I did earlier in the summer and draw some conclusions. This would also be nice, because then I would have some results to use on the poster the next time I present it.
July
Back to top
July 24, 2013
I've been putting off posting because every day, I go home saying to myself, "Ok, tomorrow's definitely going to be the day we get Phoenix++ running on VSoC!" Basically I've been wrong every time. This is not to say we haven't been making progress- we've gotten through a whole sea of errors that could be fixed by changing the name of a function or a variable here and there. But there are two larger issues we've been attacking.
We resolved one of them earlier this week. Phoenix++ had some inline assembly code, which is basically means that the programmer sometimes used blocks of assembly code instead of C++ to write really fast functions. This is pretty cool, but there are different kinds of assembly language and they're not compatible. Phoenix++ lets the user decide between two options: SPARC or x86. Unfortunately, we're compiling Phoenix++ to VSoC using an arm-elf cross compiler, which uses ARM, so we had to translate the functions from either SPARC or x86 to ARM. Most of it was pretty straightforward. However, both SPARC and x86 have a locking mechanism that doesn't translate to the early (ish) version of ARM we're using, so we had to figure out how to implement locks using the ARM instruction set. We finally succeeded in this yesterday, which leaves us with one big problem.
The main issue now is an incompatibility between the arm-elf cross compiler, and the Phoenix++ code. The Phoenix++ code uses software FP, whereas arm-elf and the associated C++ libraries use hardware FP (these are conventions for treatment of floating points). This leaves us with two options- change the Phoenix++ code to hardware FP, or reconfigure arm-elf-gcc to use software FP. It's been two or three days we've spent working on this problem, and so far, nothing we've tried has achieved either of these results. The main failure is that we can't reconfigure arm-elf because we only have the binaries, and not the source file, and we can't use another cross-compiler because VSoC doesn't seem to like output from ones that are not arm-elf. As for Phoenix++, inexplicably, no matter where and how often we include the hardware FP tag, Phoenix++ still uses software FP.
So for now, it feels like Phoenix++ is a square peg and VSoC is a round hole, and like I'm probably the most stuck I've ever been. But you never know, I'm still going to go home telling myself that tomorrow is definitely going to be the day we get Phoenix++ running on VSoC.
July 18, 2013
Earlier this week, Sophie and I were able to get some C++ code running on VSoC quite easily. Everyone agreed we better start trying to get Phoenix++ running as well. We knew this step would take a long time since it is a really large and complicated bit of code. I've only been working at this for three days and I'm already realizing that it's even more complicated than I had previously imagined. For some reason, the creators of VSoC decided it needed to be compiled with the arm-elf cross compiler. It seems that at every step, arm-elf really does not like Phoenix++. This has mostly forced us to link all sorts of libraries, and create really big makefiles. My most recent adventures have included translating bits of inline x86 assembly code into inline ARM assembly code. I'm sure there will be more issues after the inline assembly code is compatible with VSoC. This is the first big part of my work this summer that hasn't ever been done before. For that reason, I'm really excited to get this step done, but also nervous that it's actually impossible. I feel like we're making progress every day, and that we might be close to success, but you never know.
July 12, 2013
This week has been fun because there's now another undergrad, Sophie, on the project. Our goal for this week was fairly straightforward. We were to get a Ubuntu virtual machine running on our laptops, and then get VSoC, a simulator, running on it.
The first part gave us no trouble, but installing the simulator was a different story. It turns out that the set of instructions weren't up to date, so we had to figure out parts on our own. Then, it turned out that VSoC requires the arm-elf cross compiler but the Ubuntu vm only had an arm-rtems cross compiler. Apparently this makes a big difference, because with arm-rtems, the simulator was almost completely nonfunctional. Installing arm-elf had more setbacks than I could have possibly imagined. The first set of instructions I followed took me all day, only to fail at the very end. One of my other attempts resulted in me having to erase the simulator and all the associated files from the Ubuntu virtual machine and start all over again. Finally, one of the contributors from Swarthmore sent us his copy of arm-elf, and I was able to get it working. Sophie was not as lucky, but we're pretty sure that it'll work if she rebuilds the library from the very beginning.
Next week, our goal is to get some benchmarks running on VSoC. Before our friends at Swarthmore sent over their list of benchmarks, we found several of our own. One of them had some pretty sexist functions, such as woman.make_me_coffee( ), and hot_woman.spend_my_cash( ). From what I hear, it's not abnormal to see things like this in computer science. I'm pretty sure this is why we need more women. Anyway, next week we're going to run some bench marks, and then we're going to try to get Phoenix++ running on VSoC. I'm really looking forward to next week because the testing is fun, and because I now have someone to share ideas with all the time!
July 9, 2013
This is what I did today:
It looks like when they hack into the government on TV. Either they're faking it, or I should start worrying.
July 8, 2013
PAPI was very short-lived. It only made it until Friday, when I found pretty good evidence that it's just a wrapper for perf (the tool I was using before). Too bad I didn't notice that before I spent two and a half days trying to integrate PAPI into the Phoenix++ tests. This is alright though, I had already gathered a lot of data from perf. We had a meeting on Friday and decided that my results supported previous conclusions, and that we should move forward.
The next step is to try to get Phoenix++ running on VirtualSoC, a many-core virtual platform by UniBo. Today I've been working on downloading and installing VSoC. After that, I'll practice using it, and once I'm familiar with it, we'll try to get Phoenix++ running on it. I'm meeting with the rest of the group tomorrow, so hopefully I'll be able to start playing around with VSoC.
July 2, 2013
Yesterday I decided that I've done just about all I can using perf, at least until the professors get back on campus. Dimitra had suggested I check out a tool called PAPI, so that's what I did. I read through all the documentation, downloaded and installed the tool, and ran several of the tests that looked useful.
It's a little more difficult to use because, unlike perf, it seems like the user has to integrate it into their code. It's also not very well documented, and some sources seem to say there are versions of it that rely on perf. This would defeat the entire purpose of using PAPI in the first place so I really hope that it's not true.
Today I worked on including PAPI code in the Phoenix++ tests. In PAPI, it's not as trivial to count events while another program is running as it is in perf. It's also pretty hard to find what I want in the PAPI documentation so it's been slow work. I'm meeting with some professors and grad students tomorrow, and we'll hopefully figure it out.
In other vaguely related news, I got my artificial intelligence textbook and The C Programming Language this weekend. I'm excited in theory but in reality I'll probably get distracted and forget they exist until September.
June
Back to top
June 27, 2013
I haven't posted because I've been doing the same thing all week, and all of my professors are on vacation, and the grad students are busy with other things. It's been a bit slow, but if I send enough emails, things tend to get moving. Meanwhile, I've been making graphs of data and cleaning them up. I've also been running more tests on different sized data sets, and making graphs for those.
The weird thing about the output is that some of the numbers don't add up when they should. They're off by several orders of magnitude, which leads us to believe that they're not really representing what we think they are, or that the tool isn't counting what it thinks it's counting. I've been trying to come up with possible explanations, but in the end I think we're just going to end up using another better tool. I'm not super thrilled with this because it means more spreadsheets and graphs. At least I'll be motivated to do everything very quickly so I can hopefully move on to something else!
June 21, 2013
I'm pleased to report that today was one of the best days I've had at work so far. You should be happy for me, because yesterday was so bad it made me question everything I ever wanted to do in my life.
I spent most of yesterday googling an error I had in a tool called perf. The only fixes I could find either involved changes I did not have permission to make, or were extremely poorly explained. In the end I got so desperate I emailed a complete stranger who possibly lives in Shanghai to clarify his fix for the problem. I then spent the rest of the day trying to download a C++ library I needed called Threading Building Blocks. It worked without a hitch on my laptop, but for some reason didn't seem to want to play nicely with the linux machine I was using. I spent an extreme amount of time googling my problems before giving up on TBB completely, and praying that I wouldn't actually need it.
After spending most of the day in a windowless refrigerator of a room googling error messages I walked home thinking, Abbie, why would you even want to do computer science research anyway?
But luckily, three things happened:
- I ate some food and I felt way better. Always a good fix.
- The random stranger on the internet emailed me back in the middle of the night
- I tried his fix this morning, and it actually worked! Thank you so much, random internet stranger!
Also, it turned out I really did need Threading Building Blocks, but it's alright! The problems I was having using TBB yesterday have inexplicably vanished. So right now I'm finishing up running the last of my tests. I then plan to make some lovely graphs detailing run time and cache miss rates, and I'm feeling pretty good about this whole thing!
June 20, 2013
Right now, I'm impatiently waiting for an email from the computer science department so I can finish gathering data from my tests, which now all successfully compile and run!
This was my main development so far. I had hit a roadblock with getting the tests to run, so I arranged a meeting with Chris on Tuesday for help. But that morning, I got all the tests to compile with the new compiler by debugging them. That day, I ran all the tests on various inputs and with different parameters, and by the time I met with Chris, I basically knew what was going on.
I planned to finish up collecting and analyzing the data on Wednesday, but there was an system update scheduled for that entire day. I was only able to run several tests before the system went down. This was really frustrating because I had just started to get valuable results. In the meantime, I caught up on some readings I hadn't understood, and I started going through a C++ tutorial in case I had to change the code any more.
This morning, I was excited to see the system was back up. I submitted a test I had already run just to see if everything was still working. It wasn't. The tool we were using to gather data has been uninstalled during the update. I'm hoping to hear back from the department soon that they've reinstalled it so I can finish off the rest of the tests and find out what to do next. Until then, I guess it's back to the C++ tutorial.
June 17, 2013
Hi! So I'm trying out posting daily to avoid hugely long posts like the one from last week. Here we go!
Last week, I had only gotten two out of around six or seven tests to compile and run. Today, I tried to fix that. I told the makefile to use an older version of gcc and g++ that wasn't as strict, and all the tests compiled. YAY!
... except none of them would run since I used the old version. Darn. I guess they updated the compiler for a reason. So I put the newest version back and now am back where I started. Tomorrow we're going to try some things, but I'm probably going to have to just update the C++ code so it compiles. After that happened, I decided to just keep doing what I could do with the tests I could run. I was able to duplicate some of the results from the spring by changing the containers and combiners. I also found an extraordinarily long Intel manual that might help us figure out what some of the results mean.
Tomorrow, I'm meeting with Chris in the morning to try again. I really hope we can get the rest of the tests running by lunch so I can repeat the rest of the results, and use the Intel manual to figure out some new ones.
June 14, 2013
Hi! So my original plan was to post about my work once or twice a week, but I'm thinking I'm going to post more often than that because this is a really long post.
Here is a tl;dr summary: In case you are one of my relatives reading this, tl;dr stands for "too long; didn't read." On Monday and Tuesday, I got my accounts set up and read an enormous amount of papers, some of which I understood and some of which I did not. On Wednesday, I practiced running some tests in Phoenix++, which is an implementation of a problem solving framework called MapReduce. Since then, I have been collecting data about what goes on in the hardware when I run tests in Phoenix++.
Here is the detailed version: By the way, this part is really long. I'm never waiting this long to post again. I promise from now on the posts will be a lot more manageable! Anyway, it's weird that I've already been in Providence for a week. I feel like I've been here for fewer than 24 hours. It also doesn't feel like I've put in a full week's worth of work, but I promise, I have! Here is the proof:
On Monday I met with Professor Bahar for the first time. We took care of administrative details, she introduced me to her graduate students, and she gave me many readings so I could become familiar with the subject matter. My favorite was the MapReduce paper from Google. If you ever considered reading it, I highly suggest you do. Many real world problems generalize to problems for which MapReduce is a solution, like counting the number of word mentions on a page, or linear regression. I also read a paper about Pheonix++ (an implementation of MapReduce for shared-memory systems), a paper about tightly-coupled shared-memory clusters, and several papers about prior and future work on this project. It took me a long time to get through the paper on tightly-coupled shared-memory clusters, and I'm pretty sure I understood none of it. Our goal is to modify Phoenix++ to run on an architecture comprised of multiple tightly-coupled shared-memory clusters, so hopefully I'll achieve understanding by the time that knowledge is required.
Tuesday was very similar. I finished up reading the papers and began trying to get Phoenix++ running on my laptop while I waited for my Brown accounts to be set up. Phoenix++ was developed by some researchers at Stanford, and it is basically a C++ library that facilitates MapReduce. You can download it and read more about it at mapreduce.stanford.edu. It comes with a bunch of problems that can be solved with the MapReduce framework that researchers use to test the efficiency of their MapReduce implementations. There's word count, histogram, linear regression, and several others. I compiled and ran all the tests on my mac. At this time, I tried to remotely run them on a linux computer here, but could not get them to compile, so I played around with the Phoenix++ parameters for different kinds of workloads.
On Wednesday, I tried again to get the tests to compile on the linux machine again. The only ones I could get to work were linear regression and a test called kmeans that groups n-dimensional data points into k groups, and finds the mean value of each group. I met with Chris, one of the grad students, for help. He was extremely helpful and walked me through the compilation process and the job submission process, but the linux machine I had been using was down, so I had to wait until the next morning to try again.
On Thursday, I tried to submit the scripts I had written to test linear regression the next morning with no success. Every time I submitted a job to the research computer, it got stuck in the job queue. Luckily, I had a meeting with some of the professors and grad students before lunch, and we discovered the reasons behind my compilation and submission problems. I couldn't compile all of the tests because the linux machine was running a newer, stricter version of gcc (the c++ compiler), and I couldn't submit jobs to the research machine because my username had not been given clearance to do so yet! I was super relieved because neither of these things were really my fault. Once I was granted access to the research machine, I submitted my jobs, and they worked! My next order of business was to run the same tests Chris and Dimitra, two of the graduate students, had run in the spring to collect data about what the hardware was doing. I did so, but I didn't realize some of the commands would take so long to execute, so I kept killing the jobs before they were complete.
As of right now, on Friday, I have put the jobs all in separate scripts, and have attempted to run two of them. The first one terminated in error while I was at lunch. The other one is still running, and will hopefully not terminate in error. Once I run all the tests, my plan is to compare the results to those that Chris and Dimitra got in the spring. Then I need to discover what exactly the output means by researching what exactly goes on in the hardware of the machine on which my jobs are running. In the meantime, I'm going to reread that paper I didn't understand, and try to become more familiar with using C++ because I may eventually need to develop a better understanding of the Phoenix++ source code. In other news, I'm still waiting for a lot of administrative stuff to come through, like a Brown email address and a Brown ID, which should make things easier.
Thank you and congratulations to the diehard readers who made it to the end of this abysmally long post about my week. I promise I'll post shorter, more manageable posts more often in the future!
Back to top