Lahey Licensing of Fortran compiler for Linux - in detail ;-)

[Robert G. Brown]

On Tue, 21 Jan 2003, Bob Drzyzgula wrote:

> You very clearly make the case that a larger cluster can
> have greater value than a smaller cluster; you cite an
> example wherein a 48-node cluster won't solve your problem
> but a 96-node cluster will. Thus, code that will run on a
> larger cluster also has greater value than code that is
> limited to a smaller cluster. So why is not not fair to
> ask you to pay more for the right to generate code which
> has greater value?
...
> Clearly you don't have to see things that way, but in
> that event your only real recourse, I would think would
> be to find another compiler vendor that has pricing more
> to your liking.

I've stayed out of this so far because it is SO easy (and fun!) to start
a fortran rant out of a commercial fortran rant, but Bob's wisdom here
is so compelling that I cannot help but join in and reinforce it.

Long, long ago when first designing a PC/linux cluster, I looked over
the various compilers available, and if I recall correctly, Lahey even
then had a per-CPU license -- they charged on the basis of the number of
systems one planned to run a binary on.  Or, if you prefer, they charged
on the basis of their runtime library, which was licensed on a per-CPU
basis.

SO, we did what any sane consumer would do when presented with such
idiocy.  We supported PGI, we supported Absoft, we supported g77 (for
those users that HAD to have Fortran, which thank all the powers that be
I have not been since the mid-80's at this point:-).

At that time, we failed to see any compelling speed advantage for Lahey,
and the alternative vendors supported (and continues to support) cluster
computing for linux very effectively with high quality compilers.  Yes,
their licensing sucks.  So vote against it, with what counts!  Your
money!

With many of the alternatives, you can actually create a standalone
static linked binary that doesn't REQUIRE a dynamic runtime library to
be present on a node or target system.  Others (IIRC) license their
"compiler" (the code that parses your source, translates it, links it)
separately from their runtime library so that the latter can be freely
distributed but the former has to be on a specific system.  Look around!
Shop!  Cut a deal (a lot of compiler vendors would be happy to help you
out, I'm sure).  Choose the package that has the best cost-benefit to
you.

Be sure to take the long view in this, as well.  If you're porting an
old fortran application, perhaps there is a decent enough reason to use
fortran, although a LOT of old fortran applications one might wish to
port, if you look at them carefully, contain mediocre and outdated
algorithms and spaghetti snarl code (and maybe some nice, deep, bugs)
due to the generations of non-computer-scientist graduate students that
worked on them. A complete rewrite in a modern language, using a
high-quality open source library like the GSL in place of all the stolen
Numerical Recipes subroutines or ancient IBM numerical library routines
buried therein might save you more time than twice as many nodes PLUS
the time required to do the rewrite, and you might even be able to read
and maintain the resulting code when done. 

If you're developing a new application, then one REALLY has to ask
whether or not fortran is the right or best vehicle (and I'd knee-jerk
answer that even if Fortran is the only language you know, the answer is
STILL no).  gcc is free, ubiquitous, links to several variants of MPI
and PVM, is easy to program for both threaded operation and for raw
socketed communications, and makes high quality code in widespread use
in cluster applications.  We've recently had a lovely discussion on the
virtues of e.g. g++ and OO compilers.  Sure, using a variant of C or C++
(including one of the excellent commercial or semicommercial offerings,
e.g. PGI's or Intel's) might require learning, but there are lots of
resources to support the learning. People who know fortran and C and
actually PREFER fortran are (to my own direct experience, anyway) fairly
rare.  Must be a reason for this, one would think...;-)

So even though the human cost of porting to or writing in something
besides fortran may SEEM high, when one actually works out the benefits
in speed, quality of code, portability, and long-term maintainability
one may conclude that these benefits outweigh the cost.  Don't forget to
include the subtle benefits associated with open source compilers
compared to commercial (or semicommercial) ones as well -- gcc code is
more portable than code written for ANY commercial compiler, if only
because of the range of platforms and operating systems it runs more or
less identically upon.  OS compilers like gcc are arguably less likely
to contain bugs than many of the commercial offerings as well, as they
are used by a LOT of people -- at a guess by more people than use all
the commercial compilers for e.g. linux put together -- and hence get at
least the serious bugs hammered out of them quite rapidly.

Cost/benefit is all that matters.  If Lahey is too expensive (by
whatever scheme they charge, whatever deal you manage to cut) for the
benefit, then don't buy Lahey!  Tell them why you're not buying their
product when you turn them down!  Let the marketplace deal with them.
If gcc offers the best OVERALL cost/benefit (as it does for so many
folks and so much code) then by all means use gcc, even if it means that
you have to spend the first three or four weeks of your project learning
how.  You'll likely make it up in the second month -- once you know ANY
programming language, learning the second one isn't that difficult
(although it may take some time before you use it really well).

   rgb

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