The Beauty of Concurrency in Go • Hacker News Board

Re: The Beauty of Concurrency in Go

#91

Post by pjmlp » Mon, Apr 29, 2013, 5:44 PM UTC

pjmlp wrote: post #79

laureny wrote: post #69

Earlier quoted context omitted.

> Maybe you don't realize that "they" includes Ken Thompson himself... You may disagree with the Go design team's decisions, but it's amusingly absurd to accuse them of inexperience. Not really, if anything, Go shows that its designers have a lot of inexperience when it comes to modern language design. Go would have been a kille language in the late 90's but it seems to ignore everything that we've learned about lang…

Quite true, every single feature can be traced back to 80's and 90's languages that for whatever reason did not manage to become mainstream. Maybe one could make a table stating the language feature and which language provided it for the first time.

Just an update on my comment.

Even if the language is like that, if it helps improving the situation where young developers learn that strong typing does not have anything to do with VMs, I find it quite positive.

Re: The Beauty of Concurrency in Go

#92

Post by jufo » Mon, Apr 29, 2013, 6:05 PM UTC

stephen wrote: post #63

Jabbles wrote: post #8

This article isn't bad... but it misses several important points of Go. I also note the article is 9 months old. In the hope that my criticism will be taken as constructive, with apologies for not writing detailed explanations: 1. Goroutines are not threads 2. type inference allows you to elide types in var declarations: var host = flag.String(... 3. Go's convention is to use camel case, not underscores. 4. Calling o…

Your critique (which seems valid; I'm not a Go expert) does not exactly instill confidence in the Pragmatic Programmer (PP) brand. When I read material from them, I would have assumed I'd be seeing "idiomatic code from an expert"...not "hey, I'm a newbie hacking my way around in a new language, here's what I typed out in 2 days of playing with it". I mean, I understand they're big on the "learning a new language on a…

Yes, it is part of their magazine: http://pragprog.com/magazines/2012-06 (also available in PDF, epub and mobi from http://pragprog.com/magazines)

Re: The Beauty of Concurrency in Go

#93

Post by dlsspy » Mon, Apr 29, 2013, 7:50 PM UTC

smosher wrote: post #61

cpeterso wrote: post #39

Earlier quoted context omitted.

> 6. Didn't try to convince anyone runtime.GOMAXPROCS(runtime.NumCPU()) was a good idea (it's not) So what is an appropriate GOMAXPROCS? As someone who has only dabbled in a few Go tutorials, I would imagine that you would want GOMAXPROCS to be NumCPU() (or even greater) so the goroutine thread pool could "fire on all pistons". Why does Go's scheduler default to GOMAXPROCS=1 instead of NumCPU()?

In my experience the majority of well-written concurrent programs become I/O-bound on a single processor. It's pointless to add more processors to that, and can only slow you down, and Go programs are far better behaved in the non-parallel case. At other times you should think about the number of processors you want to occupy. If the objective is to behave like an appliance, then 1:1 schedulers:cpus is not a bad ball…

Then why isn't that the default?

Re: The Beauty of Concurrency in Go

#94

Post by smosher » Tue, Apr 30, 2013, 12:08 PM UTC

dlsspy wrote: post #93

smosher wrote: post #61

Earlier quoted context omitted.

In my experience the majority of well-written concurrent programs become I/O-bound on a single processor. It's pointless to add more processors to that, and can only slow you down, and Go programs are far better behaved in the non-parallel case. At other times you should think about the number of processors you want to occupy. If the objective is to behave like an appliance, then 1:1 schedulers:cpus is not a bad ball…

Then why isn't that the default?

The default is 1 isn't it? As I pointed out, this will serve the majority of concurrent code.

The best number of processes to use is equal to the parallelism of the solution. Even with highly concurrent problems, this is still most often 1. If you get it wrong performance will suffer. But in practical terms we have more to worry about, and if you're talking to the disk and the network more than you're computing, parallelism will only increase the contention on those resources. The extra processes will consume more CPU without doing any more useful work.

So the default is pretty good.

By the way 1:1 isn't the limit either. Sometimes you will want more. If the problem truly is parallel enough to exceed your CPUs, you may want additional processes anyway. This will keep things up to speed thanks to the host's scheduler which is typically preemptive, unlike Go's. This sometimes works much better if you can pick and choose which routines run on which schedulers, and I'm not sure if Go exposes that.

Re: The Beauty of Concurrency in Go

#95

Post by dlsspy » Fri, May 03, 2013, 9:31 PM UTC

smosher wrote: post #94

dlsspy wrote: post #93

Earlier quoted context omitted.

Then why isn't that the default?

The default is 1 isn't it? As I pointed out, this will serve the majority of concurrent code. The best number of processes to use is equal to the parallelism of the solution. Even with highly concurrent problems, this is still most often 1. If you get it wrong performance will suffer. But in practical terms we have more to worry about, and if you're talking to the disk and the network more than you're computing, para…

I have no idea what my response was about. As I said, I was pretty sick that day. Sorry you had to type all this stuff to explain to me that I'm a moron. :)