[sorry for the side question but:] When there is the "channels are expensive" consideration, I assume that is from a latency perspective rather than a throughput perspective. i.e. it was my understanding that channels had a small overhead on top of a basic lock, but otherwise added very little workload. The microsecond or so of cost you see I understood was *not* due to there being thousands of operations needed to run the channel, but the latency added by the stall, and scheduler overhead. I also understood that in the case of an uncontested buffered partially full channel*, the cost of a channel was effectively that of checking the head and tail pointers; therefore as close to nothing as makes no difference.
* I know this is a rare case, but I'd also argue it's the only interesting one in data flow applications if you're concerned about the latency as in other cases you will have a contested lock and therefore the overhead of the locking will dominate. (I'm not wanting to worry at the moment about say a lock on a shared data structure (state table?) that is modified infrequently as I'd be surprised if this was done by channels in most applications) If that makes sense? Regards On Friday, 11 August 2017 12:58:54 UTC+1, Jesper Louis Andersen wrote: > > On Tue, Aug 8, 2017 at 8:01 AM snmed <sandro....@gmail.com <javascript:>> > wrote: > >> >> I stumbled over a nice and very interesting Blog entry "Go channels are >> bad and you should feel bad >> <http://www.jtolds.com/writing/2016/03/go-channels-are-bad-and-you-should-feel-bad/>" >> >> , I would like to hear some opinions about that article >> from seasoned go developers. Because I just used go for a couple of >> months for my private web projects and rarely get in touch with channels. >> >> > One way of putting it is that any synchronization/communication primitive > will have an overhead in a system. Channels are "fairly expensive" compared > to other methods. But if the processing you are doing is going to take > orders of magnitude more time than the channel communication, then you can > usually benefit from channels having some extra features in them, > especially w.r.t. system correctness: they are often easier to program with. > > You can create an exaggerated situation: suppose you are in the EU and you > decide that you want to distribute your system. You buy a server in > Australia. Imagine you have a mythical failure free connection to Australia > and you are doing RPC. You are easily looking at 300+ ms roundtrip times. > If the task you execute on the Australian server is "add two numbers", then > the 300ms overhead is a problem. > > But, if the task you are shipping to Australia is an NP-complete route > planning you want solved to optimality, you are easily looking at hours of > processing time. And then 300ms seems pretty quick! > > Channels work much the same, but the window is at the microsecond level. > If you protect an operation in the nanosecond scale by a channel, then the > channel overhead will dominate. But if you require milliseconds of > processing time, then a channel is fairly cheap. > > Note that any communication to the outside world is likely to be on the > millisecond scale, and that makes channels excellent as a tool to handle an > operation which block on some foreign input. > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
