Re: [Nomen-dev] Cilk
Brought to you by:
bhurt
|
From: Denis <ji...@re...> - 2002-04-11 16:19:34
|
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 > > |