Re: [Caml-list] exene and ocaml ?

[skaller <skaller@users.sourceforge.net>]

On Sun, 2004-04-11 at 16:46, briand@aracnet.com wrote:

> I was thinking about that statement... Is that really true ?  If I
> only have maybe something like 5-10 threads running, why would it be
> such a problem ?

Probably it wouldn't, but not the reference is to:
  >> I wouldn't use or recommend a massively multithreaded approach

> I know almost nothing about the efficiency of posix threads.

The problem isn't "posix threads" per se, but Unix.
It isn't possible to use Unix kernel scheduling for efficient
task switching. Even highly optimised systems like Solaris
are required to cope with complex conditions which make
it expensive to schedule a time slice.

Also, small address space processors cannot cope
with the linear addressing problem: unlike processes,
threads share address space. If you have a lot of threads
you need a lot of stacks, and they all have to grow
'arbitrarily' large, but there isn't enough address space
for that .. even on a 64 bit machine the position is 
not good.

So actually -- FAR from the garbage collector being
a problem, the situation is exactly the opposite.
It is the heavy memory demands of the linear stack
which creates a problem a GC would have no problem
dealing with.

Felix solves some of these problems by
cooperatively multi-tasking procedural
continuations allocated on a GC managed heap
and allows O(1) event driven scheduling.
The architecture should support a GUI with
one thread for every window (and I mean 
X level window not widget), a game with
10,000 sprites, a telco system managing
100K concurrent phone calls, or any other
problem where you can factor your need
for threads of control into

(1) A few concurrent Unix style threads

(2) A huge number of threads doing almost
no work which can be scheduled on an 
event basis.

A typical architecture would divide the
Unix threads into a worker for each CPU
which drives the cooperative threading
on that CPU, and some I/O threads to
gather and dispatch events between the
worker event queues and the hardware.

This model isn't useful for all problems.
[eg -- it doesn't seem to fit parallel numerical
computing needs]

It also needs augmentation to include
persistence/network transparency to
support mobile agents, for example.

Felix generates C++, but an Ocaml back end
would be quite interesting ..

-- 
John Skaller, mailto:skaller@users.sf.net
voice: 061-2-9660-0850, 
snail: PO BOX 401 Glebe NSW 2037 Australia
Checkout the Felix programming language http://felix.sf.net



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