Googles Go verkar vara ett riktigt grymt språk!

Go är definitivt ett riktigt trevligt språk. De som designade språket ville skapa något som har många av fördelarna från dynamiskt typade skriptspråk (duck-typing) men ändå är ett starkt- och statiskt-typat kompilerat språk för systemprogrammering (i.e. samma målgrupp som bl.a. C, C++, Java och C#).

Rob Pike, som är expert på concurrent-programming, brukar vara väldigt noga att påpeka att Go är ett språk designat för just concurrent-programming och inte för parallel-programming. Det är lätt att blanda ihop dessa två.

Concurrent-programming är ett sätt att strukturerar sitt program och det tenderar att fungera extremt väl i program med massiv I/O-last (back-end system). Concurrent-programming är definitivt väldigt användbart i enkeltrådade program och på system som bara har en CPU-tråd, så ett sådant program behöver inte alls exekverar parallellt.

Parallel-programming är i stället ett mål att maximera effekten av system med många CPU-kärnor, typiska användningsområden här är high-performance-computing. Visst kan man använda Go även här, men C, C++ och Fortran med tillägg som Cilk+ eller OpenMP är nog bättre val här. Visst kan man uttrycka instruktions-parallellism i Go (går även i C#4 och Java7), men i Cilk+ kan man även uttrycka data-parallellism vilket gör det väldigt enkelt för kompilatorn att använda sig av SSE/AVX (något som överhuvudtaget inte går i C# och Java för tillfället).

De som designade Go må jobba på Google, men det är inte ett språk som kontrolleras av Google då språk, kompilator och standardbibliotek är släppt under BSD-licens. D.v.s. man får göra precis vad man vill, inklusive stoppa in det i egna projekt som man inte gör OpenSource!

Just nu finns det två kompilatorer för Go, en med namnet "gc" som är den man hittar på den officiella sidan för språket Go. Den andra är gccgo som är en "front-end" till gcc. Gccgo kan enkelt installeras via pakethanteraren om man kör Ubuntu, Fedora eller liknande. Gccgo tenderar att generera binärer som presterar bättre än de binärer man får med gc om problemet är CPU-bundent, är problemet I/O-bundent spelar kompilatorn sällan någon större roll.

Även om de flesta som använder Go nog kör det på Linux så har "gc" kompilator även stöd för Windows, och stödet är faktiskt riktigt bra. I Windows NT kärnan finns det något som kallas I/O Completion Ports, en finess som gör det möjligt att utveckla I/O-intensiva program som skalar väldigt bra. Det går att använda denna finess även i .Net och Java6/7, men det används inte de funktioner som folk oftast kör med och att använda det leder till lite mer komplicerade program. I Go används det alltid utan att man ens behöver tänka på det!

Ett litet smakprov på hur man kan använda Go för att uttrycka instruktions-parallellism, lägger även med motsvarande funktion för C# och Java som jämförelse.

Go

package main

import (
        "runtime"
        "flag"
        "fmt"
)

const PARALLEL_THRESH = 30

func fib(n uint64) uint64 {
    if n < 2 {
        return n
    }
    return fib(n - 1) + fib(n - 2)
}

func parallelFib(n uint64) uint64 {
    if n < PARALLEL_THRESH {
        return fib(n)
    }
    n2Future := make(chan uint64)
    go func() {
        n2Future<- parallelFib(n - 2)
    }()
    return parallelFib(n - 1) + <-n2Future
}

func main() {
    c := flag.Int("c", 2, "Concurrency level")
    n := flag.Int("n", 30, "Argument to Fibonacci")
    flag.Parse()
    runtime.GOMAXPROCS(*c)
    fmt.Printf("fib(%v) = %v\n", *n, parallelFib(uint64(*n)))
}

Java

import java.util.concurrent.*;

public class Fib extends RecursiveTask<Long> {
    protected static final int THREADS = 8;
    protected static final int PARALLEL_THRESH = 30;

    final long n;
    long result;

    public Fib(long n) {
        this.n = n;
    }

    protected long computeSerial(long n) {
        if (n <= 1)
            return new Long(n);
        return computeSerial(n - 1) + computeSerial(n - 2);
    }

    protected Long compute() {
        if (n < PARALLEL_THRESH)
            return new Long(computeSerial(n));

        Fib f2 = new Fib(n - 2);
        f2.fork();
        return new Fib(n - 1).compute() + f2.join();
    }

    public static void main(String[] args) {
        if (args.length != 1) {
            System.err.println("Usage: Fib N");
            System.exit(1);
        }

        long n = Long.parseLong(args[0]);
        System.out.format("fib(%d) = %d\n",
                          n,
                          new ForkJoinPool(THREADS).invoke(new Fib(n)));
    }
}

C#

using System;
using System.Threading.Tasks;

class Program
{
    const ulong PARALLEL_THRESH = 30;

    public static ulong Fib(ulong n)
    {
        if (n < 2)
            return n;
        return Fib(n - 1) + Fib(n - 2);
    }

    public static ulong ParallelFib(ulong n)
    {
        if (n < PARALLEL_THRESH)
            return Fib(n);
        var taskN2 = Task.Factory.StartNew(() => ParallelFib(n - 2));
        return ParallelFib(n - 1) + taskN2.Result;
    }

    public static void Main(string[] args)
    {
        const ulong N = 47;
        Console.WriteLine("fib({0}) = {1}", N, ParallelFib(N));
    }
}

Detta är ett väldigt ineffektivt sätt att beräkna Fibonacci, men det är populärt ändå. Dels är det en direktöversättning av den matematiska definitionen, dels så är det ett enkelt exempel som innehåller massor med potentiellt instruktions-parallellism vilket gör det till en bra "show off" för dessa finesser.

På Win8 (laptop med i7-2760QM, 4 kärnor med HT) får man följande resultat av att köra detta:
Fallet med 2(HT) är när jag begränsat programmet till att köra på samma CPU-kärna men på båda CPU-trådarna.

Windows 8 Go fib(47)
CPUs    Elapsed Speedup
1       24.825  x1.00
2(HT)   19.371  x1.28
2       12.740  x1.95
3       8.640   x2.87
4       6.915   x3.59
8       6.118   x4.06

Windows 8 C# (VS2012) fib(47)
CPUs    Elapsed Speedup
1       34.939  x1.00
2(HT)   32.002  x1.09
2       17.657  x1.98
3       12.532  x2.79
4       10.204  x3.42
8       9.141   x3.82

Windows 8 Java (JDK7) fib(47)
CPUs    Elapsed Speedup
1       13.704  x1.00
2(HT)   12.157  x1.13
2       6.954   x1.97
3       4.891   x2.80
4       3.719   x3.68
8       3.500   x3.92

Java7 är snabbast men Go skalar bäst från 1 CPU-tråd till 8 CPU-trådar. Lite förvånande att Microsoft eget språk körandes på deras eget OS är klart långsammast och skalar även sämst...

Då detta är väldigt "snällt" vad det gäller parallellism så skalar det väl, här är resultatet på en Linux server med 4st 8-kärniga Xeons (totalt 32-kärnor och 64-trådar)

4x 8-core Xeon

Ubuntu 12.04 Java7 (OpenJDK)  fib(50)
CPUs    Elapsed Speedup
1       59.084  x1.00
8       7.783   x7.59
32      2.319   x25.5
64      2.091   x28.3


Ubuntu 12.04 Go 1.1.1  fib(50)
CPUs    Elapsed Speedup
1       112.502 x1.00
8       14.390  x7.82
32      4.393   x25.6
64      3.058   x36.8


Ubuntu 12.04 gccgo 4.7  fib(50)
CPUs    Elapsed Speedup
1       45.805  x1.00
8       6.076   x7.54
32      2.004   x22.8
64      1.569   x29.2

Även på Linux är Java7 snabbare än "gc" 1.1.1, men här hade jag även gccgo 4.7 installerat och det skalar ungefär som Java7 men lite mer än 30% snabbare! Inte så illa med tanke på att Java har optimerats under 20 års tid och Go släpptes officiellt våren 2012!

Och detta är på CPU-bundna saker, något som designerna av Go specifikt säger inte är huvudmålet med språket. Har skrivit en del nätverks-intensiva saker i Go och det har typiskt varit 10-100 gånger snabbare än motsvarande program skrivet i Java eller C++. Motsvarande i bemärkelsen: så som en expert i respektive språk skulle välja att skriva, jag vet hur Go är implementerat "under huven" och rent teoretiskt skulle jag kunna skriva ett C/C++ (och det borde även vara möjligt i Java med NIO) som beter på samma sätt. Grejen är att det är väldigt lätt att skriva ett sådan program i Go, det skulle vara extremt svårt att följa logiken i ett C/C++/Java program som, sett från OS:et, fungerar på samma sätt.