On Tue, Jul 10, 2012 at 6:05 PM, Brian Anderson <[email protected]> wrote:
> Tasks do have a memory cost, but it is theoretically quite low. Rust tasks
> on linux currently have somewhere around 4K of overhead, and that's around
> 3K more than we would like and think is possible. Most of that is dedicated
> to the call stack, and there are a lot of potential future optimizations to
> minimize the cost of creating a task (by e.g. reusing them). The intent is
> that you should not have to think about whether using a task is too
> expensive, because it is cheap.

It would be cool if tasks started out more like PPL/TBB/Cilk tasks and
transitioned into the current thread-like construct and allocated
stack space only if needed. I.e. the first time a task needs to yield
its underlying "worker thread" (because it's about to block) it would
go through the work of allocating a stack (and heap?) and copy its
state into it. This would make task-parallel type things very cheap
since in that scenario most tasks would just run to completion on the
worker thread's task (and heap?), while still allowing you to use the
same mechanism for longer running tasks. Tasks which have a clear
non-avoidable yield point in them could just allocate all this
up-front of course. Maybe this is a bit too magical and there should
just be a different task-like concept that maps better to
task-parallelism.

I have to say that the latest PPL/TBB task API (they're basically the
same) is a joy to use. I would conjecture that they're much faster
than Rust's tasks in the fast path, although I haven't benchmarked,
because they don't try to be threads, they're just little jobs that
run on the stack of the worker thread (if they block, they will block
the underlying worker thread - which falls back to the OS scheduling
an overprovisioned set of worker threads onto the actual CPU threads).
See e.g. this page for some example code (though it also shows some
parallel for_each and stuff like that):
http://msdn.microsoft.com/en-us/library/dd492427(v=vs.110).aspx

-- 
Sebastian Sylvan
_______________________________________________
Rust-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/rust-dev

Reply via email to