parallel-processing - goroutine 是否适用于大型、并行、受计算限制的问题？

Question

对于数值问题，go-routines 是否会先发制人地进行多任务处理？

我对 Go 的精益设计、速度非常感兴趣，但最感兴趣的是 channel 是一流的对象。我希望最后一点可以通过它们应该允许的复杂互连模式，为大数据启用一类全新的深度分析算法。

我的问题领域需要对流式传入数据进行实时计算绑定(bind)分析。数据可以划分为 100 到 1000 个“问题”，每个问题的计算时间为 10 到 1000 秒(即它们的粒度是高度可变的)。然而，在输出有意义之前，结果必须全部可用，即，假设有 500 个问题出现，并且必须解决所有 500 个问题，然后我才能使用它们中的任何一个。该应用程序必须能够扩展，可能解决数千个(但不太可能是数千个)问题。

考虑到我不太担心数字库支持(大部分都是自定义的)，Go 似乎很理想，因为我可以将每个问题映射到一个 goroutine。在我投资学习 Go 而不是说 Julia、Rust 或函数式语言之前(据我所知，它们都没有一流的 channel ，所以对我来说处于直接劣势)我需要知道 goroutines 是否正确地先发制人地处理多任务。也就是说，如果我在一台功能强大的多核计算机上运行 500 个计算密集型 goroutine，我能否期望在所有“问题”之间实现合理的负载平衡，或者我是否必须一直合作“让步”，就像 1995 年那样。考虑到问题的可变粒度以及在计算期间我通常不知道需要多长时间这一事实，这个问题尤为重要。

如果另一种语言能更好地为我服务，我很高兴听到它，但我要求执行的线程(或 go/coroutines)是轻量级的。例如，Python 多处理模块对于我的扩展野心来说过于耗费资源。先发制人:我确实理解并行和并发之间的区别。

Answer 1

Go 运行时有一个模型，其中多个 Go 例程以自动方式映射到多个线程。没有 Go 例程绑定(bind)到某个线程，调度程序可能(并且将会)将 Go 例程调度到下一个可用线程。 Go 程序使用的线程数取自 GOMAXPROCS 环境变量，可以用 runtime.GOMAXPROCS 覆盖。 ().这是一个足以理解的简化描述。

Go 例程可能会在以下情况下产生:

• 在任何可能阻塞的操作上，即任何不能当场返回结果的操作，因为它是一个(可能的)阻塞系统调用，如 io.Read() 或一个操作可能需要等待其他 Go 例程，例如获取互斥量或发送到 channel 或从 channel 接收
• 关于各种运行时操作
• 如果调度程序检测到被抢占的 Go 例程占用了大量 CPU 时间，则调用函数(这是 Go 1.2 中的新功能)
• 待命 runtime.Gosched ()
• 关于 panic()
• 从 Go 1.14 开始，紧密循环可以被运行时抢占。因此，没有函数调用的循环不再可能死锁调度程序或显着延迟垃圾收集。并非所有平台都支持此功能 - 请务必 review the release notes .另见问题 #36365在此领域的 future 计划。
• 在其他各种场合

以下内容会阻止 Go 例程产生:

• 执行 C 代码。 Go 例程在通过 cgo 执行 C 代码时无法产生。
• 调用 runtime.LockOSThread (), 直到 runtime.UnlockOSThread () 已被调用。