From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (from majordomo@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id XAA14279; Thu, 17 Oct 2002 23:14:20 +0200 (MET DST) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f 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 XAA14422 for ; Thu, 17 Oct 2002 23:14:18 +0200 (MET DST) X-SPAM-Warning: Sending machine is listed in blackholes.five-ten-sg.com Received: from epexch01.qlogic.org ([63.170.40.3]) by nez-perce.inria.fr (8.11.1/8.11.1) with ESMTP id g9HLEHD20747 for ; Thu, 17 Oct 2002 23:14:17 +0200 (MET DST) Received: from epmailtmp.qlogic.org ([10.20.33.254]) by epexch01.qlogic.org with Microsoft SMTPSVC(5.0.2195.4905); Thu, 17 Oct 2002 16:13:11 -0500 Received: from [10.20.33.146] ([10.20.33.146]) by epmailtmp.qlogic.org with Microsoft SMTPSVC(5.0.2195.4905); Thu, 17 Oct 2002 16:14:16 -0500 Date: Thu, 17 Oct 2002 16:19:51 -0500 (CDT) From: Brian Hurt X-X-Sender: Reply-To: Brian Hurt To: Chris Hecker cc: Ocaml Mailing List Subject: Re: [Caml-list] Re: Camlp4 optimizations (was: productivity improvement) In-Reply-To: <4.3.2.7.2.20021017130323.02dbb068@mail.d6.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-OriginalArrivalTime: 17 Oct 2002 21:14:16.0386 (UTC) FILETIME=[2654EA20:01C27622] Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk On Thu, 17 Oct 2002, Chris Hecker wrote: > > >how important is operator overloading? > > I'm amazed that people who are interested in high level languages are > asking these questions (not to attack you personally, just the overall > attitude)! Developers won't learn a new language with a reputation of inefficiency (by which they mean how fast the program will run, not how easy is it to develop in). And I agree with you that this is wrong, but I admit- one of the reasons I was attracted to Ocaml instead of other functional programming languages was the performance. I now like it enough that I'll stick with it despite inefficiencies. Wander up to your local java bigot and mention "I hear Java is slow" and watch him jump down your throat. And this does not necessarily mean that the performance isn't illusory. Notice that I used C++ as my "bad example", a language that has (IMHO an unjustified) reputation for performance. Yes, this is marketing and not logical- so what? I will say- there is a way to get both the ease of development of operator overloading *and* the performance of BLAS. Make matricies first class types known to the compiler, like ints, floats, and strings (vectors can be considered m-by-1 matricies). Now the compiler knows what substitutions are legal or not- it can easily replace a = b + c + d; with a = b; a += c; a += d;, or even a = d; a += c; a += b; if it feels like it. The compiler would then produce code which would call out to a library which would have to be linked in (rather like you have to add -lm to your command line to use sin() in C). So programs which don't use matricies don't have to suffer the "code bloat" associated with them. The only problem with adding matricies to the language is where do you stop? Matricies and vectors (as mx1 matricies), OK. Complexs? Matricies (and vectors) of complexes? Quaternions? Directed rounding? Single and double precision FP? Quad precision FP? Matricies and vectors of all of the above? Arbitrary precision FP (with matricies)? Interval arithmetic (with matricies)? Etc. All of these and more have been proposed (for other languages). Take some time to explore: http://www.cs.berkeley.edu/~wkahan/ for examples (Prof. Kahan is one of the people being the IEEE FP spec). Barring adding matricies to the language, your two options are operator overloads and/or functions of some sort (the two are not necessarily incompatible- a single library could supply both of them, with warnings to use the functions for best performance). By the way, there's evidence that garbage collection *increases* performance. See: ftp://ftp.nj.nec.com/pub/pls/pldi94.ps.Z if you don't already beleive me (or have already seen that paper). Brian ------------------- To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/ Beginner's list: http://groups.yahoo.com/group/ocaml_beginners