Check out https://github.com/JuliaLang/julia/pull/12042
Currently produce/consume work in lock-step. I think they should use a channel for inter-task communication once the above PR is merged. On Wed, Jul 1, 2015 at 3:03 AM, ggggg <[email protected]> wrote: > Looking forward to your note Amit. Maybe I can find a small part to help > with. > > I'm just learning about concurrent programming, so your comments are > helpful Tom. I noted all the benchmarks I did with julia relative to go, > but I also did a simple go loop vs go with channels and the slowdown was a > factor of a few hundred, which probably means this type of programming > isn't well suited for inner loops unless as you suggest there is some sort > of automatic translation to unrolled loops. I guess it's probably more > appropriate for larger organizational type parts. > > > > On Tuesday, June 30, 2015 at 10:20:36 AM UTC-6, ggggg 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. >> >
