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 TAA01885 for caml-redist; Fri, 21 Apr 2000 19:20:30 +0200 (MET DST) 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 SAA23492 for ; Thu, 20 Apr 2000 18:40:45 +0200 (MET DST) Received: from miss.wu-wien.ac.at (miss.wu-wien.ac.at [137.208.107.17]) by nez-perce.inria.fr (8.8.7/8.8.7) with ESMTP id SAA24810 for ; Thu, 20 Apr 2000 18:40:45 +0200 (MET DST) Received: (from mottl@localhost) by miss.wu-wien.ac.at (8.9.0/8.9.0) id SAA05607; Thu, 20 Apr 2000 18:40:38 +0200 (MET DST) From: Markus Mottl Message-Id: <200004201640.SAA05607@miss.wu-wien.ac.at> Subject: Re: When functional languages can be accepted by industry? To: bpr@best.com (Brian Rogoff) Date: Thu, 20 Apr 2000 18:40:38 +0200 (MET DST) Cc: caml-list@inria.fr (OCAML) In-Reply-To: from "Brian Rogoff" at Apr 17, 2000 03:34:08 PM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: weis > 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! Over the time I have adapted to the "lack" of overloading and do not find it so missing for arithmetic operations. However, there is one application domain where I really feel "bitten" by not being allowed to overload operators: monads. I would like to use them more often for structuring code and trying out some new styles of functional programming, but it's a pain using different kinds of monads at the same time: you'd always have to specify module names for "bind"-operators, which puts the otherwise very convenient infix operators quite out of the question. But I wonder whether this specific application justifies a complication of the type system... > 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. What concerns me, I also consider the performance of OCaml programs fair enough for nearly all purposes. Since interfacing to C-code is so easy, one can always eliminate bottlenecks on a lower level. > 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. I do not think that C++ is competing with OCaml in the same niche so there is probably no point in addressing differences here. In fact, although it was surely not designed for this purpose, I believe that OCaml could be a serious threat to some scripting languages: partly due to its high performance, partly, because it is much saner = easier to maintain, and highly portable! The Unix-library is very complete and would also play an important role here. > 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. Programs on modern architectures depend so heavily on cache behaviour that performance claims for code-bloating techniques seem to be rather suspicious. I'd also like to see substantial benchmarks that prove the merits... > > 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... Considering the improvements on the hardware side in terms of processor performance, 10% seems very insignificant to me (a few months of hardware development at most), especially if you take into account that for many non-numeric applications the limiting factor is most often I/O-bandwidth. Correctness, maintainability and portability are (well, should be) the primary concerns in a world that changes fast - not "fast" programs... If your employer says that you should switch to lower-level, unsafe programming languages to get 10% more performance, tell him that he should rather buy new hardware (if you dare to! ;-) If he doesn't want, present him an estimate of the costs of more errors... Best regards, Markus Mottl -- Markus Mottl, mottl@miss.wu-wien.ac.at, http://miss.wu-wien.ac.at/~mottl