[Nomen-dev] Cilk
Brought to you by:
bhurt
|
From: Brian H. <bh...@sp...> - 2002-04-10 15:00:03
|
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. 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. 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). Brian |