Re: [Caml-list] Re: feature priorities (multithreading)

[Brian Hurt <brian.hurt@qlogic.com>]

On Wed, 19 Feb 2003 cashin@cs.uga.edu wrote:

> James Leifer <James.Leifer@inria.fr> writes:
> 
> ...
> > What kind of multithreading features do you need?  It would be
> > interesting to understand what would be useful in Ocaml, especially
> > from people who have worked with Erlang, for example.
> 
> Personally, I try to avoid threads because they usually make my
> programs less portable and sometimes more complex.  But many people
> who do parallelizable computation, like scientific computations
> involving matrices, like to increase performance by taking advantage
> of SMP architectures.
> 
> If the threads in a program only run on one processor, then all you
> have is the overhead.  If they run on different processors at the same
> time, with access to the same main memory but with independent caches,
> then the performance benefits start to compensate for the extra
> complexity of multithreading.
> 

With the increasing popularity of SMT CPUs (for example, the P4, and
comming soon the Power5), multithreading for performance will become more
usefull.  For multithreading for performance, I like the cilk interface
myself:

http://supertech.lcs.mit.edu/cilk/

I still haven't wrapped my brain around JoCaml yet, so I can't say which 
is better.  What I like about Cilk is that it allows you to effectively 
use a single CPU, or hundreds, with the same executable.

There is a second use for multithreading: responsiveness.  In a GUI
program, you have multiple threads going at once.  One is responding to
GUI events, the others are performing various time consuming tasks.  The
alternative is to be continually polling the GUI- and if you forget to do
that, you annoy your users.  An example of this would be browsers- one (or
more) threads are downloading files from the web server, while another
thread is waiting on the GUI.  So when you hit 'stop', the GUI can wake up
and actually stop downloading the pages.  Note that cilk style
multithreading would *not* be usefull for solving this problem- cilk is
purely a speed improvement.  This is more why Java added multithreading.

Note that cilk-style multithreading only makes sense with SMP, or at least 
SMT, environments and kernel-level threads.  Java-style multithreading 
works just fine with userspace threads.

Multithreading is more difficult to program than single threading, there 
is no doubt about that.  Although, interestingly enough, I think purely 
functional programs would be easier to multithread than imperitive 
programs.  The big bugbear of multithreaded programs- race conditions- are 
a side effect of, well, side effects.

I've toyed occassional with the idea of having the compiler or run time 
environment add synchronization automatically.  If possible, this would be 
the holy grail of multithreaded programming.  The idea would be that 
objects only visible to one thread don't need any sort of synchronization.  
It's objects visible from two or more threads that need synchronization.  
So a garbage collection like algorithm could detect those objects that 
need synchronization and add it.  Static analysis might also be usefull- I 
don't know.

Brian


-------------------
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