« This office isn't big enough for two weird guys! | Main | Everything's kinda backed up in le-kitchen, Dave »

Dave tells me that there's lots of company policies that apply just to me

Scenes from the upcoming blockbuster movie, "Pushing Bugs", a gripping story of the stress and tension in the lives of Bug Traffic Controllers trying to provide safe passage of insects across human automobile highways:

BTC: "Junebug 357, you are clear to cross I-265 southbound lanes at mile marker 123.niner. Proceed immediately to cross at minimum safe altitude of niner feet to avoid approaching oncoming small Japanese vehicle, over."
JB357: "Roger."
...seconds later...
BTC: "JUNEBUG 357! Climb immediately to altitude of 25 feet; unscheduled incoming tractor trailer approaching!!"
JB357: "I see him! Climb...<splat>"
BTC: "Junebug 357! Are you there? Junebug 357! Report!!"


I've gotten oodles of hits from Code Red on my web server -- 141 of the CRI variety, and 669 of the CRII-and-beyond variety. I think the funniest two CRII hits that I've gotten are from:

 msgr-cs30.msgr.hotmail.com msgr-cs31.msgr.hotmail.com 

I kid you not; this is straight from my web logs. I had read articles that MS had some of their hotmail servers infected, but to see proof of it right in my own web logs is just too darn funny. :-)


Saw Gone in 60 Seconds tonight on DVD. I thoroughly enjoyed it; it was much better than I thought it would be. I wouldn't call it the greatest movie of all time, but I would say that it is definitely worth seeing. Good action, good humor, good psychos, and good character development. I've always like Nicholas Cage. I was surprised to see Angelina Joline in it, too (took me a little while to recognize her -- her hair is bleached, much longer than Tomb Raider, and styled entirely differently, sorta dreadlocky).

I give it 30 minutes.


It amazes me how other kinds of scientists and engineers use clearly sub-optimal methods when it comes to computers. This is sounds like an unjust elitist view, but hear me out anyway.

In looking for a good demo application for my dissertation code, I heard about some DNA sequencing code that uses MPI in a manager/worker model. Sounds about perfect. I download the latest copy and had a look at it. One thing that struck me right away (and this is definitely elitist) is that you have to manually edit the Makefile. Yuk.

So there's no configure script; I can deal with that. They have "MPI defaults" for you in the Makefile, but they are a) based on MPICH (that's like rubbing a cat the wrong way :-), and b) using the most difficult method rather than just the mpicc wrapper scripts that MPICH (and LAM!) provides.

Sidenote: I've seen lots of MPI projects that do this... why do they do that?

And they make other MPICH assumptions -- such as assuming that MPI will give the same command line arguments to all executables, even if it's an MPMD model. That one threw me for a while -- I wasn't expecting that (nor did I know that MPICH did that).

The overall design of the program itself is actually pretty clever, yet complicated -- it seems to be clearly written by some scientists/engineers who want to "get it working", and you gotta respect that. But it shows some naivete in its overcomplication (IMHO, mind you) -- I think that the overall model could be less complex. For example, there's a fairly elaborate scheme in place to get the data back and forth from the manager to the workers. But it involves four different binaries (three required binaries, and an extra optional "monitor" process).

Even though the overall program seems to work ok, it's not optimal. Yes, you get speedup running on multiple processors, but the speedup is less than linear. And it seems fairly complicated for a manager/worker setup. There's a separate "foreman" executable, for example, that relays work between the manager and the workers. More than that, though, the foreman spins on non-blocking probes. This eats up CPU cycles like nobody's business.

All that being said, this is actually quite advanced for non computer scientists (and for many computer scientists, as well!). It's probably on the forefront of its field in DNA sequencing codes. Note, however, that I make these observations about many computing projects that I have seen -- not just the one DNA code that I cited above; the DNA code is just the most recent example.

So what does this tell us? I guess that that's part of our jobs as computer scientists -- to make tools that other scientists/engineers can use to build complex systems. Tools that suck less than most current tools. Indeed, Lummy had a good observation recently:

One interesting insight I gathered while at the Livermore meeting last month was along these lines. There is a real reluctance in the scientific computing community to use C++ -- especially advanced C++ -- in scientific codes. The reason is not that the people are dim or lazy. Rather, the intellectual capacity taken up by (advanced) C++ leaves room for very little else. These guys also have to be experts in numerical analysis and their application area. Also being an expert in C++ is not really feasible.

The tools that are available are generally powerful, but most of them suck for various reasons (a typical example that many readers can probably associate with is how MS Windows periodically "freezes", or dies the Blue Screen of Death). Indeed, using the current generation of tools to their fullest power requires significant expenditures in terms of time and learning -- something that most people just don't have the resources to spend. How to reconcile the use of building complex systems without either rolling individual solutions or spending huge amounts of time learning complex tools?

An idea that I have been telling fellow scientists and engineers about for quite some time is what I euphamistically call "C+". It's not C, and it's not C++ -- it's somewhere in the middle.

Most scientists/engineers know C but are scared of C++ for exactly the reasons that Lummy cited above. I'm a big fan of essentially writing C code, but using a small number of the advanced tools in C++ such as: std::string, passing by reference, the STL (maps, vectors, and lists), and basic object usage (to get guaranteed initialization/destruction). You don't need to go into full-blown object-oriented design or use all the whacky, bleeding edge features of C++; the simple tools that I listed above are extremely powerful and provide oodles more functionality than you get in vanilla C. They actually save time when programming, and allow for elegant solutions to programming problems. The learning curve on these tools is actually quite low. These are good examples of software that suck a good deal less than most other tools.

As many have noted, the current state of technology in software is really in its infancy. Consider what used to run your computer 5 and 10 years ago. It was vastly different -- there are a few essential concepts that have remained constant, but software itself has changed dramatically over the last 10 years. What will it do in the next 10, 20, 50 years?

Indeed, computers are made for the kind of rote, menial tasks that software tools are supposed to provide for us. So why do I have to spend so much time writing configure.ac for my portable unix program? Why do I have to spend so much time making an iron-clad robust build system for my portable software? Why do I have to spend so much time configuring my computer before it's safe to be put on a network? All of these kinds of things should be able to be automated for me -- it's the software that needs to be able to handle these things.

So that's what I see my job as: to make software that sucks less. It's challenging and exciting -- to be able to give someone power to do things that they have never before been able to do. To actually be able to increase productivity of others just by providing competent tools; that's neat stuff.

----

Ok, I'm a geek. But I've always admitted it. Hell, I love being a geek. But even more than that -- I don't just thoroughly enjoy it being a geek, I revel in it. :-)

Post a comment

(If you haven't left a comment here before, you may need to be approved by the site owner before your comment will appear. Until then, it won't appear on the entry. Thanks for waiting.)

About

This page contains a single entry from the blog posted on August 12, 2001 11:06 AM.

The previous post in this blog was This office isn't big enough for two weird guys!.

The next post in this blog is Everything's kinda backed up in le-kitchen, Dave.

Many more can be found on the main index page or by looking through the archives.

Powered by
Movable Type 3.34