sp (no@thanks.com) on 10/18/06 wrote:
---------------------------
>> Rather than improving numerical performance in Java, it
>> looks like the big vendors
>> are creating new, somewhat Java-like languages with good
>> numerical performance (X10, Fortress, Chapel).
>
>Yes, I've looked at those. Very interesting from a parallel programming point of
>view (I'm stuck with openmp/mpi and hand tuned vector code right now).
>
>The cynic in me wonders if we'll see production quality versions with solid performance,
>profiling&debugging support etc. I know the funding agency is pumping money into
>improving the productivty but I fear the machines in that program will still be
>programmed in mostly Fortran, some C and a little C++. Even if they are up and running
>on the machines, will they give me access to data parallel coprocessors or only
>via library calls to the "real" code written in C.

I strongly expect they will do that. The issue I think will be the profiling/debugging/infrastructure/QOI side. Traditionally university projects are about demonstrating that things can be done, not doing them to production quality. This is why although many open-source projects are _derived from_ university projects they are almost never only university projects. Loads of work done in universities never sees the light of day for these kind of QOI issues.

>The other poster mentioned Objective Caml - I'm quite a fan! The Windows support
>isn't quite there which eliminates it for some clients. Others, on linux, are starting
>to wonder about the lack of a decent solution going forward for multithreaded programming
>(the runtime system is essentially single threaded).

Yes. This is quite a serious issue for the future of OCaml as a fast language. The authors of OCaml previously wrote CamlLight. CamlLight was multithreaded properly, but for a variety of reasons it was complex and hard to maintain. OCaml removed this feature. Many other MLs are slowly moving towards supporting multi-processing properly.

It's quite possible that in a few years something like Steel Bank Common Lisp may be doing better than OCaml. SBCL already has a reasonable threading system that can take advantage of multi-processing.

I guess this uncertainty is one of the main problems with using OCaml for performance at present.

The reason for this situation is tied up with GC. With a ML like language GC can be made much simpler and more efficient if that language is also single-threaded. This doesn't work so well in impurely functional languages like lisp. If you're curious I'll explain in full.

> I agree though that the code
>is quite fast and I'll happily take on most apps with it in preference to C++. Again
>though, for those apps where I need to think about keeping the processor really
>humming I've found I needed to drop into C and break out the Intel or Pathscale compilers.

I see, heavy stuff!