Re: When functional languages can be accepted by industry?

From: Steve Stevenson (steve@cs.clemson.edu)
Date: Thu Apr 13 2000 - 14:28:27 MET DST

  • Next message: Dennis (Gang) Chen: "winocaml available"

    I may have missed some of the below ideas in the discussion.

    Let me pass along the notes from a discussion that I had with Jim
    McGraw who was one of the true guiding lights of the Sisal effort. You
    can huff and puff at this, but in my experience (11 years at the old
    Bell Labs), these ideas ring true. FYI, ASCI is the Accelerated
    Strategic Computing Intitiative (simulation support for the US nuclear
    weapons program.)

    Best regards,

    steve
    -----
    Steve (really "D. E.") Stevenson Assoc Prof
    Department of Computer Science, Clemson, (864)656-5880.mabell
    Support V&V mailing list: ivandv@cs.clemson.edu

    ============================================================

    The following information is drawn from an exchange with Jim McGraw of
    LLNL on the whys and wherefores of the failure of SISAL to win the
    hearts and minds of the programmerate. This is a LaTeX file. The
    paragraphs in \em are my comments --- steve
          
    \begin{outline}
    \item No Commerical Support*\footnote{
    Items marked with an asterisk (*) identified by Jim as key
          issues. Italicized text is my response to his comments.
    }%
          Code developers want assurance that their codes can be moved to
          different platforms and the language will be supported there.
          This requires vendor concurance and support that Sisal never
          achieved. This is the standard chicken and egg problem, because
          vendors want to see apps users demanding a product before they
          support it. This is a very real and very difficult hurdle for
          anyone -- nothing specific to Sisal or functional languages.

          {\em Agreed. You might add academic support. In fact, I'm not
          sure that isn't first sometimes. The grads coming out are not
          going to change languages and systems unless they have to.}

    \item We want Fortran*: Until the ASCI demands came along, there was a
          clear preferance to evolving current codes, which were all
          written in Fortran. The argument was that we had too much
          invested to rewrite codes and to really get the benefit of
          Sisal, you need to rewrite and rethink your code design.
          Interestingly, the new breed of programmers and the ASCI demands
          have overcome this argument. Programmers are using many
          variants of Fortran and C. C++ is coming into vogue and also
          many different front-end control languages, like Eiffel and
          JAVA. Moreover, many first wanted MPI as the model for
          parallelism, but now they are being forced to use threads and
          OpenMP, to get concurrency within these nodes. They chose MPI,
          not because it was good, but because it was perceived as the
          ONLY option that would give them long term portability (even
          though to this day, the performance cost of such portability is
          still in serious doubt). So what they really want is minimal
          change.

          {\em This last sentence would seem to capture it all. We see it
          when we try to get the students to add a new language.}

    \item Unstable compilers for Sisal*: This is a very legitimate
          argument.
       
    \item The programming model did have some serious weaknesses.
          Foremost was I/O. The whole concept of streams was included to
          have some way of doing I/O, but it was an awkward hack at best.

          {\em I must admit, I find the current spate of implementations
          of streams unintuitive. However, CAML and OCAML seem a bit
          easier to use. Much of this is experience, though, isn't it?
          Streams are really natural for some problems.}

          We ended up making more progress by permitting calls from Sisal
          to C, where we did I/O. But that approach has some severe
          technical difficulties that programmers must use with great
          care. Another example of model weaknesses is parallel
          operations like bucket-sort that we could not easily express
          with their natural concurrency. There were a whole set of
          issues about what we should or should not allow in the language,
          relative to things that were determinant.

          {\em It seems to me that this problem of how to write
          parallelism is ubiquitous and I'm not sure I understand what the
          real problem is from either a cognitive or conceptual
          viewpoint. I did a lot of discrete event simulation work at BTL
          and I find that experience the key to understanding parallelism
          but I don't see the linguistic solution either. }

    \item *Programmers did not want to turn control of key things over to a
          compiler, because they did not trust the compiler to do the
          right thing. One good example is data layout. For parallel
          machines with distributed memories, we did not have a good
          solution, although our most likely idea was to use some form of
          pragma from users. They did not like The idea that the compiler
          would decide where in memory things would go or when various
          thing would be scheduled for execution. Interestingly, they are
          now discovering that for these complex cache-based machines,
          they must have the compiler do more, or the performance of the
          codes drops through the floor even on single processors. The
          best performance is achieved by setting up data layout on a node
          based on the exact variable reference patterns across different
          (unnested) loops.

          {\em I wrote a preprocessor for a biophysics group. It took
          chemical stoichiometry notation and developed the functions. I
          realized later that they were using it to generate the code and
          then handchecking the Fortran. Is the problem that we're too
          opaque to the scientists? A more collaborative effort?}

    \item I think there is no doubt that the functional programming style
          caused concern among possible programmers. They are accustomed
          to thinking sequentially and this change was awkward. Even now,
          many folks still want to stick to SPMD mode, where everything
          has a vector view. for some kinds of code, this works great.
          However, when we get to codes that need more concurrency and
          require effective load-balancing, the solutions will be very
          hard. Right now, programmers want to manage their concurency in
          understandable ways. Sisal did not permit much of this type of
          control.

          {\em My academic colleagues don't seem to be able to make the
          switch to functional, either.}

    \item Determinant behavior. The language definition for Sisal
          required determinacy. However, to insure this property, we had
          to make sure we had the exact replicatable order of execution
          followed. This was a VERY high cost in terms of performance.
          Morever, when we went to compare performance with other codes
          that did not guarantee determinacy, we would lose badly. So our
          implementations had an option to ignore the determinacy
          constraint. When we did that, we got better performance than
          our competition, but we had lost a key feature, because now we
          could get race conditions.

          {\em How much of this should be fodder for academic
          research. Good old computability theory?}

    \item *And the ever present: Politics. <Understand the points>
       
    \item I am not sure this is all of the reasons for our problems, but
          it is certainly the overwhelming majority of them. It's
          impossible for me to rank their importance, because no one else
          ever tried.

    \item The totality of the issues just weighed us down too much to
          change things. The key point to me is that many of these issues
          are not unique to Sisal. ASCI and even the President's PITAC
          report say that "software" is the issue and that we still need
          to consider new programming models and styles.
                  
    \item The roots of MPI have been around for a lot longer than that.
          This is any area that moves at a snail's pace and yet users
          demand robust and reliable tools and upward compatibility from
          their current codes. I am not sure there is any technically
          good solution possible.

    \item {\em You may be exactly correct. The problem is not a technical
          one. The desire to change languages seems worse now than ever
          before. Maybe that's how one get ones project out of trouble:
          "We're in the wrong language, let's rewrite."}
    \end{outline}
    \end{document}

    -- 
    Best regards,
    

    steve ----- Steve (really "D. E.") Stevenson Assoc Prof Department of Computer Science, Clemson, (864)656-5880.mabell Support V&V mailing list: ivandv@cs.clemson.edu



    This archive was generated by hypermail 2b29 : Thu Apr 13 2000 - 16:45:56 MET DST