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
This archive was generated by hypermail 2b29 : Wed Apr 19 2000 - 15:09:51 MET DST