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.
