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. >