
Go 1.5 max procs default - enneff
https://golang.org/s/go15gomaxprocs
======
eblume
Back when I was learning Go, I was astounded to learn that GOMAXPROCS was set
to 1 by default. It didn't seem to make any sense to me given the nature of
the claims of the language. Of course when I investigated why the default was
1 I learned the reasons why (which this article talks about), but it still
left a bad taste in my mouth.

I'm glad that Go has matured to the point where this can be a historical
footnote! Good work, Go team.

~~~
cmelbye
See also: Concurrency is not Parallelism [http://blog.golang.org/concurrency-
is-not-parallelism](http://blog.golang.org/concurrency-is-not-parallelism)

You can still benefit from the "claims of the language", even if code isn't
running in parallel.

~~~
tossawayppp
A distinction without meaning is kind of dumb. In popular parlance parallelism
and concurrency are approximately the same thing.

~~~
Igglyboo
It does have meaning. An obvious difference is that you can have concurrency
with one processor but not parallelism requires at least two.

~~~
chrisseaton
> parallelism requires at least two

Interestingly there is one example of parallelism without concurrency and with
just one processor and just one core - vector instructions. Although it would
be a breathtakingly good compiler that could emit vector instructions to
schedule two goroutines in parallel

------
Rexxar
Strangely, on my computer, Firefox reports a security error on the site. No
error in Chrome.

    
    
        An error occurred during a connection to golang.org.
        security library: DER encoded incorrectly formatted
        message. (Error code: sec_error_bad_der)
    

I didn't have this the last time I went on golang.org.

~~~
rockdoe
The cert includes a wildcard for *.google, which Firefox rejects because it's
a wildcard on a top level domain. I can't really tell who's right here from
the specs.

[https://bugzilla.mozilla.org/show_bug.cgi?id=1169149](https://bugzilla.mozilla.org/show_bug.cgi?id=1169149)

~~~
stygiansonic
Good catch! The addition is for the new .google TLD.

Looks like the Chromium source code had some "protection" against this, at
least at one point in time:
[http://security.stackexchange.com/questions/6873/can-a-
wildc...](http://security.stackexchange.com/questions/6873/can-a-wildcard-ssl-
certificate-be-issued-for-a-second-level-domain)

It appears that the specification (RFC 2818?) doesn't specify what is
acceptable with regards to allowed wildcard certificates - leaving the various
implementations to decide what is "too risky" for themselves.

------
tptacek
This probably always should have been the default, since bumping GOMAXPROCS
from 1 to N can reveal bugs.

~~~
akavel
Worth to note that they address this concern in a way in the doc:

 _> Correctness. There is one non-performance concern. Increased parallelism
could make bugs in racy programs more likely to cause crashes or other
problems. The setting of GOMAXPROCS=1 may have thus far let those bugs go
undetected. Raising it may therefore make buggy programs less reliable. We
hope that both the race detector and the introduction of goroutine preemption
and interleaving in Go 1.1 has already helped programmers identify and
eliminate many such bugs. In any event, we can’t reasonably hobble the
performance of working Go programs for fear of breaking buggy ones. If such
buggy programs do turn up, the authors can set GOMAXPROCS=1 explicitly to keep
them working until the bugs can be fixed._

~~~
twoodfin
As someone with little experience in Go, I'm curious: How do racy programs end
up crashing? Do they just end up in some inconsistent state and panic or can
you actually trigger a CPU fault?

~~~
kasey_junk
Setting something to nil and then referencing it is a trivial race condition
to create which can cause a crash.

~~~
twoodfin
Thanks for this response, and all the others. For some reason I had it in my
head that Go's CSP concurrency model precluded sharing of that kind.

~~~
tptacek
Golang's CSP _idiom_ precludes that sharing. The language itself was
explicitly designed not to preclude it: if you know what you're doing (or,
unfortunately, don't), you can easily design concurrent data structures using
locks or atomic operations. Golang doesn't even cordon this stuff off as
"unsafe"; like in most languages, shared mutable is the default.

That said: unlike, say, string counting idioms in C, the share-using-channel
idiom in Golang is powerful, in the sense of: it's what most people reach for
by default.

For a language as opinionated as Golang, it's extraordinarily pragmatic. It is
designed first and foremost to be a tool, and then a lot of other things,
before being a statement about how to design safe programs.

~~~
pcwalton
I don't actually know of a single language that has locks and atomics, but
marks them unsafe. All languages I know of either have them and mark them safe
and idiomatic (for example, Golang or Rust), or don't have them at all (for
example, Erlang).

------
staunch
> _We hope that both the race detector and the introduction of goroutine
> preemption and interleaving in Go 1.1 has already helped programmers
> identify and eliminate many such bugs._

I recall that it took me a while to discover the race detector when I started
using Go. Now I always set GOMAXPROCS=runtime.NumCPU() and use the race
detector.

[https://golang.org/doc/articles/race_detector.html](https://golang.org/doc/articles/race_detector.html)

------
PopsiclePete
Go 1.5 is shaping to be a pretty major release! Definitely _feels_ more major
than 1.3 and 1.4 were. Really happy it's progressing so nicely. Can't wait to
see the GC improvements in 1.6+.

------
vruiz
Direct link for Firefox users since there is a certificate error:
[https://docs.google.com/document/d/1At2Ls5_fhJQ59kDK2DFVhFu3...](https://docs.google.com/document/d/1At2Ls5_fhJQ59kDK2DFVhFu3g5mATSXqqV5QrxinasI/preview?sle=true)

------
fuddle
Firefox users use -
[http://golang.org/s/go15gomaxprocs](http://golang.org/s/go15gomaxprocs)

------
davidw
> we propose to change the default setting of GOMAXPROCS to the number of CPUs
> available, as determined by runtime

That's what Erlang does, too.

------
amelius
I hope that at least the standard libraries that come with Go are thread safe
(?)

Do they test them on a regular basis, appropriately, with GOMAXPROCS > 1?

------
spullara
My prediction is that it is going to reveal tons of bugs in libraries. They
really should have defaulted it to 2.

~~~
rco8786
Curious, why? Seems that anything over 1 would reveal the same bugs.

~~~
darshan
I'm interpreting the suggestion to mean that the original default with Go 1.0
should have been 2, because that is the lowest value (and thus would have the
least of the the performance problems documented here) that would, as you say,
reveal the same bugs. That way raising it to runtime.NumCPU wouldn't be a
potentially breaking change.

Personally, I've found the issue to be documented well enough, and it is easy
enough to set GOMAXPROCS to whatever works best for a given program, that I'm
content with how the team has handled it. And I'm thrilled at the work that is
being done now to fix the issue once and for all.

------
higherpurpose
I thought it was set to 1 CPU because that's the only way for Go to guarantee
thread-safety. Is that fixed in 1.5, or does Google just choose to ignore that
in this release due to the performance benefits?

~~~
bradfitz
No, that was one of the reasons for GOMAXPROCS=1 on App Engine, which is a
hardened environment.

For your own code, we trust you to fix your races or deal with the
consequences.

~~~
Strom
Does this mean that App Engine will never see it raised above 1?

~~~
enneff
No.

------
zerr
Any updates regarding generics and error handling?

~~~
PopsiclePete
Yep! Confirmed in Go 1.6. Also - algebraic data types, monads, operator
overloading, actors, STM, multiple inheritance, exceptions, LINQ, full opt-in
dynamic typing, optional GC! Anything you want! _All_ language features, ever
conceived, will be crammed into Go, starting with the next release!

~~~
artursapek
No shit! I'm buying my ticket to Gophercon immediately

~~~
bketelsen
I just scanned registrations and don't see you there....

