Hacker News Reader

Comment by f2f | Hacker News Reader

> 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.

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/

[1] http://www.ntop.org/products/pf_ring/

> 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 let you do that?

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).

It sounds like he wanted parallelism for performance.

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

I took it to mean he launched several copies of the process, each copy pinned to one (and only one) core.

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.

He's not talking about merely being able to use channels in one core setup. This misunderstanding made me question your whole comment.

Reply on news.ycombinator.com