Version française
Home     About     Download     Resources     Contact us    
Browse thread
Re: [Caml-list] productivity improvement
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: -- (:)
From: Brian Hurt <brian.hurt@q...>
Subject: Re: [Caml-list] Re: Camlp4 optimizations (was: productivity improvement)
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