The Boston Diaries

Wednesday, March 10, 2010

More on that “tool vs. crutch” debate

An empirical test of ideas proposed by Martin Heidegger shows the great German philosopher to be correct: Everyday tools really do become part of ourselves.

The findings come from a deceptively simple study of people using a computer mouse rigged to malfunction. The resulting disruption in attention wasn’t superficial. It seemingly extended to the very roots of cognition.

“The person and the various parts of their brain and the mouse and the monitor are so tightly intertwined that they're just one thing,” said Anthony Chemero, a cognitive scientist at Franklin & Marshall College. “The tool isn't separate from you. It's part of you.”

Your Computer Really Is a Part of You | Wired Science | Wired.com

More food for thought in the tool vs. crutch debate …

Tuesday, March 09, 2010

Now this is a gaming room …

For my D&D playing friends … (link via Instapundit)

“I keep getting these notifications that you've updated your site,” said Dad, “but when I check, I keep seeing the same page over and over again.” This was about the fourth or fifth time this topic has come up over the past few months. And each time I tell Dad to shift-reload but that doesn't seem to work for him, although the page eventually does change, after awhile.

Sigh.

I suspect I know the problem. Sometime in the past year I changed the configuration of my webserver to allow browsers and web proxies to better cache the content here:

ExpiresActive  On
ExpiresDefault "access plus 1 day"
ExpiresByType  image/jpeg "access plus 1 month"
ExpiresByType  image/gif  "access plus 1 month"
ExpiresByType  image/png  "access plus 1 month"
ExpiresByType  text/css   "access plus 1 month"
ExpiresByType  text/plain "access plus 1 month"

Images, style sheets, plain text files, all can be cached for a month (heck, they can probably be cached indefinitely for my blog—the content has never really changed all that much), but the web pages (in addition to the various feed files) can only be cahced for 24 hours.

And I think that's the issue.

Dad's ISP is known to aggressively cache the web (I won't name names, but it's initials are 'A', 'O' and 'L') so I may need to adjust my methods for caching values.

Adventures in profiling

Last month, Mark hired me on as a consultant to help him profile a program he's been writing. And while I can't describe the program (or the project the program is for), I can, however, describe the issues I've had with profiling this program.

Normally to profile a program, you compile the program using special compiler options (with gcc this is the -pg option) that instrument the program with special code to record not only how many times each function is called, but how much time is spent running each function. This information is saved when the program terminates, and you run another special program to decode this output into an easy to read format. Then you use that information to boost the performance of your program.

It's pretty straightforward.

This project, on the other hand, wasn't so straightforward. The primary issue—it's a multiprocess program; that is, it calls fork() to create child processes that do the actual work. It's the child processes that need to be profiled, but it's difficult to actually get the profile information from the child processes due to the way the profiler works (and both the GNU profiler (which I'm not allowed to use due to licensing fears) and the Sun Studio 12 profiler (which is the development platform for the project) work simularly, so this issue affects both).

Problem one—the output. The program runs and when it exits, the accumulated data is written to a file. This file is named mon.out (gmon.out if I were using GNU). In this case, the main program starts, creates several child processes. The ouput file is only generated when a process ends, and the only time a process ends in this project is when you explicitely stop the main program. This results in mon.out being overwritten by each child as they end, then overwritten again when the main process ends. So all I end up with is profile information for the main process, which tells me that the main processing loop took 99% of the time with only 0.01 seconds of CPU time (in other words—the parent process did nothing noteworthy). And there's no option in either the compiler or at runtime, to change the output file.

Or is there?

The file mon.out is generated in the current working directory of the running process. Change the working directory of the process, and the file ends up in the new working directory. So I modify the program such that each child process creates a new working directory based on the child's process ID and try again.

I ended up with one mon.out file in the working directory of the main process, and a bunch of empty directories. This leads to the second problem with profiling—you only get the output when the process calls exit() (or returns from main()), not _exit() (there is a difference between the two).

And replacing the calls to _exit() with exit() caused the program to hang (Mark even had a comment in the code about the C runtime handling fork() badly in the case of exit()).

So that pretty much killed using the compiler profiler options for this project.

Or did it?

The code is on a Sun server, which means it comes with DTrace, which is an incredible tracing facility that can be used to profile an application! Without compiling a special version of the program! Heck, you can profile any running process at any time!

It's a neat facility.

Just by using some sample scripts from the DTraceToolkit and a few examples from the Solaris Dynamic Tracing Guide, I was able to provide Mark with enough information to nearly double the performance of the program (major culprit—a ton of pointless strcpy() calls in a third party library being used, but that's about all I can say about that).

I was fortunate in that DTrace existed; between samping the program counter, recording the number of standard library calls made, and selectively checking the call stack to a few questionable calls (for instance, sprintf() calls ferror() if you can believe it, and tracking down the few hundred thousand calls to strcpy()) of selected child processes, I was able to profile this multiprocess program (and each process is multithreaded—a fact I didn't realize until later).

And if DTrace didn't exist? Well … there's the profiling equivalent to printf() debugging I could have tried …

Not the Messiah

Like Handel only funnier (link via news from me). Ah, so that's what Monty Phython has been up to …

Wednesday, February 24, 2010

Noooooooooooooooooooooooooooo!

Hollywood is creatively bankrupt

Sad. Just so sad.

Tuesday, February 23, 2010

Crawler Town

For my friends who are into Lego, I give you:

Crawler Town (link via kisrael.com)

Now, back to my regularly being sick …

Monday, February 22, 2010

Souvenir from a conference

I crashed hard, mainly because, I caught yet another cold (second this year so far—or perhaps a continuation of the first, it's hard to say). Snotty nose, tired, sneezing, the whole nine yards.

[Clockwise, starting at noon—tea cup, electric kettle, tea pot, loose leaf green tea, timer, tea spoon]

I really hate being sick.

Saturday, February 20, 2010

It is over

The git presentation was well received, as I briefly covered some basic git commands like git init, git add filenames… and git commit, along with a few different workflows one can do with git.

After that, a two-plus hour dinner at Macaroni Grill, dinner for 60.

Now, I crash.

A realization

While I was underwhelmed by the Drupal users group, I am not underwhelmed here at the 2010 Florida Drupal Camp.

But then again, I'm sitting through the Special Topics track, which have the more technical talks at the conference. Everybody has been very nice (obviously, they haven't read that post) and the catered lunch was quite good. I'm actually glad I came to this thing.

Now, to prepare for my git presentation …

My perspective on presentations

I managed to get through my presentation about “Project: DoogieHowser” although my presentation was a bit shorter than I expected it to be. But it appeared to go well with the audience.

Smirk has been recording all the sessions with the goal of putting up the videos at Drupal Maestro (where you'll be able to see my presentation, but not from my perspective).

And if that wasn't bad enough, I volunteered to do yet another presentation, this time about Git, since there was an open session and one of the suggestions for a topic was git. Since I use git, I figured I could do a quick rundown on how to use it.

Just a quick note from a conference

Of course I'm blogging from the conference. Why do you ask?

Notes from a hotel room from the middle of the night while listening to a heated discussion in Spanish

The Quality Inn room is very nice, but there were several men in a very heated discussion, outside as we were trying to sleep. Bunny called the front desk to complain, and was informed by the sole employee onsite at the time that the police were being called in to mediate the heated discussion.

Sigh.

An hour later, the very heated discussion was resolved, but that still left a bunch of people entering and leaving various rooms and making sure that their doors were closed shut.

I think things quieted down by 3:00 am, giving me a full three hours before the wakeup call.

Le sigh.