Thursday, March 29, 2012

Netra T1 105

I accidentally became the owner of a new old Sun Netra T1 model 105 yesterday.  I had asked our super-helpful systems administrator if he had any old 1U servers to loan me as a prop for a tabletop demo I was to give, and it just so happened that this T1 was left behind by the former computing services manager.

Sun Netra T1 105
I must say, it's an odd little machine.  I expected it to be like my old Sun Fire v100, which is analogous to a Sun Blade 150 wrapped into a cheap 1U.  However, these T1s are closer to Ultra 10s wrapped into a 1U with the nice addition of hot-swappable SCSI in the front and a Fast40 HD68 SCSI port in the back.  This particular one was fully loaded, too:

Netra t1 (UltraSPARC-IIi 440MHz), No Keyboard
OpenBoot 3.10.25 ME, 1024 MB memory installed, Serial #        .
Ethernet address 8:0:           , Host ID: 80      .

Playing with an old computer again feels a little strange, seeing as how I haven't gotten a new toy like this in almost a year.  The last computer I added to my collection was my RS/6000 43p-150 which I bought back in May 2011, and I haven't fired it up since June.

Anyway, I wound up not even needing this computer for my demo, but I'm stuck with it now so I'm sure I can have fun with it.  All it needs is a name and an OS.

More photos can be found in my Picasa album:
Sun Netra T1

Monday, March 26, 2012

Switching from Perl to Python: Speed

The job listings in scientific computing these days seem to show a mild preference for applicants with backgrounds in Python over Perl. It has high-profile (or just highly visible?) packages like NumPy and Python's MPI bindings for scientific computing, and some molecular dynamics packages (e.g., LAMMPS) include analysis routines written in Python. Although I've invested a few years into Perl, I've decided to not pigeonhole myself and start picking up Python. After all, Perl is unintelligible after it's been written, and it's sometimes frustrating to deal with its odd quirks.

To this end, I reimplemented one of my most-used Perl analysis routines in Python. Here is my Perl version, written back in 2009:

And here is the Python version I cooked up today:

In the Python version, there are several ways to tear through a file and I tried all three. Method #1 is closest to the Perl functionality, where I can specify multiple input files on the command line and have all of them parsed sequentially. Method #2 is the method that the Python documentation seems to advocate the most. Method #3 loads the whole file contents into memory and works from there.

Unfortunately, in all three cases, Python seems to be slower than Perl. Average execution times for a typical input file are:

Maybe there's something I'm missing in the Python version, but the Perl version isn't exactly a shining example of simplicity in itself. What gives here? For a language that's being venerated in the scientific computing world, in the case of basic text parsing of large files, it isn't shining. At best, it's almost 50% slower than Perl.