Slash Boxes
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

pjf (2464)

  (email not shown publicly)
AOL IM: miyuki3k (Add Buddy, Send Message)

I run Perl Training Australia [].

I help with Melbourne Perl Mongers.

I spend an awful lot of time talking about Perl, and have had my picture in the Australian newspapers with a camel. That's rather scary.

Journal of pjf (2464)

Thursday July 01, 2004
04:47 AM

On the first day of financial year, my server gave to me....

[ #19619 ]

Financial Year
2003-04 finished very quietly. Did a bunch of paperwork, fielded a few questions from clients. Nobody called with $20,000 they needed to lose urgently. Quite dissapointing, really.

It appears that our main server rebooted this morning, at about 6am, for no apparent reason. It then proceeded to do so around noon, and later on at about 3pm. It reported seeing some strange activity on the serial line during this period, and the serial line is hooked up to the UPS, so we suspect it's having problems. Always bad when the piece of equipment that's supposed to keep your power running smoothly is doing the opposite, but this wouldn't be the first time I've seen a UPS ruin an otherwise good mains supply.

Had a number of telephone conversations with jarich, as she had access to the console, the hardare, and the suspected UPS. A couple of reboots later and the machine was running straight from the mains. During one reboot the IDE controller decided to flake out entirely and lose interrupts. That's not good, but the machine correctly restarted itself and everything come up fine.

I'd never thought I'd be grumpy about losing months and months of uptime, but I am.

Painting Programs Red
When I wasn't fretting about sick machines, I was working on a particularly knotty problem for one of my clients. One of the difficulties with it was taxonomy -- each of the three pieces of data that the algorithm processed didn't have good names, and they all used the word NULL to mean different things.

After spending more time than I would have liked to mentally map the problem, I finally got a working solution involving turning the bits of data into bit-strings, and performing operations on them. This is about twice as fast as the previous system which used regular expressions. The major slow-down at the moment appears to be that the bit-strings are being stored in a hash, and the cost of the hash-lookup is significantly more than the cost of the operation on the bit-string. Luckily, the whole thing can be converted very easily to have everything indexed into arrays, which should give us another big speed-boost.

If I had more time, I would broach the idea of putting the whole knot of code into XS. This really is a problem which would fly in C. We're building up some bit-strings (each only a single byte long), and then munging them together with a static table to produce some boolean output. We can pack everything into some very short arrays, and as we're on a 32-bit architecture we should be able to munge four maps at a time. I believe we can even construct a three-dimensional karnaugh map of the main problem, optimise it, and end up with some very fast code indeed. It'll scream along, I tell you.

Unfortunately my four-day contract finishes tomorrow. That doesn't leave enough time to comfortably test and review the code once it's finished screaming.

P5P is having some very interesting discussions right now on truncated sorts -- when you wish to sort a list, but only want back the first M of N elements. Some people seem to think that I'm really strange for staying up late chatting about the merits of different sorts and how they can be optimised when you only want a subset of the original.

It's a shame that I'm no longer teaching computer science at a University, this is the sort of problem that would make a perfect second-year assignment.

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
More | Login | Reply
Loading... please wait.