【发布时间】：2012-04-18 12:14:00
【问题描述】：
我在玩 Go 语言并发，发现了一些对我来说有点不透明的东西。
我写了并行矩阵乘法，即每个任务计算单行乘积矩阵，将源矩阵的对应行和列相乘。
这是Java程序
public static double[][] parallelMultiply(int nthreads, final double[][] m1, final double[][] m2) {
final int n = m1.length, m = m1[0].length, l = m2[0].length;
assert m1[0].length == m2.length;
double[][] r = new double[n][];
ExecutorService e = Executors.newFixedThreadPool(nthreads);
List<Future<double[]>> results = new LinkedList<Future<double[]>>();
for (int ii = 0; ii < n; ++ii) {
final int i = ii;
Future<double[]> result = e.submit(new Callable<double[]>() {
public double[] call() throws Exception {
double[] row = new double[l];
for (int j = 0; j < l; ++j) {
for (int k = 0; k < m; ++k) {
row[j] += m1[i][k]*m2[k][j];
}
}
return row;
}
});
results.add(result);
}
try {
e.shutdown();
e.awaitTermination(1, TimeUnit.HOURS);
int i = 0;
for (Future<double[]> result : results) {
r[i] = result.get();
++i;
}
} catch (Exception ex) {
ex.printStackTrace();
return null;
}
return r;
}
这是 Go 程序
type Matrix struct {
n, m int
data [][]float64
}
func New(n, m int) *Matrix {
data := make([][]float64, n)
for i, _ := range data {
data[i] = make([]float64, m)
}
return &Matrix{n, m, data}
}
func (m *Matrix) Get(i, j int) float64 {
return m.data[i][j]
}
func (m *Matrix) Set(i, j int, v float64) {
m.data[i][j] = v
}
func MultiplyParallel(m1, m2 *Matrix) *Matrix {
r := New(m1.n, m2.m)
c := make(chan interface{}, m1.n)
for i := 0; i < m1.n; i++ {
go func(i int) {
innerLoop(r, m1, m2, i)
c <- nil
}(i)
}
for i := 0; i < m1.n; i++ {
<-c
}
return r
}
func innerLoop(r, m1, m2 *Matrix, i int) {
for j := 0; j < m2.m; j++ {
s := 0.0
for k := 0; k < m1.m; k++ {
s = s + m1.Get(i, k) * m2.Get(k, j)
}
r.Set(i, j, s)
}
}
当我使用 nthreads=1 和 nthreads=2 的 Java 程序时，我的双核 N450 Atom 上网本的速度几乎提高了一倍。 当我使用 GOMAXPROCS=1 和 GOMAXPROCS=2 的 Go 程序时，根本没有加速！
尽管 Java 代码为 Futures 使用了额外的存储空间，然后将它们的值收集到结果矩阵中，而不是在工作代码中直接更新数组（Go 版本就是这样做的），它执行很多 在几个核心上比 Go 版本更快。
特别有趣的是，GOMAXPROCS=2 的 Go 版本会加载两个内核（htop 在程序运行时显示两个处理器上 100% 的负载），但计算时间与 GOMAXPROCS=1 相同（htop 仅显示 100% 的负载在这种情况下在一个核心上）。
另一个问题是，即使在简单的单线程乘法中，Java 程序也比 Go 程序更快，但这并不完全出乎意料（考虑到来自 here 的基准测试）并且不应该影响多核性能倍增器。
我在这里做错了什么？有没有办法加速 Go 程序？
更新：
看来我发现我做错了什么。我使用System.currentTimeMillis() 检查java 程序的时间，使用time shell 命令检查Go 程序的时间。我错误地将 zsh 输出中的“用户”时间作为程序工作时间而不是“总”时间。现在我再次检查了计算速度，它也给了我几乎两倍的加速（虽然它比 Java 的要小一些）：
% time env GOMAXPROCS=2 ./4-2-go -n 500 -q
env GOMAXPROCS=2 ./4-2-go -n 500 -q 22,34s user 0,04s system 99% cpu 22,483 total
% time env GOMAXPROCS=2 ./4-2-go -n 500 -q -p
env GOMAXPROCS=2 ./4-2-go -n 500 -q -p 24,09s user 0,10s system 184% cpu 13,080 total
看来我得更专心了。
Java 程序在相同的情况下给出的次数要少五次。但我认为这是另一个问题。
【问题讨论】：
-
我编译并运行了您的代码，但没有观察到这一点。相反，对于 1000x1000 矩阵的单次乘法，我看到了预期的加速。你应该发布一个完整的程序并详细说明你是如何计时的。
-
感谢您的回答。请在问题中查看我的更新。
标签： java multithreading performance parallel-processing go