6 ms·

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 cl

by eblume 11y ago

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.

stygiansonic 11y ago
Like you, I was also initially confused about the default value of GOMAXPROCS - for the same reason. Great to see they have changed this to something that, without any other context, makes more sense.
cmelbye 11y ago
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.
- rsc 11y ago
  While this is technically true, it doesn't seem like that helpful a response to say "well you were getting benefits, just not this one". Until now you've had to know to ask for parallelism; it should have been there by default, and soon (I hope) it will be.
  - jlouis 11y ago
    This is, incidentally, also the Erlang default. Interrogate the system and if it is SMP capable, run with SMP enabled.
  - cmelbye 11y ago
    Oh, I agree 100%. I was just as confused as he was when I first started using Go, and I'm very excited that this change might finally happen. However, I think calling my response "technically true" is selling Go's concurrency primitives a little short. They enable a really great programming model, which makes it much easier to express certain ideas in code. And I/O-bound programs benefit even if GOMAXPROCS=1. I didn't understand that subtlety when I first started with Go, and it seems like GP commenter (and probably other HN readers) didn't either. "Concurrency is not parallelism" is very helpful in explaining that, which is why I linked to it.
- tossawayppp 11y ago
  A distinction without meaning is kind of dumb. In popular parlance parallelism and concurrency are approximately the same thing.
  - Jtsummers 11y ago
    You aren't wrong, but it does make it difficult to discuss with people. At least within the programming field it's useful to have two terms with distinct meanings to discuss the topic. Consider the terms accuracy and precision [0], where again the popular understanding is that they're (essentially) synonymous. But within the scientific and engineering world that uses the terms the distinction is critical. EDIT: Verification and validation [1] are another pair of terms where the distinction is important for industry, but popular understanding often mixes them up. [0] http://en.wikipedia.org/wiki/Accuracy_and_precision http://en.wikipedia.org/wiki/Accuracy_and_precision [1] http://en.wikipedia.org/wiki/Verification_and_validation http://en.wikipedia.org/wiki/Verification_and_validation
  - enneff 11y ago
    When having a technical discussion we should interpret technical terms with their precise meaning. Rob Pike gave a good talk about this: http://blog.golang.org/concurrency-is-not-parallelism http://blog.golang.org/concurrency-is-not-parallelism
  - bkeroack 11y ago
    It wasn't very long ago (before the multicore era) that essentially nothing running on personal computers was truly parallel. Yet multithreaded applications (concurrency) worked just fine.
  - Igglyboo 11y ago
    It does have meaning. An obvious difference is that you can have concurrency with one processor but not parallelism requires at least two.
    - chrisseaton 11y ago
      > 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
- ubernostrum 11y ago
  What I do not want in a programming language is for it to advertise features which are subject to confusion in common parlance, then say "I did what I said, you just weren't smart enough to understand what I said". My reaction is somewhat like this XKCD: https://xkcd.com/169/ https://xkcd.com/169/
  - tankenmate 11y ago
    The debate over concurrency vs parallelism hit its peak in the mid 1990s, well before Go came along. I remember having arguments with fellow students (and the occasional professor) at university about how it affects memory allocations (stack vs heap), virtual memory layout (the thread vs coroutine stack being one of the bigger issues; Linux's early introduction of mremap was particularly handy) the OS scheduler, etc. It's not just a Go / language feature thing.
aikah 11y ago
> It didn't seem to make any sense to me given the nature of the claims of the language I disagree, it makes total sense when you understand the consequences of GOMAXPROCS set to anything but 1.
- acdha 11y ago
  Concurrency was the primary selling point for Go. Setting GOMAXPROCS=1 not only failed to deliver on that but also ran the risk of people not noticing concurrency issues because all of their development happened without parallel execution.
  - aikah 11y ago
    sure, but now some programs will break. This is a breaking change.
    - acdha 11y ago
      Those programs were already broken – the developer just didn't know about it.
    - NateDad 11y ago
      This just changes the default, which anyone can do in their OS. If your program breaks when run by someone who set gomaxprocs.. that's a bug in your program.
  - eikenberry 11y ago
    Concurrency in Go is a programming model, specifically CSP. They have been very clear about this from the beginning and saying they failed to deliver on it is disingenuous.
    - coldtea 11y ago
      No, they also talked from the start about how Go makes it easy to leverage many CPUs...
smegel 11y ago
> It didn't seem to make any sense to me given the nature of the claims of the language. You mean that it was good for writing network servers capable of handling many tens of thousands of connections? You usually don't need more than one core to handle IO, and if you are doing processor intensive stuff a few more cores is not going to help if you have many thousands of requests - in this case a better pattern is a work queue and a way of letting the client know their work is done. Concurrency/threading is generally considered a "hard" topic within software dev, and if you lack a solid grounding in the basic concepts you are destined to misuse or misapply the paradigm.
- amelius 11y ago
  Sometimes a server does more than just I/O.
  - smegel 11y ago
    Well if it "does more" for every request when you are handling many thousands of concurrent requests, that is going to be one hell of a busy server.
    - paulfurtado 11y ago
      I'm not sure what you're trying to argue here. If you want to serve many requests that do significant CPU work in parallel, multiple cores are necessary no matter how efficiently Go manages the connections. Additionally, even rendering HTML templates can take quite a bit of CPU time and when Go's concurrency is limited to a single-core, that means only one template can be rendered in parallel, blocking other requests.
      - smegel 11y ago
        > If you want to serve many requests that do significant CPU work in parallel For what definition of "many"? If you have 16 cores that is 16 requests being processed in parallel. Go hasn't even got out of bed by the time it is handling 16 connections. When Go is being used for it's intended purpose - handling thousands of concurrent connections, you need to be a lot smarter than just running on all the cores you have. I'm not saying you wouldn't use all cores to maximize utilization - what I am saying if that if you are scaling beyond one core, then you would already be thinking about scaling across multiple servers behind a load balancer - i.e. you are doing ops work on a production scale cluster. And if you are doing production ops work, you are going to be tuning all the processes under your control in detail, not just making rash assumptions about how they may or may not utilization multiple cores. The point I was arguing here is that someone who said "Back when I was learning Go" and who understands the "nature of the claims of the language" is not going to be running into these sorts of scalability issues, and would not be bitterly disappointed to learn of a default threading value of 1. Unless they had some misconstrued understanding of what Go's concurrency support was all about, and made an incorrect assumption that it was primarily about parallel computation, rather than it's true purpose of having many thousands of lightweight processes handling lots of network I/O.

by eblume 11y ago

stygiansonic 11y ago

Like you, I was also initially confused about the default value of GOMAXPROCS - for the same reason. Great to see they have changed this to something that, without any other context, makes more sense.

cmelbye 11y ago

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.

rsc 11y ago
While this is technically true, it doesn't seem like that helpful a response to say "well you were getting benefits, just not this one". Until now you've had to know to ask for parallelism; it should have been there by default, and soon (I hope) it will be.
- jlouis 11y ago
  This is, incidentally, also the Erlang default. Interrogate the system and if it is SMP capable, run with SMP enabled.
- cmelbye 11y ago
  Oh, I agree 100%. I was just as confused as he was when I first started using Go, and I'm very excited that this change might finally happen. However, I think calling my response "technically true" is selling Go's concurrency primitives a little short. They enable a really great programming model, which makes it much easier to express certain ideas in code. And I/O-bound programs benefit even if GOMAXPROCS=1. I didn't understand that subtlety when I first started with Go, and it seems like GP commenter (and probably other HN readers) didn't either. "Concurrency is not parallelism" is very helpful in explaining that, which is why I linked to it.
tossawayppp 11y ago
A distinction without meaning is kind of dumb. In popular parlance parallelism and concurrency are approximately the same thing.
- Jtsummers 11y ago
  You aren't wrong, but it does make it difficult to discuss with people. At least within the programming field it's useful to have two terms with distinct meanings to discuss the topic. Consider the terms accuracy and precision [0], where again the popular understanding is that they're (essentially) synonymous. But within the scientific and engineering world that uses the terms the distinction is critical. EDIT: Verification and validation [1] are another pair of terms where the distinction is important for industry, but popular understanding often mixes them up. [0] http://en.wikipedia.org/wiki/Accuracy_and_precision http://en.wikipedia.org/wiki/Accuracy_and_precision [1] http://en.wikipedia.org/wiki/Verification_and_validation http://en.wikipedia.org/wiki/Verification_and_validation
- enneff 11y ago
  When having a technical discussion we should interpret technical terms with their precise meaning. Rob Pike gave a good talk about this: http://blog.golang.org/concurrency-is-not-parallelism http://blog.golang.org/concurrency-is-not-parallelism
- bkeroack 11y ago
  It wasn't very long ago (before the multicore era) that essentially nothing running on personal computers was truly parallel. Yet multithreaded applications (concurrency) worked just fine.
- Igglyboo 11y ago
  It does have meaning. An obvious difference is that you can have concurrency with one processor but not parallelism requires at least two.
  - chrisseaton 11y ago
    > 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
ubernostrum 11y ago
What I do not want in a programming language is for it to advertise features which are subject to confusion in common parlance, then say "I did what I said, you just weren't smart enough to understand what I said". My reaction is somewhat like this XKCD: https://xkcd.com/169/ https://xkcd.com/169/
- tankenmate 11y ago
  The debate over concurrency vs parallelism hit its peak in the mid 1990s, well before Go came along. I remember having arguments with fellow students (and the occasional professor) at university about how it affects memory allocations (stack vs heap), virtual memory layout (the thread vs coroutine stack being one of the bigger issues; Linux's early introduction of mremap was particularly handy) the OS scheduler, etc. It's not just a Go / language feature thing.

aikah 11y ago

> It didn't seem to make any sense to me given the nature of the claims of the language I disagree, it makes total sense when you understand the consequences of GOMAXPROCS set to anything but 1.

acdha 11y ago
Concurrency was the primary selling point for Go. Setting GOMAXPROCS=1 not only failed to deliver on that but also ran the risk of people not noticing concurrency issues because all of their development happened without parallel execution.
- aikah 11y ago
  sure, but now some programs will break. This is a breaking change.
  - acdha 11y ago
    Those programs were already broken – the developer just didn't know about it.
  - NateDad 11y ago
    This just changes the default, which anyone can do in their OS. If your program breaks when run by someone who set gomaxprocs.. that's a bug in your program.
- eikenberry 11y ago
  Concurrency in Go is a programming model, specifically CSP. They have been very clear about this from the beginning and saying they failed to deliver on it is disingenuous.
  - coldtea 11y ago
    No, they also talked from the start about how Go makes it easy to leverage many CPUs...

smegel 11y ago

> It didn't seem to make any sense to me given the nature of the claims of the language. You mean that it was good for writing network servers capable of handling many tens of thousands of connections? You usually don't need more than one core to handle IO, and if you are doing processor intensive stuff a few more cores is not going to help if you have many thousands of requests - in this case a better pattern is a work queue and a way of letting the client know their work is done. Concurrency/threading is generally considered a "hard" topic within software dev, and if you lack a solid grounding in the basic concepts you are destined to misuse or misapply the paradigm.

amelius 11y ago
Sometimes a server does more than just I/O.
- smegel 11y ago
  Well if it "does more" for every request when you are handling many thousands of concurrent requests, that is going to be one hell of a busy server.
  - paulfurtado 11y ago
    I'm not sure what you're trying to argue here. If you want to serve many requests that do significant CPU work in parallel, multiple cores are necessary no matter how efficiently Go manages the connections. Additionally, even rendering HTML templates can take quite a bit of CPU time and when Go's concurrency is limited to a single-core, that means only one template can be rendered in parallel, blocking other requests.
    - smegel 11y ago
      > If you want to serve many requests that do significant CPU work in parallel For what definition of "many"? If you have 16 cores that is 16 requests being processed in parallel. Go hasn't even got out of bed by the time it is handling 16 connections. When Go is being used for it's intended purpose - handling thousands of concurrent connections, you need to be a lot smarter than just running on all the cores you have. I'm not saying you wouldn't use all cores to maximize utilization - what I am saying if that if you are scaling beyond one core, then you would already be thinking about scaling across multiple servers behind a load balancer - i.e. you are doing ops work on a production scale cluster. And if you are doing production ops work, you are going to be tuning all the processes under your control in detail, not just making rash assumptions about how they may or may not utilization multiple cores. The point I was arguing here is that someone who said "Back when I was learning Go" and who understands the "nature of the claims of the language" is not going to be running into these sorts of scalability issues, and would not be bitterly disappointed to learn of a default threading value of 1. Unless they had some misconstrued understanding of what Go's concurrency support was all about, and made an incorrect assumption that it was primarily about parallel computation, rather than it's true purpose of having many thousands of lightweight processes handling lots of network I/O.