From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: weis Received: (from weis@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id PAA30899 for caml-redistribution@pauillac.inria.fr; Wed, 19 Apr 2000 15:05:15 +0200 (MET DST) Resent-Message-Id: <200004191305.PAA30899@pauillac.inria.fr> Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id AAA03311 for ; Tue, 18 Apr 2000 00:34:34 +0200 (MET DST) Received: from shell5.ba.best.com (shell5.ba.best.com [206.184.139.136]) by concorde.inria.fr (8.8.7/8.8.7) with ESMTP id AAA18692 for ; Tue, 18 Apr 2000 00:34:33 +0200 (MET DST) Received: from localhost (bpr@localhost) by shell5.ba.best.com (8.9.3/8.9.2/best.sh) with ESMTP id PAA00798; Mon, 17 Apr 2000 15:34:08 -0700 (PDT) Date: Mon, 17 Apr 2000 15:34:08 -0700 (PDT) From: Brian Rogoff To: John Max Skaller cc: jean-marc alliot , caml-list@inria.fr Subject: Re: When functional languages can be accepted by industry? In-Reply-To: <38FB4EA3.7AE9895@maxtal.com.au> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-From: weis@pauillac.inria.fr Resent-Date: Wed, 19 Apr 2000 15:05:15 +0200 Resent-To: caml-redistribution@pauillac.inria.fr On Tue, 18 Apr 2000, John Max Skaller wrote: > jean-marc alliot wrote: > > I don't think there are lot of things missing in the STANDARD library. I > > don't see why it is inconsistent. I don't see why documentation is > > incomplete. Things might be missing in the general library, yes. > > The order of arguments is perverse. Obvious functions are missing, > such as finding the number of elements in a map. The documentation > fails to tell how fast the functions are, and the specifications are > sometimes imprecise. The standard library is improving though, and additional libraries could certainly be written by users. My main concern here is that the best libraries make it into the standard distribution. In particular I prefer Pcre to the Str library, and would like to see it become the standard distribution. Note that I'm not using *distribution* and *library* interchangeably. In order to get an STL-like library in OCaml, I think we'd need some form of overloading. This comes up on this list every now and again, and it is clear that the Caml team is working on it, so we'll see. I particularly liked the last discussion here on type classes where Pierre Weis mentioned that he was interested in an overloading scheme which could unify the notations for array and string access; I'd be overjoyed if he is successful! Until some form of overloading is in OCaml though, I wouldn't look to the STL as a library to emulate, though I suppose its most important idea, the expression of algorithms in terms of iterators rather than specific data structures, doesn't depend on overloading. > > > Show me a functional programming language that is as fast > > > as C++ and I will give up C++. :-) > > > > > > CAML. Just try programming the fibonacci function in both languages... -:) > > :-) I believe that the Stalin compiler for Scheme, which is a whole program compiler (you give up separate compilation) has done better than C on some much more significant programs than fibonacci. I suspect that any compiler which abandons separate compilation and does aggressive whole program analysis may have problems with extremely large programs, but I don't have evidence to back this up. I presume that a similar compiler for an ML variant could be written. Given that the Caml team has limited resources, I'd rather they spend them elsewhere, as I am satisfied with the performance of OCaml for the problems I apply it to. I realize that others have different priorities. Another potential area for performance improvement would be the elimination of GC using the region system or something like it. There are probably other places in the implementation where choosing a different strategy could close the gap with C++ in speed, at the cost of code bloat. Also, the claim is made that C++ with templates generates code with run time performance comparable to hand coded C. Several studies that I've read call that into question; Richard O'Keefe's usenet comparison of a few years ago, the book by Kernighan and Pike "The Practice of Programming" and Anh Vo's papers on the Cdt library which compare it with the STL. > > CAML becomes slow when you use some of the nice functional features of the > > language. > > It's one heck of a lot slower using the imperative features, > and even slower using object oriented ones. Once again, if you're willing to subject your entire program to analysis then I bet the OO parts of OCaml could be made to run much faster. SmallEiffel seems to be running pretty fast these days. Don't get me wrong; I think separate compilation is important, and would prefer that the default compiler operate as it does now. I just think that some of the performance hits you see could be eliminated without changing the language but by changing the compiler. > > But if you write CAML as you write C code you won't lose much > > speed. Huh? What if you write crypto code, or a BDD library, or numerics, or a regex library, or ... > Sorry. You lose HEAPS. Even 10% is significant, CAML can > be over a decimal order of magnitude slower. C++ generics are > generally much faster (being automatically specialised -- which > also causes code bloat :-( I don't think you see an order of magnitude for the most part though... > No dispute. [I'm an 'old' game programmer too]. I'd write > the main game play engine of a strategy game in ocaml in preference > to C/C++, but there's no doubt I do the graphics in C/C++. > There, every ounce of performance is absolutely critical. If every ounce of performance is truly "absolutely critical", then go to assembler. Even C won't compete :-) Also, for numerics, Fortran compilers are still probably better than C, though I don't know how much longer that will hold true. > >Templates are, from a theoritical point of view, a > > matter of laugh, > > No. They're not perfect. They generate very fast code. > On the contrary, it is the boxed values of functional languages > which are the laugh: they kill performance. See above on templates. I agree that boxed values suck for high performance code. > What object theory? There isn't one. Object orientation > is a mess. Eiffel is every bit as bad as C++ here: the fact is that > C++ trades off beauty and correctness for speed and compatibility. > > It is faster than C though, and much easier to use. Faster than C? I doubt that. Where is your evidence? > Remember -- I _like_ Ocaml. I do _not_ like C++. > I did my best to make it better, with little result. > But the fact remains, it is the language of choice for most applications > simply because it provides reasonable power, reasonable safety, > and there is an assurance that it can be as fast as you can bother > to take care to make it. I'd say simply because it is perceived as a better C, and C was already the language of choice for most applications. OCaml is not riding anyone's coattails, so it really has to be better at something, or, more likely, we have to create a niche in which OCaml is the best language (read "The 22 Immutable Laws of Marketing ;-). I think that writing compilers and associated tools is one such niche, since it plays off of MLs strengths. -- Brian