This is the webpage that will be documenting my progress in my DMP research project this summer. Today, May 29, I am starting my job with Michelle Strout at CSU in Fort Collins, CO.

Mon, 6/04 10:30: Blah! I have now configured ViM to use spacefill (instead of tabs).

Wed, 6/06 16:03: I'm starting to work on my webpage.

Thurs, 6/07 10:45: There are a few things about Linux that are bugging me. Every so often, I'm working on something in a GUI and it just disappears. I don't know what's going on. The process just terminates in the middle of what I'm doing. It's happened a few times with Firefox, The Gimp, and now with my HTML editor! Bah.

Since I started working here, I've had to get used to a couple of adjustments. I think the biggest one is working with Linux. I'm used to Windows and GUIs, and using the command line has been quite challenging at times. I've learned a lot in the past few weeks, though. I've learned about a number of Linux tools. Here's a list of some of the stuff I've learned about in the last couple of weeks:

• gnuplot
• pico
• svn
• chmod
• gdb
• top
• ls -a

• LaTeX
• python
• using MySQL (as opposed to MS SQL Server)
• C-shell scripting
• gvim
• Thunderbird
• creating a .forward file

Fri, 6/08 9:49: Right now, I'm trying to debug a "practice problem" that Michelle gave to me. It works fine on 64-bit Linux and Solaris, but it's been getting seg faults when run on a couple of 32-bit Linux machines. I don't know why. It may have something to do with the timer, or the multiplication of two large integers. I'm trying to figure it out. GDB is saying that it's seg faulting during the fprintf statement. Some days I hate debugging.

Mon, 6/11 11:16: Michelle is gone this week (she's attending a conference in California) so we have to figure out what to do ourselves. My dad suggested that the fprintf may be causing problems because one of my data types might be wrong in the string section. i.e., I'm using %lf for a float (when I should be using %f). I'm going to try a few things and see if I can get it to stop seg-faulting in GDB.

Tues, 6/12 17:02: I wrote an uber batch file (a shell script that calls my other shell scripts) and now have 2400 entries in an SQL database, which I have used to make pretty graphs with gnuplot. Not only did I figure out how to put stuff into the MySQL database, but I figured out how to get it back out (with some queries to separate the data) and how to use it to make nice-looking graphs. I also fiddled with gnuplot and figured out how to put on some labels and fiddle with the key so it looks nice. I'll post the graphs up here tomorrow. All in all, I think it was quite a productive day. Now, off to Boulder for Game Development Club!

Thurs, 6/14 15:16: I'm having some trouble with SVN. I did something yesterday that was quite stupid. I wanted to move my files into a new directory. Seems simple enough. So I try:

carstensz> svn mv code/ first/

Great! It moved my code. But, wait, I wanted to move it into the code/ directory. I should have done:

carstensz> svn mv code/ code/first/

Ok, so, I try moving it back.

carstensz> svn mv first/ code/first/
svn: Use --force to override this restriction
svn: Move will not be attempted unless forced
svn: 'first' has local modifications

What? Fine, I'll force it.

carstensz> svn mv --force first/ code/first/
svn: Cannot copy to 'code' as it is scheduled for deletion

What? Ok, fine. I'll just remove the dang thing then.

carstensz> svn rm first
svn: Use --force to override this restriction
svn: 'first' has local modifications

Yes, yes, we've been through this before.

carstensz> svn rm --force first
D         startup/LaTeX2

Wait... Did that delete the files?

carstensz> ls first
ls: first: No such file or directory

Cursing myself silently, I attempt to retrieve my data. I try svn update, commit from grace (who is not connected to the network and has my files through svn), update again, back to grace and trying to add (as it informs me that those files already exist in the repository, of course!)... Nothing short of svn checkout to a new directory retrieved the data. I don't know how to go back to a previous revision; I'm not sure I can since I used svn rm on the files.

To make a long story short, I am now unable to commit. When I try to do so, SVN helpfully informs me:

carstensz> svn commit -m "Is it broken?"
svn: Commit failed (details follow):
svn: Directory '/s/bach/d/under/jrothenb/ILP/code/grace' is missing

When I try to svn rm the bad directory, then re-commit, it gives the same complaint. So I try a mkdir instead.

carstensz> mkdir code/grace
carstensz> svn commit -m "Is it broken?"
svn: Commit failed (details follow):
svn: Directory '/s/bach/d/under/jrothenb/ILP/code/grace/.svn' containing working copy admin area is missing

I'm half tempted to just make a file called .svn, but that might break it more. It might be best to just start over...

Mon, 6/18 09:34: My dad helped me fix SVN, so now it works again, and everything's in the directories I want. It's nice to have computer science friends and relatives.

Tues, 6/19 09:42: Alas, for I have to do the dreaded "write-up" and tell people what my project is all about. I'm not quite sure I know. (I'm also not quite sure it's working - it seems to have encountered errors in calculation for K=3.0/4.0 on nelson, the 32-bit Linux machine. I may have to look at the assembly code. If only I knew the right flag in gcc to produce assembly code...)

Tues, 6/26 10:19: I've been getting the weirdest performance issues. My program unrolls this code loop:

    for (i=0; i<M; i++)
    {
        for (j=0; j<N; j++)
        {       
            A[j] = A[j]*K;
        }               
    }

where K is a constant. I started out with the constant of 1.5. Ok, so, it worked for the 64-bit computers and was incredibly slow on the 32-bit machine. Looking at the operations per cycle, however, I think the performance was similar even though the times were very different. Ok, so, great. Now I try different constants: 0.0, 1.0/2.0, 3.0/4.0, and 1.0. For 0.0 and 1.0/2.0 I get great results! It's exactly what I want to see on the graph. For 1.0, the compiler optimizes away the loop, so I can't use it for data. Fine. But for 3.0/4.0, it's really slow! The performance is terrible - 100 times worse than for constants of 0.0 and 1.0/2.0.

Tuesday, 6/26 14:55: Stupid Bluefish editor crashed on me! I'm getting very aggravated by these seemingly random crashes. It happened quite frequently while using "Inkscape", a vector illustrator. I think it shut down at least 10 or 15 times when I was trying to make my two diagrams for my explanation of register tiling.

Anyway, the whole constants thing is rather bizarre. I'm running a bunch of tests, on other values of M (the number of iterations) and K (the constant used in multiplication), and I've noticed a couple odd things. Here are some interesting observances I've made:

• All constants less than .5 act like 1/2 (nicely).
• All constants greater than .5 act like 3/4 (not-so-nicely).
• For some value of M, the performance of 3/4-like constants vastly improves (and becomes similar to 1/2-like constants).
• Nelson, the 32-bit Linux box, gets floating-point round-off errors for the 3/4-like constants for all optimizations greater than -O0. (The other machines do not.)

In order to analyze it more, I'd have to make a bunch of graphs. I'm kind of overwhelmed by the massive amounts of data I've generated. If I put it all in the database, there will be about 20,000 rows in the table.

Thursday, 7/12 14:01: We've finally moved on to the next project. We spent a really long time looking at the performance weirdness that was happening to my last set of experiments. Basically, we could never figure out why the less than 1/2 constants acted so differently from the greater than 1/2 constants. I tried running PAPI hardware counters on one of our machines, grace, to see the number of floating point multiplications executed when the program was run, but not only were the results pretty much the same for K=1/2 and K=3/4, but they also didn't match the execution times and were generally wacky. So, we're going to give up, and move on, and put down our failure in the conclusion section of my writeup. Future plans: figure out what the heck is up with these dang constants! But for the purposes of actually getting something done on the actual paper Michelle wants to write, we're moving on. Huzzah.

Wednesday, 7/18 16:41: I understand my new project and I'm excited to start experiments. My first step is code generation with python. I'm looking forward to learning something new and having something to automate. Writing scripts is fun.

We had a tools session on Tuesday where we learned to use dot. It's a nifty program. It automatically creates a flowchart from text instructions. For instance, the following code:

digraph G {
    a -> b -> c;
    c -> a;
    a -> a;
}            

Turns into the following graph:



Pretty nifty, eh? Anyways, I like making my todo lists as graphs of sort, with main tasks pointing to smaller divisions. I made one by hand early on when I was working here:



It wasn't terribly hard to do, and I was able to move things around so that it was optimally positioned, but it took some effort and once I'd finished it I couldn't go back in and edit the text, or colors, or add or delete tasks very easily. So, here's one I made earlier today, which was generated by dot:



Since everything's text, it's really easy to edit, and I don't worry about placement or drawing the arrows correctly, as dot does that for me. It's quite handy.

Thursday, 7/26 15:45: I've been tremendously busy lately trying to finish up everything. There's so much to do before work ends and time is running out! What with coding, and finding errors, and trying to figure out the specifications for compiling it's been rather hectic. Half of the time I'm so busy I can't breathe and the other half I have no idea what I'm doing! It can be really frustrating sometimes but the times when I get something to click make it worth it, I think.

Wednesday, 8/01 14:26: This week is Stephanie's last week, and my second-to-last (or penultimate, I could say), and Michelle is away in Scotland helping her sister with her newborn baby. She is, apparently, "marooned," without working internet. I'm sure it doesn't bother her terribly much, as she's still able to help her sister and get work done preparing for the upcoming semester, but Stephanie is a bit put out as she was hoping to get her final DMP report reviewed before she left. I'm feeling a bit lost, as I keep finding out unpleasant things about my project - for instance, the fact that one of my compilations takes approximately 27 hours to compile. The next longest takes about 19 hours. Although I managed to do the two longest compilations over the weekend, I don't imagine I'll be completely done with all of them by the time I need to leave. I'm hoping to make a graph of compilation times to include with my graph of run times. If, that is, it finishes in time. However, Michelle did just call us, and apparently is able to check her email once a day by going over to the local Starbucks. Ah, Starbucks. So, that's good, and at least now I have a better goal! But there's no way I can do everything before I leave. I want to run experiments, write a technical paper, write a python script to generate a wavefront schedule... Oif. Too much.

Thursday, 8/16 21:31: Well, I am officially done. It was pretty fun (though there were some parts that were frustrating), and as such I am all moved out of Fort Collins (though I forgot a few peanut butter sandwiches in the fridge at work). Though my work officially ended last Friday, I wasn't finished with my final report and so came in on Wednesday to finish up and turn in my office keys. It's finally all done. Even though it was a lot of work and there were times when I had no clue what I was doing (or really didn't want to work on my paper), it was a great learning experience. If everything pans out, I'll probably apply to grad school for my Master's. I think I'd enjoy coming back to CSU. And I'm going to try installing Linux on my laptop. :)