4 ms·

> lied to Go and told it there was only one CPU but then you loose all the cool features of channels etc.. channels work just fine in a single-cpu context. con

by f2f 12y ago

> lied to Go and told it there was only one CPU but then you loose all the cool features of channels etc.. channels work just fine in a single-cpu context. concurrency is not parallelism.

dinkumthinkum 12y ago
That struck me as odd. I questioned the entire poster's results based on that statement.
- Jare 12y ago
  I took it to mean he launched several copies of the process, each copy pinned to one (and only one) core.
  - kator 12y ago
    Correct it was the only way to get Go to scale to a reasonable response rate for this application and it thus meant my CPU loading was not even since it was based on the randomness of socket connections that persisted on one cpu or another.
- coldtea 12y ago
  He's not talking about merely being able to use channels in one core setup. This misunderstanding made me question your whole comment.
scott_s 12y ago
It sounds like he wanted parallelism for performance.
georgemcbay 12y ago
channels work fine in a single-cpu context, but in the setup OP described you won't be able to use them to have the various processes talk to each other. At least not without using one of the various netchan-alikes or rolling your own channel<->ipc solution, neither of which is likely to result in an elegant solution (note how the original netchan was abandoned by the Go team).
kyrra 12y ago
I believe what your parent was looking for is being able to pin a specific goroutine to a single CPU. If you are doing network traffic analysis, if a goroutine will jump between CPUs, you get the cache-miss overhead. This is the reason snort[0] (all in C) doesn't even use threads and sticks to a single process. To be able to use multiple threads when network processing you need hardware support (or something like PF_RING[1]) to distribute your load between cores. You want to be able t keep a data stream (TCP stream) pinned to a given CPU core, and doing that in Go is near impossible with how go-routines are scheduled. [0] https://www.snort.org/ https://www.snort.org/ [1] http://www.ntop.org/products/pf_ring/ http://www.ntop.org/products/pf_ring/
- shurcooL 12y ago
  > You want to be able t keep a data stream (TCP stream) pinned to a given CPU core, and doing that in Go is near impossible with how go-routines are scheduled. Doesn't http://godoc.org/runtime#LockOSThread http://godoc.org/runtime#LockOSThread let you do that?

by f2f 12y ago

> lied to Go and told it there was only one CPU but then you loose all the cool features of channels etc.. channels work just fine in a single-cpu context. concurrency is not parallelism.

dinkumthinkum 12y ago

That struck me as odd. I questioned the entire poster's results based on that statement.

Jare 12y ago
I took it to mean he launched several copies of the process, each copy pinned to one (and only one) core.
- kator 12y ago
  Correct it was the only way to get Go to scale to a reasonable response rate for this application and it thus meant my CPU loading was not even since it was based on the randomness of socket connections that persisted on one cpu or another.
coldtea 12y ago
He's not talking about merely being able to use channels in one core setup. This misunderstanding made me question your whole comment.

scott_s 12y ago

It sounds like he wanted parallelism for performance.

georgemcbay 12y ago

channels work fine in a single-cpu context, but in the setup OP described you won't be able to use them to have the various processes talk to each other. At least not without using one of the various netchan-alikes or rolling your own channel<->ipc solution, neither of which is likely to result in an elegant solution (note how the original netchan was abandoned by the Go team).

kyrra 12y ago

I believe what your parent was looking for is being able to pin a specific goroutine to a single CPU. If you are doing network traffic analysis, if a goroutine will jump between CPUs, you get the cache-miss overhead. This is the reason snort[0] (all in C) doesn't even use threads and sticks to a single process. To be able to use multiple threads when network processing you need hardware support (or something like PF_RING[1]) to distribute your load between cores. You want to be able t keep a data stream (TCP stream) pinned to a given CPU core, and doing that in Go is near impossible with how go-routines are scheduled. [0] https://www.snort.org/ https://www.snort.org/ [1] http://www.ntop.org/products/pf_ring/ http://www.ntop.org/products/pf_ring/

shurcooL 12y ago
> You want to be able t keep a data stream (TCP stream) pinned to a given CPU core, and doing that in Go is near impossible with how go-routines are scheduled. Doesn't http://godoc.org/runtime#LockOSThread http://godoc.org/runtime#LockOSThread let you do that?