Re: [Nomen-dev] Cilk

[Denis <ji...@re...>]

Hi Brian & all
On Wednesday, April 10, 2002, at 04:16  pm, Brian Hurt wrote:

>
> I've done some reading on Cilk, and have my preliminary responses:
>
> It's an interesting idea and very usefull, in a certain domain of
> problems.  I am, in fact, strongly thinking of using it for 
> another one of
> my projects (which is in that domain).  It is not a general purpose
> threading paradigm, however.
>
> 1) Their response to data race conditions is the same as the old joke
> "Doctor, it hurts when I do this!"  "Well, don't do that, then!"  
> Indeed,
> several of their theoretical papers say that in the precesence of 
> locks,
> their proofs of perfection go out the window.  I notice a distinct 
> lack of
> producer-consumer or shared-resource problems among the programs 
> they brag
> about- it's all programs that are very easy to split up the data among
> different processes and run with no synchronization whatsoever.

Yes, their lock system is not very integrated. Do you think it 
can't be further improved?

>
> 2) Their model of multithreading doesn't provide real 
> asynchronicity, or
> any sort of latency bounding.  This makes it unsuitable for 
> anything where
> you need to interrupt a computation- for example, what GUIs use
> multithreading for (allowing one thread to go off and do some expensive
> computation while another thread polls for GUI events, and can 
> abort the
> expensive computation when the user hits cancel).  In cilk on a
> monoprocessor, the expensive computation would start and not let 
> the GUI
> thread have any clock cycles until it was finished- by which point the
> user has aborted the program and rebooted the computer, because 
> obviously
> the program locked.  Even in a SMP/SMT environment, the expensive
> computation could (should) easily fill up all the processors with sub
> parts of it's expensive computation and the same problem exists.

I agree totally with the above paragraph. What you want to do with 
this kind of multithreading is computation.

>
> 3) On the other hand, for problems in it's domain, cilk-style
> multithreading is within a loud shout of the optimal solution.  
> Capable of
> keeping a large number of processors busy, and with near-optimal
> scheduling.  For the problems it serves, it's the best at serving them.
> Which means that it may be good for Nomen to support more than one 
> style
> of multithreading- old style "he-man" threads, and cilk-style 
> computation
> threads.  The disadvantage of this is that it makes for a new 
> style of bug
> (using the wrong type of threading).

Can't we get rid of old-school threads? Maybe using constraint 
programming... I knew of a language that had constraint programming 
right but I can't find its name again. You could define 
function-like structures containing a list of affectations, and at 
each iteration the value of left-hand sides was updated. You used 
"pre" to get the value of last iteration.

Something like:

fun fib(n)
	f0 = 1
	f1 = 1
	i = pre i + 1 | 1
	f = (if i = 0 then f0) | (if i = 1 then f1) | pre f + pre pre f
	fib = (if i = n then f)
end

I forgot the details...
Anyway the interest of this approach is that a condition can be 
fulfilled at any time and the treatement follows, making it 
suitable for GUIs (seems to me).

-- Denis.

>
> Brian
>
>