Playing with Computers at Work (I/O vs Compute)

I used computer science at work and it was fun.

A coworker and I were talking just the other day about a situation where our code would need to enumerate every open file for a given process. We had a binary tree structure in memory that maintained the list for our process as well as the option of retrieving the information via '/proc'. Since we needed to touch every element in our tree in memory, that's easily identifiable as O(n), but what was unclear for our now group of four deliberators was whether the enumerating of the /proc/[pid]/fd file would be just as fast, faster, or slower. Ultimately, a couple of them settled on the fact that it would be the same speed since you still needed to enumerate every file descriptor, and it would be just as fast to make the system call to retrieve the proc info. I disagreed. My argument was that compute is always going to be faster than I/O, and even though it's a system call to a pseudo-filesystem, it makes sense to crawl the tree instead of getting it from proc. To prove my suspicion, I created the following experiment:

1. Run a program that opens and holds 2**x file descriptors.
2. Run a script to build a tree of 2**x levels in memory.
3. Using the same script, walk the tree using a depth first search. (Time this function)
4. Using the same script, attempt to read the list of FDs from /proc/[pid]/fd. (Time this function)
5. Compare the result of the function timers.

Results: At 10 levels, the tree enumeration took 0 milliseconds, while the I/O required about 55 milliseconds to complete. When I increased the size of the tree to 16 levels, the time required to walk the structure increased to around 25 milliseconds. Compute was faster.

Notes:
1. This is not bleeding edge accurate. The python package 'psutil' is essentially a piece of middleware that could influence the time it takes to return the list of file descriptors, but I think still accurately simulates what enumerating the proc file would require.
2. The accuracy of the time.time() value used for the experiment is two decimal places on my test machine.

You can find the experiment files HERE.

Prototyping with Leap Motion

If you have a Mac and plan on using Python with the Leap, let me save you some trouble and just tell you:

Install Homebrew straight away.

First, some back story. I wanted to start using Python first to prototype with the Leap controller and get a feel for how the frames and gestures are handled. Just setting up the environment turned out to be a headache due to how OS X handles its own Python installation. Several path and dependency problems ensued, but to save you the frustration yourself, install Homebrew if you haven't already and let it manage your packages instead of OS X.

After you have downloaded Homebrew and Python using the simple 'brew' cli commands, you're going to need to use 'install_name_tool' to modify the LeapPython.so library dependency locations. Follow this tutorial.

Once you're finished with those steps, import it into your Python project or Python path and you should be ready to start programming with the Leap Motion!

I spent far too much time trying to get these dependencies resolved on my mac tonight so I didn't get as far as I would have liked with the programming, but I did upload a very simple example that builds on the 'Hello World' tutorial posted by Leap. Will probably get more into it tomorrow when I have a little more time. See you then!