« Go to hell, Costas | Main | Kenau Reeves can't act »

The only question that remains is "which of them do I fire?"

I went to Sandia with Andy this week.

It was a neat trip; I've been to Albequrque (sp?) before, but not to Sandia itself. I didn't realize that it was physically located on an Air Force Base (Kirkland AFB? Don't remember the name offhand).

Next time, however, I'll be flying in and out of Louisville, not Indianapolis. This time, I picked up Lummy in Bloomies and then drove to Indianapolis to fly out. We came home on Monday night, and after driving Lummy back to Bloomies, I didn't get back to Louisville until about 3:30am on Tuesday morning. Never again.

The moon and Mars were really bright the whole way home, though.

I also found out that you will get stuck behind someone slow on IN-46, regardless of the time of day.

The trip itself was cool. We went "behind the fence" at Sandia, into Classified County. We had to be escorted and within sight of Rich, our contact, the entire time. When we went into his office building, we had to sign in, and the secretaries put big magnetic "Caution -- Uncleared personnel in the area!" stickers on all the doors.

We were down there to see Brian and kick off our LAM/MPI collaboration with those folks. They actually can only generally tell us what they are using LAM for -- "simulating the nuclear stockpile". Any specifics beyond that are apparently on a I-could-tell-you, but-then-I'd-have-to-kill-you basis. Which is ok; I think I'm comfortable not knowing. :-)

Brian and I both gave talks; I gave a general "LAM is great" talk, and Brian gave a talk about specifically what we are doing with Sandia (we were up until 1-2am working on his slides, and then Brian came back to our hotel at 6:30am to practice his talk). Both talks went well. We met with Ron and the CPLANT folks as well; we'll probably be at least coordinating with those folks during this work, which is good.

In general, the trip was a success, and we have a better understanding of what they are trying to do, and what they would like us to do with LAM/MPI. This should be a very interesting project.

I notice the news reports that the European Union has blocked the GE / Honeywell merger. This was pretty much expected, I think --
there has been rumblings about this before. But it's still amazing. I am not familiar with the details, but I can't imagine that the US government is going to be happy about this (that's how much clout GE has). Even President Bush has apparently made some comments about how he is not pleased about this.


Tracy and I went to Gina and Dan's 4th of July party last night. There were lots of GE folks there. We stayed until after midnight sometime; it was quite fun.

My conversation with Rich about shared library modules for LAM continues. He brings up good points about the efficiency of shared libraries and how it's not the fault of the concept of shared libraries that, etc. And he's right. There's lots of very good technical reasons that we should use shared libraries for the module design in LAM.

But we won't.

At least, not right now. Right now, the state of technology for shared libraries (IMHO) is too non-uniform. Probably the number one reason why is that it's a nightmare to create shared libraries on different platforms. Even GNU libtool isn't a complete solution (it doesn't work on all platforms). Hence, LAM/MPI is not in a position to require shared libraries. Sure, it can be an option, but not a requirement.
This reason is closely followed by the fact that it would be a somewhat large delta to change to explicitly use dynamic libraries (properly) with dlopen() and friends. Is this rocket science? No. It's not even particularly hard. But it's a nonzero change, and, at the moment, unnecessary. So good engineering dictates that we don't do it now. Get it working (with static linking), and then possibly move to shared library modules. With good modular design, the change is the same now as it would be to do it in the future, so not implementing it now reduces the number of variables that we have to debug.

One point that came out that I assumed was common knowledge was that LAM can be compiled as shared libraries (using GNU libtool). Hence, all this module stuff can end up in liblam.so (vs. liblam.a). This was actually one of Rich's points -- that we shouldn't close the door on shared libraries completely, because of the various performance benefits, particularly for large SMP boxen.

My only point is that I don't want each of these modules to be their own shared library. Whether or not liblam is a shared or static library, I don't care -- that's a user choice -- just as long as it's not a requirement. More to the point, if the compiler/linker/libtool can give me shared libraries for free, great. But I don't want to explicitly program for shared libraries (dlopen() and friends) for the reasons that I stated above and in prior journal entries. At least not yet.

And, for the record -- I was right: Darrell did feel the urge to say the same things that Rich did. :-)

On another LAM note, someone found a minor bug in LAM 6.5.2 such that compiling programs with MPI I/O won't work. Arrghh... This may trigger the release of LAM 6.5.3. But we're currently in the process of figuring out what the license for LAM/MPI will be down at IU. I'm trying to push BSD, but other forces are at work (including IU's lawyers). We'll see how this shakes out...

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.)


This page contains a single entry from the blog posted on July 4, 2001 8:39 AM.

The previous post in this blog was Go to hell, Costas.

The next post in this blog is Kenau Reeves can't act.

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

Powered by
Movable Type 3.34