This change was to make the contended case faster right?
What about the non-contended case?
--
You received this message because you are subscribed to the Google Groups "golang-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Sorry didn't read the doc, my bad.
If I read correctly then the non-contended case is much faster. How can that not be worth adding the change?
Indeed and I am not in a position to judge if the maintenance overhead of the change in this particular case is worth it.
I do find the non-contended case attractive though because it increases the performance of code that really tries to use channels for concurrency in the small if that makes sense. ☺
Is it deferred with a new target release or just put on hold indefinitely?
What would constitute a justification in this case if the performance is not enough?
Go encourage the use of channels and the the faster they are, the better.
Would some sort of count and perhaps classification of public usage make up part of an empirical justification?
Is the postponement due to you realizing that it is too complicated to be worth it? Is there a thread I missed somewhere?
What would constitute a justification in this case if the performance is not enough?
Ok, so no or at least acceptable degradation in sync channels and an impact for at least a few large and well used programs or libraries. Perhaps Vitess, Nsqd and Mgo can make up a tiny suite. These I can at least rudimentarily try myself.
What I meant by thread Dmitry was if there was a discussion in an email thread somewhere. I'll look around better when I have a real computer at hand.
FYI
As per offline discussion, the "lock-free channels" change:
https://docs.google.com/a/google.com/document/d/1yIAYmbvL3JxOKOjuCyon7JhW4cSv1wy5hC0ApeGMV9s/pub
is deferred as it adds significant complexity w/o visible benefit for
real Go programs.
In this figure I have tried to explain what might be perceived as difference between implicit yield, block and deadlock.
A strong argument would be benchmarking results of a real application
that demonstrate performance improvement with the patch. Nobody
presented it so far.
On Monday, 29 September 2014 11:41:17 UTC+1, Øyvind Teig wrote:In this figure I have tried to explain what might be perceived as difference between implicit yield, block and deadlock.Channel operations are not "yielding": this would imply that the goroutine /could/ continue but instead /yields/ (as with runtime.Gosched()).
If a send/receive on a channel occurs, the goroutine cannot continue until the channel operation completes.
This is the definition of blocking.
Makes more sense to me, to explicitly block and tell the scheduler what you need in order to get useful work done instead. When you yield, you basically stop being runnable without telling the scheduler why and it must treat you as runnable and burn CPU on you.
Then yield doesn't seem to be the right term and blocking seems better. Yielding means to give up the rest of the timeslice. After that timeslice, what should the scheduler do? Handing over to you, so you yield again?Makes more sense to me, to explicitly block and tell the scheduler what you need in order to get useful work done instead. When you yield, you basically stop being runnable without telling the scheduler why and it must treat you as runnable and burn CPU on you.
On Mon, Sep 29, 2014 at 7:01 PM, <martin...@ft.com> wrote:
>>
>> A strong argument would be benchmarking results of a real application
>> that demonstrate performance improvement with the patch. Nobody
>> presented it so far.
>
>
> I have often re-factored parts of my code away from using channels in order
> to get a performance gain. Selfishly speaking, this is far from ideal, as
> it results in _my_ code being more complex. Perhaps other applications have
> changed in the same way. If so, it would be hard to show a performance
> gains with faster channels for a real application that already exists. If
> they needed that performance, they might have already moved the critical
> path away from using channels.
>
> I'm all for avoiding complexity without good reason, I just think that in
> this case, the evidence you are looking for may already have been destroyed
> through necessity.
That's true. But it also don't prove that my change would make the
apps faster. Maybe it will make them slower.
without CLRunParallel 8.31s, 8.35s, 8.58sRunParallelChan 10.43s, 10.47s, 10.53swith CLRunParallel 8.58s, 8.43s, 8.33s,RunParallelChan 9.75s, 9.72s, 9.92s, 10.12s, 10.50s, 9.8s
git clone github.com/egonelbre/spexs2 $GOPATH/github.com/egonelbre/spexs2
cd $GOPATH/github.com/egonelbre/spexs2
git checkout dev
cd _examples
make proteins.30k
On Tuesday, 30 September 2014 09:19:42 UTC+3, Dmitry Vyukov wrote:On Mon, Sep 29, 2014 at 7:01 PM, <martin...@ft.com> wrote:
>>
>> A strong argument would be benchmarking results of a real application
>> that demonstrate performance improvement with the patch. Nobody
>> presented it so far.
>
>
> I have often re-factored parts of my code away from using channels in order
> to get a performance gain. Selfishly speaking, this is far from ideal, as
> it results in _my_ code being more complex. Perhaps other applications have
> changed in the same way. If so, it would be hard to show a performance
> gains with faster channels for a real application that already exists. If
> they needed that performance, they might have already moved the critical
> path away from using channels.
>
> I'm all for avoiding complexity without good reason, I just think that in
> this case, the evidence you are looking for may already have been destroyed
> through necessity.
That's true. But it also don't prove that my change would make the
apps faster. Maybe it will make them slower.I've revived one of my earlier approaches to a graph search problem...At the time, when (~2yrs ago) I wrote that version it was too slow... of course in the mean time there have been several other updates to Go.Probably there are improvements possible to that program... aand, probably the channel isn't the slowest part of it... of course, converting it from the "locking" version to "channel" version slowed the program down a bit... Anyways, it's the closest thing I have to a real-world heavy channel use.
After testing with or without CL I'm getting about ~5% win in terms of speed, but the results are quite noisy due to the parallel to say definitively:without CLRunParallel 8.31s, 8.35s, 8.58sRunParallelChan 10.43s, 10.47s, 10.53swith CLRunParallel 8.58s, 8.43s, 8.33s,RunParallelChan 9.75s, 9.72s, 9.92s, 10.12s, 10.50s, 9.8sIf you want to test the channel mode you need to use the "dev" branch...git clone github.com/egonelbre/spexs2 $GOPATH/github.com/egonelbre/spexs2cd $GOPATH/github.com/egonelbre/spexs2git checkout devcd _examplesmake proteins.30kIt runs a simple test-case. To switch between RunParallel/RunParallelChan there is parameter "chanmode". If the process is taking too little time in proteins/conf.json you can decrease the values inside "Extension.Extendable"; I used "Matches(fore)": 1. NB. it's easy to make the program eat-up several GB of RAM.
On Tuesday, 30 September 2014 09:19:42 UTC+3, Dmitry Vyukov wrote:On Mon, Sep 29, 2014 at 7:01 PM, <martin...@ft.com> wrote:
>>
>> A strong argument would be benchmarking results of a real application
>> that demonstrate performance improvement with the patch. Nobody
>> presented it so far.
>
>
> I have often re-factored parts of my code away from using channels in order
> to get a performance gain. Selfishly speaking, this is far from ideal, as
> it results in _my_ code being more complex. Perhaps other applications have
> changed in the same way. If so, it would be hard to show a performance
> gains with faster channels for a real application that already exists. If
> they needed that performance, they might have already moved the critical
> path away from using channels.
>
> I'm all for avoiding complexity without good reason, I just think that in
> this case, the evidence you are looking for may already have been destroyed
> through necessity.
That's true. But it also don't prove that my change would make the
apps faster. Maybe it will make them slower.I've revived one of my earlier approaches to a graph search problem...At the time, when (~2yrs ago) I wrote that version it was too slow... of course in the mean time there have been several other updates to Go.Probably there are improvements possible to that program... aand, probably the channel isn't the slowest part of it... of course, converting it from the "locking" version to "channel" version slowed the program down a bit... Anyways, it's the closest thing I have to a real-world heavy channel use.