tag:blogger.com,1999:blog-1440405560330732771.post8477677727071050470..comments2023-07-13T01:34:47.947-07:00Comments on The Good Soldier LMeyerov: More on using Cilk++lmeyerovhttp://www.blogger.com/profile/05895714526572076172noreply@blogger.comBlogger2125tag:blogger.com,1999:blog-1440405560330732771.post-56561513251279483612009-01-28T22:33:00.000-08:002009-01-28T22:33:00.000-08:00That's an excellent point :) I need to rerun bench...That's an excellent point :) I need to rerun benchmarks this weekend, so I'll include that (among other things).lmeyerovhttps://www.blogger.com/profile/05895714526572076172noreply@blogger.comtag:blogger.com,1999:blog-1440405560330732771.post-45956432883233675922009-01-28T09:24:00.000-08:002009-01-28T09:24:00.000-08:00Leo,I know what you posted is just pseudo-code, bu...Leo,<BR/><BR/>I know what you posted is just pseudo-code, but you seem to imply that the work done in traverse(node) is independent of the work done in traversing the children of node. Have you considered spawning the work like this?:<BR/><BR/> function traverse(node) {<BR/> cilk_spawn work();<BR/> cilk_for (child in node.children) traverse(child);<BR/> }<BR/><BR/>This would allow the parallel for loop to start before the work is done, maximizing parallelism. As you point out, the work-stealing scheduler will not allow the system to get over-saturated. The extra parallelism may make a difference for larger numbers of processors, especially on the first node, where the work() function is a serial bottleneck.Pablohttps://www.blogger.com/profile/16497414485092450978noreply@blogger.com