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