One of the limitations I find with the current implementations of tasks is the lock-step nature of produce/consume as also being type unstable.
Channels which are type-stable should be much faster. Tasks should communicate via channels and I hope to have produce/consume use them too. Filling an array, or a lazy stream generator will naturally be faster - I don't know the overhead of task switching (when using a mix of tasks and channels) at this time though. On Tue, Jul 7, 2015 at 9:57 PM, andrew cooke <[email protected]> wrote: > > sorry, i phrased that really poorly. > > what i meant was, they seem to be intended as a kind of "everything > included" replacement for multiple threading. for example, the PR you link > to adds channels. > > i assumed that was why they have a reputation for being too slow to be > useful in cases where, say, you can just allocate an array, fill it in a > loop, and return the array. or am i wrong about that too? > > maybe it would be clearer if i explained a motivating example. i recently > wrote a parser combinator using a trampoline approach. obviously, i could > have used Tasks to simplify the code. but i didn't because i assumed they > would be way slower than doing the trampoline by hand. > > now i don't have a reference for that, but the comments earlier in this > thread say that they are type unstable, which would certainly not help. > > so what i am asking, i guess is: (1) am i wrong about Tasks being slow? > (2) if not, are there any plans for a faster, simpler, type-stable > coroutine? (3) or even just lazy streams, if that helps with type > stability? > > andrew > > On Tuesday, 7 July 2015 10:02:20 UTC-3, Amit Murthy wrote: >> >> Tasks are lighweight, not at all like threads. You can literally have >> thousands of them without any issues. Multi-threaded julia is a >> work-in-progress. Currently each julia process has a single thread of >> execution and tasks switch whenever there is I/O involved or on an explicit >> yield(). libuv provides the underlying event-driven I/O, timers, etc. >> >> On Tue, Jul 7, 2015 at 6:02 PM, andrew cooke <[email protected]> wrote: >> >>> >>> it seems to me that coroutines (Tasks) in julia are very much intended >>> for "heavyweight" multithread use. >>> >>> but lazy streams are really useful in general (they transformed how i >>> use python), and even full-on coroutines can be useful in some >>> single-threaded applications. so i wonder if there's a need for a >>> lighter-weight implementation? maybe something already exists - it's not >>> clear to me this needs to be part of the base language. >>> >>> andrew >>> >> >>
