🤖nuanyangyang@nuanyangyang

“Go这个变态的语言…… 估计是为了避免Python那样，一个Python程序的执行效果和系统上装的package有关。go的做法就像强制所有程序都放到virtualenv里。 也有点像Java的classpath，Java程序执行的时候claspath上所有的包（除了标准库以外）都要明确指定。Go的做法就像Java一样…”

“【 在 Ykxpb 的大作中提到: 】 : 嘿嘿 先膜暖神~ : 哦哦 看文档是第一步咯？ 嗯嗯 明儿看起来~ : 不用直接上手什么小项目 边探究边学么？ : ................... 先学会爬才能学会走嘛。”

““读他妈的文档”。每个项目自己都有文档。那些开发了框架的人，自己肯定希望用户会用自己的框架吧。肯定会配有文档的。 比如spring： https://projects.spring.io/spring-framework/ 点进去，里面就有doc，地址就是 https://spring.io/docs 比如hibern…”

“不知道。那都是我的猜测。我并不完全清楚CPU的行为会如何。 但是我觉得既然已经到了这么细的粒度，基本上没什么好的办法测量性能了吧。毕竟CPU里指令并不是串行执行的。 【 在 wmzhere 的大作中提到: 】 : 如果中断的时候 ip 是 X，理论上不应该 X 当作正在执行的指令，而应该是上一条指令。 : 但是从方便处…”

“重新做了个实验。go也换用32位整数。下面是新的程序和时间。 package main import ( "fmt" "time" ) func isPrime(n int32) bool { var i int32 for i = 2; i < n; i++ { if n%i == 0 { return false …”

“【 在 wmzhere 的大作中提到: 】 : 主要是懒得开 fno-inline。最开始开 O3 了，然后 is_prime 被内联到 main 里面，读汇编更费劲一些。吐槽：AT&T 风格的汇编太难受了…… : 如果要 gcc 开 O3，还不如直接上 icc 呢，哈哈！ 重新实验了一下。换成int64_t以后就和g…”

“还有就是你的C++没有开优化。G++在没开优化的时候，局部变量都是真的写入内存的。看这些： │ mov %edi,-0x14(%rbp) │ movl $0x2,-0x4(%rbp) 10.71 │ e: mov -0x4(%rbp),%eax │ cmp -0x14(%rbp),%eax │ ↓ jge 30 0.0…”

“你用perf测量的吗？ perf的测量原理是每隔一段时间用信号中断进程一次，然后看每个栈。换句话说，就是“随机地中断进程，看它停在哪里”。这样注定了perf的测量精度只能达到几ms一个样本，这个频率实在是太低了。 而且，我对于“大量时间耗在对两个寄存器进行mov的指令上”非常怀疑。对于Ivy Bridge和以后的Int…”