Quite a few people asked offline for a fortran version of the tests I indicated in the last post on this subject. So here is the basic code and its performance. What is interesting is that, for the same inputs as the C code, with no heroic loop unrolling/unwinding, the Fortran is about 3x faster than the C. Well, except for ifort. But we will get into that more later on.

MPI-HMMer, the implementation of Professor Eddy’s HMMer code built for MPI clusters, is now live on the net. www.mpihmmer.org will get you there, as will mpihmmer.org. There are some nice nuggets buried within … the papers, and a short discussion of MPI-HMMer-boost, which is a multi-layer parallel-accelerated implementation of HMMer. As usual, we are in search of meaningful and big benchmark tests to see what we can do (and if we can break it).

One of the things I and many other people worry about is how to retain data for long periods of time. This means that the data has to be accessible, readable, and convertable. This suggests that only open formats and file systems should ever be considered for data storage and retention. With this in mind, I read Robin Harris' Storagemojo column this morning. Yeah, I would say he nailed it.

I don’t have time right now to comment in depth, but read John West’s predictions, as well as most of the other editorials. Spot on in most cases. Mirrors things we have been saying and working on for a while. They are at http://hpcwire.com

I postulated for a while that this was the case. HPC technologies tend to evolve to a point of bandwidth (or latency) limitation. The broader IT market tends to follow. This is basically stating that as you build out resources, common designs will tend to oversubscribe critical information pathways. I had a conversation with a potential partner today where we were talking about HPC across multiple different subfields and we kept coming back to this.

This would be about 12.8k spam estimated for this month. Last month I had 10.9k. I heard somewhere that someone said spam is decreasing. My measurements (graphs over the last year) show quite the opposite. Our spam-box is on a per user basis. Each mail runs an annotation filter gauntlet. At the end of this gauntlet, it is classified as spam or not-spam. Not all mail reaches the gauntlet. Most of the “mail” gets rejected.

One of the comments to the previous post got me thinking about testing code on the same machine under various compilers. It is fairly well known that the Intel compilers emit code that doesn’t select reasonable operational paths on AMD processors, which usually results in identical binaries having vast performance difference on very similar platforms. This doesn’t make a great deal of sense from a technological point of view … you want to test for SSE* support, and not use processor strings to set set paths, specifically in that paths which may be disabled by processor string on your own CPUs, which is enabled/fixed in an upgrade of the microcode would be deselected … That is, such efforts are self defeating in the end.

Sorry about that, but it looks like some email domains are still using DULs that contain business DSL and business cable modem. If you are having trouble getting the emails, please use either a gmail.com, or similar (saner) email system. They generally do not have problems getting email to them. And they don’t use RBLs/DULs. Go figure. You may have seen me complain in the past about RBLs and their evil twin, DULs before.

I keep running into small (brick) walls with IE (mis)features. The latest one was when IE likes to send the whole file name … including path and drive … as the file upload name. The previous one was when IE refused to do the AJAXified file upload progress meter. Works on all the other browsers on all the platforms I have tried. Just not IE. I seem to remember something like this from some years ago with DragonFly’s predecessor.

like this … … Been hacking away at DragonFly. More soon.