[Beowulf] MS HPC... Oh dear...

[Robert G. Brown]

On Mon, 12 Jun 2006, Joe Landman wrote:

>
>
> Ashley Pittman wrote:
>> On Mon, 2006-06-12 at 00:02 -0400, Joe Landman wrote:
>>
>>> What Microsoft will do is to take away as much of this as they can.  I
>>> haven't seen it yet, but I believe they will offer MPICH as a DLL, so if
>>> PathScale wants to work along side some other device, you can select
>>> this at runtime, and just have it work.  This is a nice idea.
>>
>> Perhaps I've missed something here, what do windows DLLs provide that a
>> linux .so doesn't?
>
> Nothing.  Unfortunately most folks use statically linked binaries for
> MPI, so .so's are not a factor.  I could be wrong, and maybe there is a
> way to get statically linked binaries to respect LD_PRELOAD or
> LD_LIBRARY_PATH, but I am not aware of it.

There are two important differences that you miss, Joe.  The first is
that "dynamic link library" is a much cooler sounding name than a
"shared object" library.  "DLL" sort of rolls off of the tongue where
"SO" sounds like it wants to be followed by "B".

The second is that historically DLLs have been one of the best ways to
break a WinXX system ever invented.  Every g*dd**n time one installs a
new piece of software on a WinXX system that needs to "update" a
critical DLL so that >>it<< is happy, you have a significant probability
of breaking at least one piece of software that used the version you
replaced, especially if IT loaded a different version of the SAME DLL
when it was originally loaded.

Installshield ain't yum, and no software vendor is willing to wait for
MS to "fix" things in their distribution DLLs so that their own package
works correctly with it, so they each fix what they need to fix and
redistribute.

> More to the point, this dynamic binding allows you to write to the API,
> present a consistent ABI, and handle the hardware details elsewhere in a
> driver which can be linked in by the .so/.dll/.eieio method at runtime.
> Which is about the complexity that most end users/customers want.

In the best of all universes, this is true.  But in the best of all
universes, I'd have naked slave girls fanning me and periodically
stuffing grapes in my mouth while I type, right?

In the real world, this is true if a) There >>is<< a well defined,
carefully versioned API; b) there is a single point of support for the
DLL (at least for DLLs that have to integrate tightly with the also
carefully versioned operating system); c) the API/ABI is written in such
a way that it remains (mostly) backwards compatible; c) software that
uses the DLL is version aware; d) the software installation process for
the OS is version aware.

Now, let's see -- RPM-based linux, supported by e.g. yum, does this very
nicely.  ALL software is dependency aware and is typically built per
distro per major revision thereof.  People who refuse to use rpm --force
ever, and who only use rpm-based software, and who never install their
own "private" copy of a shared library but instead only use the one that
comes "with" the distro and built to the same standards and dependency
rules find that installing package X almost never breaks package Y.

Debian also plays nicely here -- dependency awareness, build
consistency, strong resistance to multiple libraries satisfying any
given shared dependency and dependency loops and so on.

WinDoze?  Don't make me laugh.  Anybody in the room who hasn't broken at
least one WinXX app by installing another (without the slightest warning
or complaint from the OS or install process) please raise their hand.
Hmmm, not a lot of hands out there....;-)

So FUNCTIONALLY sure, DLLs and SO are the same thing.  Practically
speaking, Wine and/or Cedega typically install applications (and all
their application-specific DLLs) in their own independent fake trees
just to avoid this very problem, because it is difficult enough to debug
a WinXX emulator as it is without having to also debug dueling DLLs.

     rgb

>
>>
>> Ashley,
>
>

-- 
Robert G. Brown	                       http://www.phy.duke.edu/~rgb/
Duke University Dept. of Physics, Box 90305
Durham, N.C. 27708-0305
Phone: 1-919-660-2567  Fax: 919-660-2525     email:rgb at phy.duke.edu