Ruminations on Computer System

Go语言defer的作用域为当前函数

2023-01-10T00:00:00+00:00

Go官方对defer关键字的行为解释，第一句是：

A “defer” statement invokes a function whose execution is deferred to the moment the surrounding function returns

defer的作用域是一个函数，在函数退出时立即调用。在任何{ }包围的区间里写defer，效果等同于在该执行点注册一次defer。

1 在循环和if语句中注册defer

考虑下面的代码会打印什么内容？

package main

import "fmt"

func main() {
	i := 0

	for {
		defer func(itr int) {
			fmt.Printf("finish loop %d\n", itr)
		}(i)
		if i > 5 {
			break
		}
		i++
	}

	if i > 5 {
		defer fmt.Printf("finish if\n")
		fmt.Printf("Yes\n")
	}

	fmt.Printf("end proc\n")
}

结果是，先打印”Yes”和”end proc”，之后再按照defer注册的逆序打印相应内容，即defer的调用顺序。如下：

Yes
end proc
finish if
finish loop 6
finish loop 5
finish loop 4
finish loop 3
finish loop 2
finish loop 1
finish loop 0

2 在多次运行行为不同的代码块中注册defer

现在考虑如下代码。和上面的if语句不同的是，由于rand存在，程序每次运行的行为都可能与上一次不同。那么defer的注册是否也可以是有选择的呢？

package main

import (
	"fmt"
	"math/rand"
	"time"
)

func main() {
	rand.Seed(time.Now().UnixMicro())
	r := rand.Int()
	if r%2 == 1 {
		defer fmt.Printf("random number is odd\n")
	}

	fmt.Printf("end proc, r%%2 = %v\n", r%2)
}

程序运行两次，产生不同的随机数与不同的行为：

end proc, r%2 = 1
random number is odd

end proc, r%2 = 0

所以可以得出结论，defer在代码块中的注册也是有选择的，没有运行到的代码是不会对defer注册的。

Go语言channel的输出顺序

2022-12-23T00:00:00+00:00

关于有缓冲和无缓冲channel，网上有许多介绍。简单来讲，有缓冲的channel提供了一个有限长度的有序通知队列，生产者在队列充满前都是无阻塞的向里面填入内容，且当队列非空时消费者可以无阻塞的从channel中接收通知，队列空时消费者阻塞。而无缓冲的channel提供的是阻塞的通知机制，生产者在向其中填入内容时可能会阻塞，阻塞的条件是消费者此时是否已经阻塞在channel上等待接收，如果没有则生产者阻塞。

但是，关于无缓冲channel的通知顺序，网上没有太多介绍。本文通过简单的实验确认了，无缓冲channel的通知顺序同样是按照生产者发出通知的顺序来的。不过如果生产者本身发起通知的顺序不定，则channel的输出顺序也会不定。

1 生产者按序写入channel

实验代码如下。这段代码对一个无缓冲channel中按照每100ms的间隔向里面写入，标号顺序为0~9。在等待足够长的时间之后（2s），再反复从channel取出标号。

package main

import (
	"fmt"
	"time"
)

func main() {
	ch := make(chan int)

	for i := 0; i < 10; i++ {
		go func(idx int) {
			ch <- idx
		}(i)
		time.Sleep(time.Millisecond * 100)
	}

	time.Sleep(time.Second * 2)

	for i := 0; i < 10; i++ {
		fmt.Printf("%v\n", <-ch)
	}
}

反复运行，可以看到总是有如下输出：

$ go run main.go
0
1
2
3
4
5
6
7
8
9

说明无缓冲channel的通知顺序同样是按照生产者发出通知的顺序来的。

2 生产者无序写入channel

使用强制睡眠并不能反映真实代码中常见的多goroutine竞争channel的场景。于是，去掉上述代码的部门睡眠，得到如下代码：

package main

import (
	"fmt"
	"time"
)

func main() {
	ch := make(chan int)

	for i := 0; i < 10; i++ {
		go func(idx int) {
			ch <- idx
		}(i)
	}

	time.Sleep(time.Second * 2)

	for i := 0; i < 10; i++ {
		fmt.Printf("%v\n", <-ch)
	}
}

运行可以发现，输出的顺序并没有按照0~9的顺序来。由于goroutine的启动与调度顺序并不完全按照代码调用顺序来，所以channel的输出也不会按照0~9的顺序出现。实际打印出的顺序就是生产者goroutine中写入channel的顺序。多次运行，其中两次的结果如下：

$ go run main.go
3
0
1
2
6
4
5
7
8
9

$ go run main.go
9
0
1
2
3
4
5
6
7
8

本文通过代码实验了channel的输出顺序，确定了channel具有保序的特性。

对比Go和C++编译器生成的汇编

2022-11-09T00:00:00+00:00

写代码的时候发现一个有趣的现象，同样的一段循环的逻辑，使用Go语言竟然比C++快不少。十分简单的代码却有不同的运行速度，怀疑是两个编译器生成了不同的汇编，于是进行深入调查。

1. Go版本

go version go1.19.2 linux/amd64

package main

func main() {
    for i := 0; i < 1000000000; i++ {}
}

编译运行

$ go build
$ time ./app
real    0m0.168s
user    0m0.168s
sys     0m0.000s

2. C++版本

g++ (Ubuntu 11.2.0-19ubuntu1) 11.2.0

int main() {
    for (long long i = 0; i < 1'000'000'000ull; i++) {}
}

编译运行

$ g++ main.cpp
$ time ./a.out
real    0m0.331s
user    0m0.331s
sys     0m0.000s

3. 分析一

上述代码的运行环境是Win11 22H2 WSL2，Ubuntu 22.04，CPU是i7-12700H，内存32GB。

直接上objdump，分析上面生成的两个elf文件。需要指出的是，我在编译C++代码时没有用-O选项。这种简单的循环在开了g++优化选项后会被编译器当作无副作用代码而舍弃掉。

$ objdump -d ./app > app.asm
$ objdump -d ./a.out > main.asm

还原汇编后，把代码拉到最下面，就可以看到main函数真正的样子。

首先是Go编译器生成的汇编。大致意思是，将rax寄存器置0（低32位的eax对自身取异或即可实现），然后反复对rax里面的值加1（inc指令）并且判断这个值是否满足条件（第一次运行直接跳转到457c07行，随后在457c04到457c0d之间循环，直到cmp的结果不会让jl跳转，程序将执行ret退出函数）。这里go编译器把原先代码里的变量i映射为了寄存器中的一个值。

0000000000457c00 <main.main>:
  457c00:	31 c0                	xor    %eax,%eax
  457c02:	eb 03                	jmp    457c07 <main.main+0x7>
  457c04:	48 ff c0             	inc    %rax
  457c07:	48 3d 00 ca 9a 3b    	cmp    $0x3b9aca00,%rax
  457c0d:	7c f5                	jl     457c04 <main.main+0x4>
  457c0f:	c3                   	ret

其次是g++生成的汇编。可以看到，C++代码中的变量i作为一个函数局部变量，被放到了当前的栈空间上，用-0x4(%rbp)表示其位置。其余的逻辑，就和Go的汇编一样了。

0000000000001129 <main>:
    1129:	f3 0f 1e fa          	endbr64
    112d:	55                   	push   %rbp
    112e:	48 89 e5             	mov    %rsp,%rbp
    1131:	c7 45 fc 00 00 00 00 	movl   $0x0,-0x4(%rbp)
    1138:	eb 04                	jmp    113e <main+0x15>
    113a:	83 45 fc 01          	addl   $0x1,-0x4(%rbp)
    113e:	81 7d fc ff c9 9a 3b 	cmpl   $0x3b9ac9ff,-0x4(%rbp)
    1145:	7e f3                	jle    113a <main+0x11>
    1147:	b8 00 00 00 00       	mov    $0x0,%eax
    114c:	5d                   	pop    %rbp
    114d:	c3                   	ret

那么，是不是就可以判断上述C++代码比Go代码慢一倍的原因，在于g++编译的时候没有对变量位置进行寄存器优化呢？如果猜想成立，也就意味着当使用g++寄存器优化后，两份代码的运行时间应该相近。

4. 分析二

根据上面的分析，我们需要调整编译参数或者使用代码上的技巧，来使C++编译器把变量放在寄存器中而不是内存里（cache）。不过，我并没有找到相关的优化技巧。反而是C语言支持register关键字可以指导编译器对变量进行寄存器优化。那么让我们先来用C语言试一试。

int main() {
    for (register int i = 0; i < 1000000000ull; i++) {}
}

编译运行

$ gcc main.c
$ time ./a.out
real    0m0.237s
user    0m0.237s
sys     0m0.000s

的确快了，但也没有特别快，而且多次运行会出现比较大的波动，在190ms到290ms之间。看一看汇编长什么样。核心部分，将rbx寄存器置0，并且反复加1（add指令）。但是，比较的时候却是先把rbx寄存器里面的值拷贝到rax中，然后判断rax是否满足条件（cmp指令）。

0000000000001129 <main>:
    1129:	f3 0f 1e fa          	endbr64
    112d:	55                   	push   %rbp
    112e:	48 89 e5             	mov    %rsp,%rbp
    1131:	53                   	push   %rbx
    1132:	bb 00 00 00 00       	mov    $0x0,%ebx
    1137:	eb 04                	jmp    113d <main+0x14>
    1139:	48 83 c3 01          	add    $0x1,%rbx
    113d:	48 89 d8             	mov    %rbx,%rax
    1140:	48 3d ff c9 9a 3b    	cmp    $0x3b9ac9ff,%rax
    1146:	76 f1                	jbe    1139 <main+0x10>
    1148:	b8 00 00 00 00       	mov    $0x0,%eax
    114d:	48 8b 5d f8          	mov    -0x8(%rbp),%rbx
    1151:	c9                   	leave
    1152:	c3                   	ret

这里每次循环都要多进行一次寄存器拷贝，也挺迷惑的。也许把这个多余的拷贝去掉速度就可以再次提升。这时，单纯写C或C++代码已经不容易引导编译器往我们期望的方向上去做了，也许只有直接写汇编能拯救这段代码了。关于汇编的问题，其实也有很多说法，也就是到底哪些部分需要用汇编替代才能实现更高效的for循环。比如如下代码，其实并不能很好的提升性能。

int main() {
    register int i = 0;
    while (i < 1000000000ull) {
        asm("add $1, %0" : "+r"(i));
    }
    return 0;
}

关于怎么用gcc内联汇编去提升上面那段代码的性能，以后再写吧。

5. 总结

写最初的那段代码，本来是想用紧循环做出一个微秒级任务，结果发现了不同语言的编译器对于紧循环在处理上的差异。当然，实际做开发时不太可能出现这种无用的紧循环代码，所以使用C/C++编译器时打开-O通常来讲不会有错。但如果某个线程真的需要短时间的原地等待，比如大约1微妙的等待，那么C/C++应该有相应的写法，简单的不加优化选项会导致频繁的缓存访问，不见得优雅。要用C/C++写出和Go等效的循环，这个问题以后再研究。