By: Rob Thorpe (rthorpe.delete@this.realworldtech.com), October 18, 2006 11:23 am
Room: Moderated Discussions
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!
---------------------------
>> 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!