Go块是否像Node这样的处理器密集型操作？ [英] Does Go block on processor intensive operations like Node?

问题描述

Go是伟大的并发，任务作为go程序传递，go程序在虚拟处理器中处理，每当一个go例程经历阻塞操作（数据库调用），go程序被移动到另一个虚拟处理器在不同的线程，这是大部分时间在另一个物理处理器上运行...现在，我们实现并行性。

Node.js有一个类似的技术（除了一切发生在同一个线程上），但将所有等待的虚拟进程置于等待队列中，直到它们接收到阻塞资源（DB，URL）的响应，然后发送进行处理。

Node.js的缺点是它无法处理处理器密集型操作（对于循环是一个例子），虚拟进程正在运行，将占用所有时间，直到完成而没有抢占，这就是为什么Node.js在它用于关键系统之前被明智地考虑的原因，尽管它具有很高的并发可用性。

是的，Go产生一个新的线程来处理阻塞的go程序，但是对于处理器密集型操作，它们被认为是相同的，还是遭受了Node问题？

解决方案

在实践中比使用Node更困难，并且更容易从中恢复。 Node是单线程的，除非你编写显式的多进程代码（这并不总是很容易，特别是如果你想移植）。 Go使用具有某个最大数量的运行线程的N：M调度（默认情况下等于逻辑CPU的数量，但是可调）。注意正在运行：正在等待阻止操作的goroutine是冻结的，不会被视为占用正在运行的线程。

，如果你有一个goroutine做一些CPU密集型的，它一般不会影响其他goroutine的运行能力，因为有一堆其他线程可用来运行它们。如果您的goroutine中的所有都被计算占用，那么其他的都不会有机会运行，直到完成。这可能不是必然的是一个问题，如果他们实际上完成工作，因为所有的CPU都在做实际工作，但当然有时它可以在延迟敏感的情况下。

如果这是一个问题，请考虑以下三种解决方案：

1. code> runtime.Gosched 在长计算期间产生对处理器的控制，允许其他goroutine有机会运行。不必做其他改变;它只是一个工作与合作调度器的方式。 Gosched 可能会立即返回，或可能稍后返回。




2. 使用工作池限制的并行CPU密集型工作到小于GOMAXPROCS。




3. 同一个硬币的Flipside：提高GOMAXPROCS高于预期的并行计算任务数量。这可能是最糟糕的想法，并会损害调度至少有点，但它仍然可以工作，并确保您有线程可用于处理事件。

Go is great for concurrency, tasks are passed as go-routines, and go-routines are processed in a virtual processor, whenever one go-routine experience a blocking operation (a database call), the go-routine is moved to another virtual processor on a different thread, which is most of the time run on another physical processor ... now, we achieve parallelism.

Node.js has a similar technique (except everything happens on the same thread), but putting all waiting virtual processes in a waiting queue, till they receive responses from the blocking resource (DB, URL), then they are send to be processed.

The down side of Node.js, is its inability to handle processor intensive operations (for loop is an example), and the virtual process being in action, will take all the time till finish without preemption, that's why Node.js is regarded wisely before it's used in critical systems, despite it's high concurrency availability.

Yes, Go spawns a new thread to handle the blocking go-routine, but how about the processor intensive operations, are they regarded the same, or suffer from Node problems?

解决方案

Yes, but it's much more difficult to run into in practice than with Node, and much easier to recover from. Node is single-threaded unless you write explicitly multiprocess code (which isn't always easy, especially if you want to be portable). Go uses N:M scheduling with a certain maximum number of running threads (equal to the number of logical CPUs by default, but tunable). Note running: a goroutine that is waiting for a blocking operation is "frozen" and doesn't count as occupying a running thread.

So, if you have a single goroutine doing something CPU-intensive, it generally won't have an impact on other goroutines' ability to run, because there are a bunch of other threads available to run them. If all of your goroutines are occupied with computation, then it's true that other ones won't get a chance to run until one finishes. This might not necessarily be a problem if they're actually getting work done, since all of your CPUs are doing actual work, but of course sometimes it can be in latency-sensitive situations.

If it is a problem, three solutions come to mind:

1. Use runtime.Gosched during long computations to yield control of the processor, allowing other goroutines a chance to run. No other change has to be made; it's just a way of working with the cooperative scheduler. Gosched might return immediately, or it might return later.

2. Use a worker pool to limit the amount of parallel CPU-intensive work to less than GOMAXPROCS. Go makes this pretty easy.

3. Flipside of the same coin: raise GOMAXPROCS above the expected number of parallel compute tasks. This is probably the worst of the ideas, and will hurt scheduling at least somewhat, but it will still work, and ensure you have threads available for handling events.

这篇关于Go块是否像Node这样的处理器密集型操作？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！