Golang功能基准测试和Go Go Sudine Call开销的结果令人困惑

Question

出于好奇，我试图了解 golang 的函数和 go 例程调用开销是多少。因此，我写了下面的基准，给出了下面的结果。 BenchmarkNestedFunctions 的结果让我感到困惑，因为它似乎太高了，所以我自然地认为我做错了什么。我预计 BenchmarkNestedFunctions 会略高于 BenchmarkNopFunc，并且非常接近 BenchmarkSplitNestedFunctions。请任何人提出我可能不理解或做错的事情。

package main

import (
    "testing"
)

// Intended to allow me to see the iteration overhead being used in the benchmarking
func BenchmarkTestLoop(b *testing.B) {
    for i := 0; i < b.N; i++ {
    }
}

//go:noinline
func nop() {
}

// Intended to allow me to see the overhead from making a do nothing function call which I hope is not being optimised out
func BenchmarkNopFunc(b *testing.B) {
    for i := 0; i < b.N; i++ {
        nop()
    }
}

// Intended to allow me to see the added cost from creating a channel, closing it and then reading from it
func BenchmarkChannelMakeCloseRead(b *testing.B) {
    for i := 0; i < b.N; i++ {
        done := make(chan struct{})
        close(done)
        _, _ = <-done
    }
}

//go:noinline
func nestedfunction(n int, done chan<- struct{}) {
    n--
    if n > 0 {
        nestedfunction(n, done)
    } else {
        close(done)
    }
}

// Intended to allow me to see the added cost of making 1 function call doing a set of channel operations for each call
func BenchmarkUnnestedFunctions(b *testing.B) {
    for i := 0; i < b.N; i++ {
        done := make(chan struct{})
        nestedfunction(1, done)
        _, _ = <-done
    }
}

// Intended to allow me to see the added cost of repeated nested calls and stack growth with an upper limit on the call depth to allow examination of a particular stack size
func BenchmarkNestedFunctions(b *testing.B) {
    // Max number of nested function calls to prevent excessive stack growth
    const max int = 200000
    if b.N > max {
        b.N = max
    }
    done := make(chan struct{})
    nestedfunction(b.N, done)
    _, _ = <-done
}

// Intended to allow me to see the added cost of repeated nested call with any stack reuse the runtime supports (presuming it doesn't free and the realloc the stack as it grows)
func BenchmarkSplitNestedFunctions(b *testing.B) {
    // Max number of nested function calls to prevent excessive stack growth
    const max int = 200000
    for i := 0; i < b.N; i += max {
        done := make(chan struct{})
        if (b.N - i) > max {
            nestedfunction(max, done)
        } else {
            nestedfunction(b.N-i, done)
        }
        _, _ = <-done
    }
}

// Intended to allow me to see the added cost of spinning up a go routine to perform comparable useful work as the nested function calls
func BenchmarkNestedGoRoutines(b *testing.B) {
    done := make(chan struct{})
    go nestedgoroutines(b.N, done)
    _, _ = <-done
}

基准测试的调用方式如下：

$ go test -bench=. -benchmem -benchtime=200ms
goos: windows
goarch: amd64
pkg: golangbenchmarks
cpu: AMD Ryzen 9 3900X 12-Core Processor
BenchmarkTestLoop-24                    1000000000               0.2247 ns/op          0 B/op          0 allocs/op
BenchmarkNopFunc-24                     170787386                1.402 ns/op           0 B/op          0 allocs/op
BenchmarkChannelMakeCloseRead-24         3990243                52.72 ns/op           96 B/op          1 allocs/op
BenchmarkUnnestedFunctions-24            4791862                58.63 ns/op           96 B/op          1 allocs/op
BenchmarkNestedFunctions-24               200000                50.11 ns/op            0 B/op          0 allocs/op
BenchmarkSplitNestedFunctions-24        155160835                1.528 ns/op           0 B/op          0 allocs/op
BenchmarkNestedGoRoutines-24              636734               412.2 ns/op            24 B/op          1 allocs/op
PASS
ok      golangbenchmarks        1.700s

BenchmarkTestLoop、BenchmarkNopFunc 和 BenchmarkSplitNestedFunctions 结果似乎彼此相当一致并且有意义，BenchmarkSplitNestedFunctions平均每个基准操作比 BenchmarkNopFunc 做的工作更多，但并不算多，因为昂贵的 BenchmarkChannelMakeCloseRead 操作大约每 200,000 次基准测试操作才执行一次。

类似地，BenchmarkChannelMakeCloseRead 和 BenchmarkUnnestedFunctions 结果看起来是一致的，因为每个 BenchmarkUnnestedFunctions 的作用比每个 BenchmarkChannelMakeCloseRead 稍多（如果仅通过递减和 if 测试可能会导致分支预测失败（尽管我希望分支预测器能够使用最后一个分支结果，但我不知道关闭函数实现有多复杂，这可能会压倒分支历史记录）

但是 BenchmarkNestedFunctions 和 BenchmarkSplitNestedFunctions 完全不同，我不明白为什么。应该有类似之处，唯一有意的区别是任何增长的堆栈重用，我没想到堆栈增长成本几乎如此之高（或者是解释，结果与结果如此相似只是巧合） BenchmarkChannelMakeCloseRead 结果让我觉得它实际上并没有按照我想象的那样进行？）

还应该注意的是 BenchmarkSplitNestedFunctions 结果有时可能会出现显着不同价值观；重复运行时，我看到一些值在 10 到 200 ns/op 范围内。它也可能无法报告任何结果 ns/op time，但当我运行它时仍然通过；我不知道那里发生了什么：

BenchmarkChannelMakeCloseRead-24         5724488                54.26 ns/op           96 B/op          1 allocs/op
BenchmarkUnnestedFunctions-24            3992061                57.49 ns/op           96 B/op          1 allocs/op
BenchmarkNestedFunctions-24               200000               0 B/op          0 allocs/op
BenchmarkNestedFunctions2-24            154956972                1.590 ns/op           0 B/op          0 allocs/op
BenchmarkNestedGoRoutines-24             1000000               342.1 ns/op            24 B/op          1 allocs/op

如果有人可以指出我在基准测试中的错误/我对结果的解释并解释到底发生了什么，那么我们将非常感激

背景信息：

1. 堆栈增长和函数内联：https://dave.cheney.net/2020/04/25/inlined-optimizes-in-go
2. 堆栈增长限制：https://dave.cheney.net/2013/06/02/why-is-a-goroutines-stack-infinite
3. Golang 堆栈结构：https://blog.cloudflare.com/how-stacks-are-handled-in-go/
4. 分支预测：https://en.wikipedia.org/wiki/Branch_predictor
5. 顶级 3900X 架构概述： https://www.techpowerup.com/review/amd-ryzen-9-3900x/3.html
6. 3900X 分支预测历史/缓冲区大小 16/512/7k: https://www.techpowerup.com/review/amd-ryzen-9-3900x/images/arch3.jpg