4 ms·
The interface does look a lot like Cilk, which is a definite plus as that is an absolute pleasure to use. This however offers a lot more configurability than C
by jakear 7y ago
The interface does look a lot like Cilk, which is a definite plus as that is an absolute pleasure to use.
This however offers a lot more configurability than Cilk (or at least more accessible configuration). Whether that’s a curse or blessing... I guess we’ll find out! :)
Also, have you looked into implementing Cilk-style reducers at all? [0]
[0]: https://www.cilkplus.org/docs/doxygen/include-dir/group___reducers.html https://www.cilkplus.org/docs/doxygen/include-dir/group___re...
- leiroigh 7y agoBig difference is that Cilk appears to typically synchronize on function return, while julia needs an explicit wait/fetch (there is also a @sync macro). That is, spawn/wait can be matched from the AST in cilk, while julia demands that the user communicates and stores a reference to the started task for later waiting. It is easy to forget to wait on a task, or even lose reference to it. The current scheduler will typically execute this task quickly, even if nobody ever waits on it; until load changes and you have races everywhere. There are currently no warnings comparable to Python's "RuntimeWarning: coroutine foo was never awaited".
- jakear 7y agoCilk does indeed sync on function return. You can also manually call 'cilk_sync'. I do think that Cilk’s approach is better (more in line with “make error states unrepresentable”, which I’m a big fan of), but Julia’s approach seems to be more in line with their overall goal of giving the programmer as much control as possible. Not sure if that’s a good thing or not, but as said above... we’ll find out soon!
- gpderetta 7y agoAffine types to represent futures would help here.