BIOS, cpufreq, perl, sprinkles & cherries on top

The Undergraduate Research Commandments

by Stephanie Schmidt

1. Thou shalt do a lot of work.

2. Thou shalt have nothing to show for it more often than not.

3. Everyone in research shall pass through this phase.

4. Lie to thyself. Call it a phase even though thou shall know it will happen again.

5. And again.

6. And again.

When in the course of research, your allotment of tasks become disjointed from one another, remaining organized is crucial. Otherwise you won’t be able to avoid the problem of tasks falling through the cracks. This applies to groups of any size. As often as people stress this point, it’ll continually get blown off by fellow undergraduates as just one of those things seasoned professionals say to scare you. Er yeah...the folks brow beating this point, same ones who cry over bad documentation, once again have a valid point.

I promise for most schemes it’s not just busy work. Having the time to get through all the tasks per week is a different story entirely. Understanding the blog platform you are using is another good idea too, especially if posts go missing. Excuse this attempt to recapture the essence last week’s post covered. Debugging scripts, tweaking BIOS settings and learning the fun of redundant work sounds like an awesome week with so much progress made, eh? Quite.

Debugging should have its own class somehow in undergraduate requirements. I don’t care that people have their own method. Every debugging method boils down to the same handful of steps; what differs is the artistic way the steps are executed. Debugging a big file you didn’t write is scary. Especially when you’re a total n00b at the language. Just those ten lines I used to expanded a function brought with it a whole heap of warnings and bugs thrown up on the formerly working-ish program. Good documentation and cout statements were pretty much all that saved my sanity. Google is a great tool until you don’t know how to properly phase the bug in general terms.

The frustration iceberg was trying to find a compromise between perl variable syntax and command line expressions. Working around that one turned into hours of creative reworking to avoid any need for awk. Changing $1 to /$1 may be great for telling perl to not touch that variable. The command line, however, looking at that fix will act five year old being asked what is the square root of negative three. Failing silently is the worst problem a debugging entails. Wait, spending hours elbow deep in Google trying to figure out why an entire command line isn’t being grabbed only to learn oh...it’s not actually the code you wrote. Someone else’s piece is acting weird. Good documentation folks: not just a lame requirement but a means to cutting that debug phase in half if you can rule out bugs coming from pre-existing code.

A result of all this real world style programming has been a major change to my debugging method. I’ve started documenting outside of my code what steps I take to debug. It helps me revert on the fly back to old settings without bulk commenting out changes. Just because sometimes it won’t be your lines code that is causing the barf of bugs. Oh and updates? Don’t necessarily trust them, they can mess things up too. I’m looking at you Apple: ios4 has been a mistake to older generation devices.

Step back from the programming side of things. Appreciate how simplistically elegant the BIOS interface is for navigating. Getting into the BIOS itself can be an hour of frustrated restarts, mistimed keys & not hitting the correct key. Hint: it’s always delete. Except when its escape. Or when it’s F11. At least the restart button is universal. I give mad props to the BIOS interface though, because by enabling SpeedStep my data collecting life became easier. cpufreq actually started sending legit verbose data! cpufreq happens to be directly linked to a component within our benchmark software, which in turn is used when examining the collected data. Nothing important to hurry and get working you can imagine.

My tasks this week often had nothing, or very little, to show for themselves given how long they took to execute. Patience was key for jumping to the next task. Patience to integrate new information debugging brought and sucking up the pain of opening yet another instance of google or terminal. Patience is the hidden side to research. And lies. Lying to yourself that all that hard work gone unseen this weekend did something will be easier to accept under the lies of sprinkles & cherries on top.

We have toiled for 6 weeks, and alas......PERL

After an arduous 6 week battle with the benign concept of 'compatibility' our test machines simply did not want to accept, Stephanie and myself had seemingly finally made it to the point in our project that requires something we are familiar with: Coding. Such was not the case, however, as learning a new programming language, PERL, proved quite challenging.

One note of success this past week was coding in PERL to read a file, discard the junk, and output things in a much more organized fashion. Unfortunately, we were not able to make this work for my room, of which I was forced to manually clean. Some day.....

Aside from adding to my repertoire of French, Spanish, and C++, Stephanie and I also worked to expand upon Ben's GPU parsing scripts from last year, and also browsed through documentation to clean up and debug for our own future reference. We are confident that when we finish, our documentation will be PERLy clean.

Sudo 10 Degrees from the Sun

CUDA was not half the battle it promised to be with Ubuntu unlike Perf. I don’t know what Vince was talking about, rickroll loves Lady Gaga!

On to more serious notes, this week’s heat wave inspired in me a healthy respect for the unix command line. Something most undergrads don’t fully utilize until they’re higher up in their courses, at least for me. Naturally this is long after the useful commands have been forgotten. Google is only helpful when you know how to properly phrase the command query in question. The ability to utilize a system without a GUI should prove to be a good skill to have out in the workforce.

I think you’d be hard pressed to find any other research field that can be done from the comfort of home and still turn out meaningful results. Remote ssh’ing allowed the luxury working on rickroll without braving the triple digit heat to visit the setup in the basement. Two such commands that I learned to love for this portion of install, debug and then demanding the install has permission, were wget & sudo.

What throws up a permission error, sudo magically fixes.

(Image courtesy of xckd)

wget allowed for quick downloads directly onto rickroll exactly in the directory I happened to be in. If only they had this option in Windows, I’d never have to look for where a file downloaded again.

Now onto learning Perl & hopefully being able to understand it as well as document it. Who knew being trilingual would apply to programming languages?