Agree with your comments. There is enough room to speed up these constructs. I have some thoughts on having channels in Base. Will post a note about it on Julia-dev in a couple of days.
On Tue, Jun 30, 2015 at 12:20 PM, ggggg <[email protected]> wrote: > I'm trying to understand coroutines for single threaded concurrency. I'm > surprised that produce()/consume() and RemoteRef have no mechanism for type > information, and as I understand it, are type unstable. One should > therefore avoid using these in inner loops I guess? Should we expect this > to remain the case? > > In Go it appears to be encouraged to heavily use concurrency even for > things as simple as generating a series of numbers. In julia you might say > a = zeros(Int,100) > for i=1:100 a[i]=i end > > In go you could certainly do that, but in my brief introduction it > appeared to be encouraged to do create a function that pushes i onto a > "channel" and then read numbers out from the channel. In julia with > produce/consume instead of a channel that would look like > counter() = for i=1:100 produce(i) end > a = zeros(Int,100) > task = Task(counter) > for i=1:100 a[i]=consume(task) end > This seems seems to violate julia performance guidelines as I understand > them, since the the compiler doesn't know what type consume(task) will > return. > > So I tried to implement something more like a go channel, that has type > information. I thought it would be faster > type GoChannel{T} > v::T > hasvalue::Bool > c::Condition > end > It turned out to be about 2x slower than the produce()/consume() approach, > and using RemoteRef (which has a more go channel like API) is about 4x > slower than produce()/consume(). On my computer anyway, the > produce()/consume() approach is about 7x slower than using a channel in go > for the same thing. > > Gist with full code: > https://gist.github.com/ggggggggg/c93a0f029620deca4f2e > > So I guess my questions are: > Why isn't there at least an option to encode type information in > consume/produce and RemoteRef? > Is there anything I could do to speed up my GoChannel implementation? Did > I make any mistakes in my other benchmarks? > > I know this is one of go's defining features, so it is perhaps > unsurprising that Julia isn't as fast for this yet. Is there room to speed > these concurrent communication constructs up? > > Thanks. >
