C and C++ are not the same language, and there is typically a notable
difference in performance between code written in one and code written in
the other, even when they do roughly the same thing. I'm sure C would,
at least in most cases, do at least as well as OCaml -- even if C++
typically lands somewhere behind imperative OCaml code.
I focused on C, and to some extent C++, as it is seen as a language
that gets closest to the metal short of assembler. In the old days the
only way to get the most performance out of some hardware was to write
it (or part of it) in C or assembler. Other languages just did not
come close.
These days however languages that such as ocaml, erlang and java have
got so good that the gap between C/C++ is less significant and
becoming a competent java programmer is much easier than becoming a
competent C programmer. That said you can get excellent performance
from these languages with less risk in development time and code
quality issues than going for C/C++.
I'm not saying that you're wrong about OCaml being a good choice for
speed. It usefully combines great performance with a good, friendly
syntax and powerful semantic model. I just don't think it's useful to
say OCaml comes in first while you mention C just because OCaml did
better than C++, which does *not* have the same performance
characteristics as C, in the general case.
The biggest issue for me was that the gap between C/C++ and languages
like ocaml, erlang and java is getting to the point where we can no
longer say that C/C++ will be the fastest. I was a big proponent of
the "write it in C" school when it comes to performance, I found out
that other languages were significantly faster than I assumed. I still
prototype in Ruby, but I no longer automatically rewrite it in C.
···
On 12 November 2010 02:42, Chad Perrin <code@apotheon.net> wrote:
Note that I'm referring to language names, but my observations tend to
hold true across major implementations of those languages, from what I
have seen.--
Chad Perrin [ original content licensed OWL: http://owl.apotheon.org ]