为啥写

Go的汇编一直是我感兴趣的地方，为了验证之前所学的汇编知识和好玩 ，我决定往Go官方提交一个性能patch。
所以到官方的标准库里搜了一圈，发现adler32并没有硬件加速的实现，而Intel已经公布了相关的SSE加速实现
https://github.com/01org/isa-l/

所以我决定把Intel的抄过来，结果不停地掉坑和爬出来，终于提交了patch（撒花）

https://go-review.googlesource.com/c/51850

希望在Go 1.10发布的时候能进入官方源：）

坑

1. 写法的区别
2. Go汇编不支持
3. 难以调试
4. 内存越界与LEA
5. 向官方提交代码需要注意的地方，保证Change ID一致

坑一：Intel和AT&T的写法的区别

Intel写法是：
opcode destination source

AT&T 也就是Go官方汇编语言的写法正好是反过来的：
opcode destination source

抄代码的时候有点绕

坑二 Go汇编不支持：

Go的维护者们对于新添加汇编opcode一直是很保守的，比如2001年前后就有的SSE2 里的PSHLLW（）竟然不支持（= =||）。
所以得自己填BYTE，比如官方文档中的MOVQ用BYTE方式编写 https://golang.org/doc/asm

BYTE $0x0f; BYTE $0x6f; BYTE $0x00 // MOVQ (AX), M0

但这里就有一个坑，比如PSHLLD和PSHRQ的Opcode是一样的……只是按/r 寄存器类型进行区别。需要注意

坑三：调试困难

一般代码测试时，都可以直接输出日志，帮助定位问题，但是汇编不行，所以我是通过把需要的值放入某个不用的寄存器， 例如

#define debug R15
// min(a, b int) int
TEXT min(SB), NOSPLIT, $0

在需要的时候，提前把函数返回

MOVQ debug, ret+16(FP)
RET

当然应该有更好的方法，可以把所有寄存器打印出来，不过这个方法够我自己调试用了。

坑四：内存越界与LEA

一般程序中都是指针，或者直接结构体。不过，汇编这里回归本真，只有内存地址和寄存器。所以一定要小心访问数据的边界和跳转的内存地址。
这里学到了一个LEA的用法，地址计算器，把内存地址到目标寄存器里。

LEAQ 0(data)(size*1), end

具体用法

• 0: 写死的偏移量
• data: 偏移值
• size: 动态偏移量，可以用乘法

坑五：

提交代码到gerrit要保持Change ID相同，要不然算一个新的Change。

附录：opcode坑

• MOVOU： O=oct， U=unaligned， 指的是八个word，即128位，用于XXM寄存器的移动。
• TESTQ： 对比值，并影响FLAG
• DIVL：低位除，如果高位有数据就会出错

资料：
Go官方介绍： https://golang.org/doc/asm

本文已授权腾讯公司转载：https://www.zhihu.com/question/293021546

简单的说，什么都看不到。

为了简化，我们只说微信群。

根据2014年腾讯的公开数据 1

微信和WeChat月活跃账户4.68亿，90亿条日均消息

如果全国人民在同一个群里说话，每天就是
14E8 x (90 / 4.68) = 2.6E10 条

考虑到大家一般除了睡觉8小时外，而且仅仅匀速发送的话，那就是
(14E8 x (90 / 4.68))/(86400 - 8x3600) =

467414条每秒

目前主频最高的手机CPU，高通骁龙805(APQ8084)2 有2.7GHz的处理能力，一共是4核，如不计算操作系统、显示刷新、网络IO等CPU操作的话
每条信息能分配到 2.7GHz x 4 / 467414 =

23KHz

仅仅相当于生产于1951年的第一台真空管计算机Whirlwind 3的计算能力，自然手机的CPU是处理不了这么大的数据量的。
幸好IT界有个摩尔定律，每18个月CPU性能就能翻倍（或者价钱是一半），假设等到了2025摩尔定律失效时，我们的手机应该有
2e((2025-2017)x12/18) x 2.7 = 108Ghz

看起来不错嘛，不过每条消息才能消费108GHz x4 / 467414 =

931KHz

差不多是1972年的Intel 8008 800KHz4 的水平，结果就是你等了7年，还是进不了这个全国群抢一个红包

假设我们每个人都获得了能处理消息能力的手机 5（比如说全球超算第一名的太湖之光，1千万个CPU核心）来帮忙处理微信群。
由于微信没有公布数据，因此我们只好假设平均每条消息有10个汉字，这大概相当于30 byte，算上应用层会加上一定的控制字符，再加上TCP／IP网络层的数据消耗大概是74 byte，取个整，平均每条消息有100 byte。
这时每秒数据流量是(100x8)x467414 =

373Mbps

理论上的4G网络，能支持1000Mbps6，但别忘了，是全国人民在同一个群里，很快你周围的人也接近了这个流量，这使得你所在的基站不堪重负，陷入瘫痪。
为了避免网络瘫痪导致你抢不到红包或者看群消息，你需要搬到一个周围没有人的基站，因此人口密度最低的西藏省是个不错的选择。
不过运营商的日子就不好过了，因为全国上下的流量达到了惊人的每秒373Mbps x 14E8 = 5.2E17 bps =

52 Pbps

相当于全国4月份的移动数据总流量的3%，意味着6分钟就能用完全国一年的流量 7，或者把52PB数据用2T 3.5英寸硬盘装起来，然后叠起来，有130m高

当然，我相信我们抠门的国有运营商肯定会砸下重金为你建设全世界最大的宽带网络，毕竟是为了国家建设全国群，同时，好让你快乐地抢红包。

不过，接下来该花钱的就不是国有企业——腾讯。

为了处理每个人的373Mbps流量，现有的万兆交换机仅仅能支撑26个人，也就是说腾讯至少需要1346万台4口万兆交换机，目前华为4口万兆交换机售价是3927元每台，一共需要支出

1346x10000x3927 = 52,857,420,000 元

一台便宜的2U服务器则需要10000元

1346x10000x10000 = 134,600,000,000 元

仅仅这两项就相当于腾讯CEO马化腾持有的股票 9 市值10了

而仅仅是把这些2U服务器叠起来就有88.9x1.346E7=1196594000mm

1196km

国际空间站的轨道高度才340km

这下，你终于可以愉快地进了群。

但你惊讶地发现，屏幕上除了绿色，什么都没有……

这是因为你的眼睛没办法接收这么快的数据。
而人眼的视觉暂留时间是100-400ms11 ，我们这个群消息停留的时间只有0.002ms，相比之下，电影、电视有41ms。
因此你还没来得及看清消息，它就已经消失了，最后只留下一团绿色的色块在屏幕的正中央。

实现了学生T分布之后，有趣的是，在集群中使用时发现sntpd的偏移量变化非常有规律

最后我确认是两个问题引起的：

1. s.poll 的区间设置得过长，时钟一旦偏移，要花很长的时间去校正
2. 由于95%置信区间的设定，导致时钟源总是变化，因此总有跳变

读了一次论文之后，发现，DLM博士早就知道这事，而且在论文中也指出了这种只使用offset的方法是他们的第一版算法……但是发现由于时钟dispersion（误差）的存在，导致时钟offset不一定准确，会丢掉误差的数值，所以他们使用了Marzullo算法。

https://en.wikipedia.org/wiki/Marzullo%27s_algorithm

看着很复杂，但是主要思想却相当简单，就是先假设所有的区间都是“好区间”，把区间值按大小排序，得出最多的夹杂着最少最大值的区间，然后在反向求最多的夹杂着最少最小值的区间。如果得不出，就缩减窗口项，好区间=所有区间减一，直到找到为止。

以下是我的Go实现

# iset 即区间拆分之后的数值
func (s *Service) marzullo(iset []Interset) (surviors []*Peer) {
sort.Sort(byOffset(iset))
nlist := len(iset) / 2
nl2 := len(iset)
var n int
low := time.Hour
high := -time.Hour
for allow := 0; 2*allow < nlist; allow++ {
n = 0
for _, set := range iset {
low = set.val
n -= set.typE
if n >= nlist-allow {
break
}
}
n = 0
for j := nl2 - 1; j > 0; j-- {
high = iset[j].val
n += iset[j].typE
if n >= nlist-allow {
break
}
}
if high > low {
break
}
}
var p *Peer
for i := 0; i < len(iset); i += 2 {
p = iset[i].peer
if high <= low || p.offset+p.rootDistance < low || p.offset-p.rootDistance > high {
continue
}
surviors = append(surviors, p)
}
return
}

最近在实现sntpd的时间选取，但是遇到了一个问题，怎么查询到集群里“合适”的机器，一开始我只是用delay最低的，但是这样并不是最好的，而RFC5905里的实现太复杂了，这样的话，我就需要一个“滤波器”，但是样本实在太少了，学过统计学的就知道，样本要大于30才算好，但是，查询太多的机器很影响性能，所以样本一般低于5个。因此一番搜索之后，发现“学生T分布”是最好的选择：小样本估计置信区间。

那正态分布呢？因为我们知道，生物过程或者其他变量过多样本都符合正态分布，而学生T分布就是对正态分布的估算。回到ntp的问题，ntp影响的因素有太多了，网络拥塞，时钟抖动，时钟偏移等等，其实，跟网络打上交道，因素就已经够多了。

所以这个条件下，给sntpd安上一个学生T分布滤波器就很好了：）

首先要选个置信度，我只是要排除非法值，所以95%是个很好的选择。
根据公式

Wiki-学生T分布

计算样本均值，样本标准差，自由度（样本数-1），再按表格查询，就知道置信区间了，这样就大于或者小于置信区间的值，就可以当作非法值去掉了。

• CPU: Intel(R) Core(TM) i7-4790 CPU @ 3.60GHz (AVX2\AVX)
• HOST OS: Windows 7
• Guest: Ubuntu 16.04.1 LTS 64 bit

In Host (which Dev is my VM name)

C:\Program Files\Oracle\VirtualBox>VBoxManage.exe setextradata "Dev" VBoxInternal/CPUM/IsaExts/AVX2 1

Check by:

C:\Program Files\Oracle\VirtualBox>VBoxManage.exe getextradata "Dev" enumerate
Key: GUI/Fullscreen, Value: true
Key: GUI/LastCloseAction, Value: SaveState
Key: GUI/LastGuestSizeHint, Value: 1920,995
Key: GUI/LastNormalWindowPosition, Value: 26,30,944,394,max
Key: GUI/LastScaleWindowPosition, Value: 8,30,1272,928
Key: GUI/RestrictedRuntimeDevicesMenuActions, Value: HardDrives
Key: GUI/RestrictedRuntimeMachineMenuActions, Value: SaveState,PowerOff
Key: GUI/ScaleFactor, Value: 1
Key: GUI/StatusBar/Enabled, Value: false
Key: GUI/StatusBar/IndicatorOrder, Value: HardDisks,OpticalDisks,FloppyDisks,Net
work,USB,SharedFolders,Display,VideoCapture,Features,Mouse,Keyboard
Key: VBoxInternal/CPUM/IsaExts/AVX2, Value: 1

Restart your VM and bingo!