From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (from weis@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id QAA16542 for caml-redistribution@pauillac.inria.fr; Thu, 13 Apr 2000 16:38:36 +0200 (MET DST) Resent-Message-Id: <200004131438.QAA16542@pauillac.inria.fr> Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id OAA18906 for ; Thu, 13 Apr 2000 14:29:55 +0200 (MET DST) Received: from cs.clemson.edu (citron.cs.clemson.edu [130.127.48.6]) by nez-perce.inria.fr (8.8.7/8.8.7) with ESMTP id OAA05574; Thu, 13 Apr 2000 14:29:47 +0200 (MET DST) Received: from merlin.cs.clemson.edu (merlin [130.127.48.80]) by cs.clemson.edu (8.9.3/8.9.3) with ESMTP id IAA28781; Thu, 13 Apr 2000 08:28:28 -0400 (EDT) Received: (from steve@localhost) by merlin.cs.clemson.edu (8.9.3/8.9.3) id IAA26165; Thu, 13 Apr 2000 08:28:28 -0400 (EDT) From: Steve Stevenson MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Thu, 13 Apr 2000 08:28:27 -0400 (EDT) To: Jean-Christophe.Filliatre@lri.fr (Jean-Christophe Filliatre) Cc: "Dennis (Gang) Chen" , Pierre Weis , caml-list@inria.fr Subject: Re: When functional languages can be accepted by industry? In-Reply-To: <14581.28385.615880.93928@pc89.lri.fr> References: <38E7F364.5D24BB7C@motorola.com> <14572.49274.910966.673172@cylinder.csl.sri.com> <38ED71B6.30118608@motorola.com> <14574.1721.508470.790475@cylinder.csl.sri.com> <38F270CF.221F5BD0@motorola.com> <20000411195808.62154@pauillac.inria.fr> <38F3D520.9CD19485@motorola.com> <14581.28385.615880.93928@pc89.lri.fr> X-Mailer: VM 6.43 under 20.4 "Emerald" XEmacs Lucid Message-ID: <14581.47817.399464.722031@merlin.cs.clemson.edu> Resent-From: weis@pauillac.inria.fr Resent-Date: Thu, 13 Apr 2000 16:38:36 +0200 Resent-To: caml-redistribution@pauillac.inria.fr 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. \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