openlang

builder 升到 golang:1.25 后,pod 里 GOMAXPROCS 还是 32

已经用 golang:1.25 重新构建了,本以为运行时能识别到 2 个 CPU 的限制。pod 里还是打印 gomaxprocs=32 numcpu=32,而且每次运行 nr_throttled 都会涨几千。workers 从 16 降到 4,也只是把耗时从 9 分钟降到 7 分钟。我是漏了什么?谢谢。

FROM golang:1.25 AS build
...
RUN CGO_ENABLED=0 go build -o /manifestd .
module github.com/maxlab/manifestd

go 1.23.0
resources:
  requests:
    cpu: "1"
  limits:
    cpu: "2"

pod 的环境变量里没有设置 GOMAXPROCS,代码里也没有任何地方用具体的值调用 runtime.GOMAXPROCS。同一个二进制在我的 MacBook 上大约 2.5 分钟就跑完了。

从英语翻译查看原文

后续讨论 3

顺着彼此的依据读下去

同一个问题的其他角度

  1. 简单循环非常慢,gfortran,200000 x 64 数组

    一个小型标定工具,代码在下面。输出是对的,但太慢了。detrend+clip 要好几秒,rms 也比该有的速度慢,每个元素只有一次乘法和一次加法。我试过 -O3 和 -march=native,没什么变化。怀疑是 Apple silicon 上的 s…

    回复 2最近活动 fortran
  2. running_mean 很慢,时间花在 memmove 而不是算术运算上

    平滑传感器数据。数组是 readings(nstation, ntime),站点在前,因为数据文件就是这样排布的,其他工具也要读。对站点做一层循环,每个站点调用一次 running_mean: 模块里是这样: 规模是 1500 个站点,20000 个…

    回复 1最近活动 fortran
  3. 你说的是哪个构建时间?

    每个讨论拆 crate 的帖子,最后都会有人甩出一个构建时间。其实有两个,而且变化方向不一样。 干净构建指的是从空的 target 开始的全部过程。拆分可能会让它稍微变差,因为每个 crate 都带着自己的元数据,链接器还是得看到全部内容。编辑循环指…

    回复 2最近活动 rust