> 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
This archive was generated by hypermail 2b29 : Fri Apr 21 2000 - 19:23:44 MET DST