洛桑联邦理工学院(EPFL)发布了一个新的网站http://www.scala-native.org/，他们宣布了一个新的项目 Scala Native,但是没有公布具体的内容，只有"coming soon"的提示， 但是网站上唯一的提示 "Your favourite language gets closer to bare metal." 隐约透漏它可能是可以使用Scala编程语言编译成本机代码的项目。

Scala除了纵向发展外(Scala本身语言的扩展)， 也在横向的发展， 比如Scala.js将Scala语言引入到Javascript中，它可以将Scala语言编译成javascript。因此有理由相信，这个即将发布的项目可以将Scala代码编译成本机代码，这样就可以脱离虚拟机直接运行了。

阅读全文

在visual studio code 1.0发布之前我也曾多次尝试使用visual studio code开发Go程序，但是都放弃了，一是Go的插件还没发布或者不完善，而是vscode还不是那么方便，所以我一直使用atom + goplus + godebug编写Go的代码，而且用起来也非常的顺手方便。 现在vscode 1.0发布了，而且支持10种本地化语言，我尝试使用它编写Go程序，功能和性能都不错，所以目前atom和vscode都是我的菜。

本文简单介绍一下使用vscode开发Go的一些配置，速览vscode + Go 的功能。

阅读全文

这是William Kennedy写的第二篇文章： Scheduler Tracing In Go, 第一篇为 Stack Traces In Go。

本文主要介绍如何跟踪Go的调度器Scheduler的活动。

阅读全文

William Kennedy写了两篇关于Go 调试的文章，非常不错，特意翻译了一下，加深记忆。本文是其中的一篇： Stack Traces In Go。 另一篇是 Scheduler Tracing In Go。

Stack Trace表示堆栈跟踪，这是一个或多个堆栈帧的有序的集合。在程序出现panic的时候你会看到控制台有Stack Trace信息打印出来。

阅读全文

Channel是Go中的一个核心类型，你可以把它看成一个管道，通过它并发核心单元就可以发送或者接收数据进行通讯(communication)。

它的操作符是箭头 <- 。

1
2

ch <- v    // 发送值v到Channel ch中
v := <-ch  // 从Channel ch中接收数据，并将数据赋值给v

(箭头的指向就是数据的流向)

就像 map 和 slice 数据类型一样, channel必须先创建再使用:

1

ch := make(chan int)

阅读全文

Go泛型特性已经被讨论了多次了¹, Andrew Gerrand现在把这个提案加入到了Go的issue列表中²，并标记为Go2标签。当然这不代表着要将泛型加入到Go中,而是演示一个完整的提案应该是什么样子。

阅读全文

其它语言中Future和Promise的概念大量存在， 比如Node.js、Scala、Java、C#、C++ 11、Scheme、Swift等，可以方便的实现异步执行和回调。但是在Go语言的世界里，我们是通过goroutine/channel实现这种类似的功能呢，goroutine之间可以通过channel进行通讯， 但是，如果我们还是想使用Future/Promise的功能的话，该如何实现呢？

Future，Promise或Delay是用于并发编程的一种设计模式。它们表示一个对象，这个对象用来作为一次计算结果的代理，而该结果开始的时候是未知的，因为计算还没有完成。Promise与Future的区别在于，Future是Promise的一个只读的视图，也就是说Future没有设置任务结果的方法，只能获取任务执行结果或者为Future添加回调函数。

阅读全文

阿姆达尔定律（英语：Amdahl's law，Amdahl's argument），一个计算机科学界的经验法则，因吉恩·阿姆达尔(Gene Amdahl)而得名。它代表了处理器平行运算之后效率提升的能力。

1967年计算机体系结构专家吉恩.阿姆达尔提出过一个定律阿姆达尔定律，说：在并行计算中用多处理器的应用加速受限于程序所需的串行时间百分比。譬如说，你的程序50%是串行的，其他一半可以并行，那么，最大的加速比就是2。不管你用多少处理器并行，这个加速比不可能提高。在这种情况下，改进串行算法可能比多核处理器并行更有效。

阅读全文

我们在监测Linux的应用的时候，当CPU的利用率非常高，但是系统的性能却上不去的时候，不妨监控一下线程/进程的切换，看看是不是context switching导致的overhead过高。

一般我使用dstat工具用来监控，比如dstat -y:

1
2
3
4
5

---system--
 int   csw 
 367   561 
 274   439 
 279   363

或者vmstat 3:

1
2
3
4

[root@abc smallnest]# vmstat 3
procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 0  0      0 3126192  31692 1521612  0    0   176   325  166  258  1  1 96  3  0

但是如何知道那些进程/线程做切换能，淘宝褚霸有篇文章:latencytop深度了解你的Linux系统的延迟介绍了一种方法。事实上，有一个工具pidstat,可以用来监控上下文切换。 它是sysstat包其中的一个工具，sysstat包含好几个很棒的工具，比如sar、iostat等。

执行pidstat -w

1
2
3
4
5
6
7
8
9
10
11
12
13
14

root@abc smallnest]# pidstat -w
Linux 2.6.32-358.el6.x86_64 (abc) 	04/11/2016 	_x86_64_	(2 CPU)
11:25:00 PM       PID   cswch/s nvcswch/s  Command
11:25:00 PM         1      0.60      0.03  init
11:25:00 PM         2      0.04      0.00  kthreadd
11:25:00 PM         3      0.36      0.00  migration/0
11:25:00 PM         4      0.58      0.00  ksoftirqd/0
11:25:00 PM         5      0.01      0.00  migration/0
11:25:00 PM         6      0.08      0.00  watchdog/0
11:25:00 PM         7      0.39      0.00  migration/1
11:25:00 PM         8      0.01      0.00  migration/1
11:25:00 PM         9      0.52      0.00  ksoftirqd/1
……

cswch/s是主动地上下文切换，nvcswch/s是被动执行上下文切换的次数。

如要要显示线程的上下文切换统计，可以执行:

1
2
3
4
5
6
7
8
9
10
11
12
13
14

[root@abc smallnest]# pidstat -wt
Linux 2.6.32-358.el6.x86_64 (abc) 	04/11/2016 	_x86_64_	(2 CPU)
11:27:57 PM      TGID       TID   cswch/s nvcswch/s  Command
11:27:57 PM         1         -      0.56      0.03  init
11:27:57 PM         -         1      0.56      0.03  |__init
11:27:57 PM         2         -      0.03      0.00  kthreadd
11:27:57 PM         -         2      0.03      0.00  |__kthreadd
11:27:57 PM         3         -      0.34      0.00  migration/0
11:27:57 PM         -         3      0.34      0.00  |__migration/0
11:27:57 PM         4         -      0.57      0.00  ksoftirqd/0
11:27:57 PM         -         4      0.57      0.00  |__ksoftirqd/0
11:27:57 PM         5         -      0.01      0.00  migration/0
……

更多的参数可以man pidstat获得。

前几天我写了一篇文章: 超全的Go Http路由框架性能比较，利用Julien Schmidt实现的benchmark测试框架对几乎所有的go web框架的路由功能进行了比较。我本来以为对Go web框架的性能考察就告以段落了，直到我写了一段简单的代码测试Irsi，用来模拟实际产品中的处理，才发现了Julien Schmidt测试框架的问题。

这段代码是这样的：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

package main
import (
	"fmt"
	"os"
	"strconv"
	"time"
    "github.com/kataras/iris"
)
func main() {
	api := iris.New()
	api.Get("/rest/hello", func(c *iris.Context) {
		sleepTime, _ := strconv.Atoi(os.Args[1])
		if sleepTime > 0 {
			time.Sleep(time.Duration(sleepTime) * time.Millisecond)
		}
		c.Text("Hello world")
	})
	api.Listen(":8080")
}

当我将实际业务的处理时间模拟为10毫秒的时候，使用100并发进行测试：
wrk -t16 -c100 -d30s http://127.0.0.1:8080/rest/hello，Iris吞吐率才达到97 requests/second。详细介绍可以看我的文章： iris 真的是最快的Golang 路由框架吗? 。

虽然Iris的作者很快做了修改，临时解决了这个问题，但是也促使我重新审视Julien Schmidt测试框架,也促使我实现了一个测试Go web framework benchmak的框架： Go web framework benchmark。

2016/04/12 updated: 现在Iris已经改成了fasthttp实现，性能超级好。

阅读全文