Golang : why runtime. GOMAXPROCS 限制为256？

Question

我在 MacBook 和 Ubuntu 上玩 golang 1.7.3，发现 runtime.GOMAXPROCS 被限制为 256。有人知道这个限制是从哪里来的吗？这是否记录在任何地方，为什么会有限制？这是实现优化吗？

我只能在这个描述 golang 运行时包的页面上找到对 256 的引用:https://golang.org/pkg/runtime/ . runtime.MemStats 结构有几个大小为 256 的统计数组:

type MemStats struct {
    ...
    PauseNs       [256]uint64 // circular buffer of recent GC pause durations, most recent at [(NumGC+255)%256]
    PauseEnd      [256]uint64 // circular buffer of recent GC pause end times

这是我使用的示例 golang 代码:

func main() {
    runtime.GOMAXPROCS(1000)
log.Printf("GOMAXPROCS %d\n", runtime.GOMAXPROCS(-1))

打印 GOMAXPROCS 256

附言 另外，有人可以指出有关此 GOMAXPROCS 如何与 golang 调度程序(如果有的话)使用的操作系统线程数相关的文档。我们应该观察运行 GOMAXPROCS OS 线程的 go 编译代码吗？

编辑:感谢@twotwotwo 指出 GOMAXPROCS 与操作系统线程的关系。仍然有趣的是，文档没有提到这个 256 限制(MemStats 结构中的其他限制可能相关也可能不相关)。

不知道有没有人知道这个256号的真正原因。

Answer 1

请注意，从下一个 Go 1.10(2018 年第一季度)开始，GOMAXPROCS将受限于……什么都没有。

The runtime no longer artificially limits GOMAXPROCS (previously it was limited to 1024).

参见 commit ee55000通过 Austin Clements ( aclements ) ，修复了issue 15131 .

Now that allp is dynamically allocated, there's no need for a hard cap on GOMAXPROCS.

---

allp is defined here .

另见 commit e900e27 :

runtime: clean up loops over allp

allp now has length gomaxprocs, which means none of allp[i] are nil or in state _Pdead.
This lets replace several different styles of loops over allp with normal range loops.

for i := 0; i < gomaxprocs; i++ { ... } loops can simply range over allp.
Likewise, range loops over allp[:gomaxprocs] can just range over allp.

Loops that check for p == nil || p.state == _Pdead don't need to check this any more.

Loops that check for p == nil don't have to check this if dead Ps don't affect them. I checked that all such loops are, in fact, unaffected by dead Ps. One loop was potentially affected, which this fixes by zeroing p.gcAssistTime in procresize.