]> Pal-Kristian Engstad writes: > Some proponents of this mailing list seem to be > convinced that Ocaml is so much more productive than > C++. I find this to be a terrible mistake. From an > industry where performance is crucial (games > programming), I find quite a few aspects of Ocaml hard > to unify with productivity. You are saying that for some tasks the superior productivity of ocaml, in terms of development time, is irrelevant because you cannot achieve the required level of performance. I (myself, personally) thought your mail contained several misconceptions about ocaml. I work with C++ in HPC, and I've played with a variety of different languages and coding idioms; I have to say that ocaml is generally quite competitive with "general purpose" C and Fortran compilers, if you write your inner loops in a Fortran style. ocaml will lose in some cases against serious Fortran compilers that do heavyweight HPC optimisations, but as far as I know very few C++ compilers have that capability (Intel's?). And for some tasks the superior performance of Fortran is irrelevant because you cannot achieve the required level of productivity :-P. ocaml also loses performances as soon as you start trying to put nice abstraction features in the inner loops. This is disappointing but not specific to ocaml: templated inner loops in C++ are fast if they only use scalars, but loops involving e.g. lightweight objects as "iterators" are not, unless you are using the KAI compiler. (Which has just been bought up and killed off by Intel, grrr. KAI was way ahead of its time; it really made it possible to write incredibly "high level" C++ and get fast code out the back. I wish all that effort had been done in a university, put into a more sensible language, and liberated so that nobody could take it away :( .) I don't agree that the lack of operator overloading is a problem, per se. If you follow the argument (passim ad nauseam in the archives) you eventually reach the conclusion that the real problem is that the compiler doesn't inline across module boundaries---and that _is_ serious. If access to machine-specific instructions is a problem, then ocaml isn't the right tool. Of course, if your uses of them occur in library routines which can naturally be written in C, then you don't have a problem. In short, ocaml is really not so bad for high performance, provided that you take care to write your inner loops in a "dumb" way and save the nice language features for the rest of the code (and you have to do that anyway, although maybe not so stringently, with C++). ------------------- 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