I thougth that using type annotations to assert the type would help, but it
doesn't:
```
counter() = for i = 1:100 x = produce(i) end
function testâ‚‚()
a = zeros(Int, 100)
task = Task(counter)
for i = 1:100
a[i] = consume(task)::Int
end
end
```
El martes, 30 de junio de 2015, 11:20:36 (UTC-5), ggggg escribió:
>
> 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.
>
