{"action":"created","issue":{"url":"https://api.github.com/repos/JuliaLang/julia/issues/22631","repository_url":"https://api.github.com/repos/JuliaLang/julia","labels_url":"https://api.github.com/repos/JuliaLang/julia/issues/22631/labels{/name}","comments_url":"https://api.github.com/repos/JuliaLang/julia/issues/22631/comments","events_url":"https://api.github.com/repos/JuliaLang/julia/issues/22631/events","html_url":"https://github.com/JuliaLang/julia/pull/22631","id":239772670,"number":22631,"title":"WIP: parallel task runtime","user":{"login":"kpamnany","id":3784427,"avatar_url":"https://avatars1.githubusercontent.com/u/3784427?v=4","gravatar_id":"","url":"https://api.github.com/users/kpamnany","html_url":"https://github.com/kpamnany","followers_url":"https://api.github.com/users/kpamnany/followers","following_url":"https://api.github.com/users/kpamnany/following{/other_user}","gists_url":"https://api.github.com/users/kpamnany/gists{/gist_id}","starred_url":"https://api.github.com/users/kpamnany/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/kpamnany/subscriptions","organizations_url":"https://api.github.com/users/kpamnany/orgs","repos_url":"https://api.github.com/users/kpamnany/repos","events_url":"https://api.github.com/users/kpamnany/events{/privacy}","received_events_url":"https://api.github.com/users/kpamnany/received_events","type":"User","site_admin":false},"labels":[{"id":184008807,"url":"https://api.github.com/repos/JuliaLang/julia/labels/multithreading","name":"multithreading","color":"fbca04","default":false}],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":28,"created_at":"2017-06-30T13:02:38Z","updated_at":"2017-10-28T05:51:54Z","closed_at":null,"author_association":"CONTRIBUTOR","pull_request":{"url":"https://api.github.com/repos/JuliaLang/julia/pulls/22631","html_url":"https://github.com/JuliaLang/julia/pull/22631","diff_url":"https://github.com/JuliaLang/julia/pull/22631.diff","patch_url":"https://github.com/JuliaLang/julia/pull/22631.patch"},"body":"This replaces the existing fork-join threading infrastructure with a parallel task runtime (partr) that implements [parallel depth first scheduling](http://www.cs.cmu.edu/%7Echensm/papers/ConstructiveCacheSharing_spaa07.pdf). This model fully supports nested parallelism.\r\n\r\nThere is a _lot_ incomplete in the integration with Julia, so contributions are very needed.\r\n\r\nRight now, the default remains the original threading code. Enable partr by defining `JULIA_ENABLE_PARTR` (uncomment the line in `Make.inc`). The code simply compiles; it won't run probably for some time yet. There are many TODOs in the code, with more to come.\r\n\r\nThe new interface is Cilk-like, i.e. spawn, sync, and parfor (with dynamic scheduling and reduction supported).\r\n\r\nA very rough, high-level TODO list follows; this will be expanded and detailed over time.\r\n\r\nCritical path items:\r\n\r\n- [ ] Replace/integrate `jl_task_t` with `jl_ptask_t`. This includes supporting most of the interface in `event.jl` (including `Condition`) and some of `task.jl`.\r\n- [ ] Integrate Julia coroutines (yield/resume). This will remove support for symmetric coroutines, i.e. no more `yieldto()`. Initially we might try to use the existing (stack copying) switching mechanism.\r\n- [x] Allocate/free GC-able tasks.\r\n\r\nOther work items:\r\n\r\n- [ ] Faster Task stack management. This model needs task switches to be very quick for it to be effective for nested parallelism, so copying stacks is out. The plan right now is to use a pool of stacks. A task only needs a stack once it is started thus you only need as many stacks as you have running (or yielded) tasks. Recursive task spawning (like with parallel fib) will use these up quickly, but that's not a common pattern (we think?). Also, stacks can be smaller (inference is no longer recursive) so we can have more of them.\r\n- [ ] Document it all.\r\n- [ ] Integrate I/O. The main thread will drive the event loop. Tasks will (in a thread-safe way) add I/O requests to a queue serviced by the main thread (or perhaps a dedicated I/O thread).\r\n- [ ] Update the code for `Condition`. Probably all that's needed is to make it thread-safe.\r\n- [ ] Add Julia interface calls. Some name resolution across distributed and shared memory parallel constructs is necessary. How should names like `@parallel`, `@spawn`, `@async`, etc. be allocated?\r\n- [ ] Exception handling (hopefully not much to do here, since the existing task model handles it).\r\n- [ ] GC-safe all the code.\r\n\r\nIf you're helping, open PRs to this branch.\r\n\r\nCc: @JeffBezanson, @vtjnash, @yuyichao, @ViralBShah, @vchuravy."},"comment":{"url":"https://api.github.com/repos/JuliaLang/julia/issues/comments/340141557","html_url":"https://github.com/JuliaLang/julia/pull/22631#issuecomment-340141557","issue_url":"https://api.github.com/repos/JuliaLang/julia/issues/22631","id":340141557,"user":{"login":"amitmurthy","id":117461,"avatar_url":"https://avatars1.githubusercontent.com/u/117461?v=4","gravatar_id":"","url":"https://api.github.com/users/amitmurthy","html_url":"https://github.com/amitmurthy","followers_url":"https://api.github.com/users/amitmurthy/followers","following_url":"https://api.github.com/users/amitmurthy/following{/other_user}","gists_url":"https://api.github.com/users/amitmurthy/gists{/gist_id}","starred_url":"https://api.github.com/users/amitmurthy/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/amitmurthy/subscriptions","organizations_url":"https://api.github.com/users/amitmurthy/orgs","repos_url":"https://api.github.com/users/amitmurthy/repos","events_url":"https://api.github.com/users/amitmurthy/events{/privacy}","received_events_url":"https://api.github.com/users/amitmurthy/received_events","type":"User","site_admin":false},"created_at":"2017-10-28T05:51:54Z","updated_at":"2017-10-28T05:51:54Z","author_association":"MEMBER","body":"@anton-malakhov #22996 effectively takes a closure and queues it for execution on the main event loop. This is at a much higher level than intercepting individual libuv write calls and shipping them to the main event loop. I'll try and cleanup #22996 soon. I chose this model for the following reasons. \r\n\r\n- In the `Distributed` module, serializing a large object involves multiple `write` calls. It is more efficient to ship the entire top level serialization call to the main thread than individual `write` calls. This is not an issue for smaller objects where data is first written to an in-memory buffer and a single libuv `write` performed.\r\n\r\n- I don't know how much of our standard library is thread-safe. Queued execution of blocks of code is simpler than putting appropriate locks in place. Also, I suspect the locking mechanisms we have need to be better integrated with the task infrastructure.\r\n\r\nI would like to mention one more thing to keep in mind as you enhance libuv (mostly from the implementation of `Distributed` but probably equally applicable elsewhere). While a single scheduled task reads incoming requests from a socket connected to a worker, any task can write directly to the socket for outbound communication. If you envisage multiple event loops and sticky tasks, how this effects the design of socket IO can be considered. \r\n"}}
{"actor":{"display_login":"amitmurthy"}}