Hacker News Reader

Comment by kasey_junk | Hacker News Reader

This article uses the term "realtime" and then discusses latencies in seconds and tens of milliseconds. It further says that Go approaches C in terms of speed. Can Go actually achieve C latency which is an order of magnitude faster than this, or is that hyperbole?

How does GC impact that? What about C to Go inter-op. Is there a latency penalty?

View on HN

Yes the GC has a large impact on this and yes C to Go inter-op has a heavy penalty. Memcachier did a talk at a Go meetup where they discussed a custom slab allocator they built to workaround some of these problems.

Like C, Go is compiled to a native binary. Certainly something like GCC will tend to produce faster code, but there's nothing fundamental here preventing you from writing code that can run fast in Go.

The real question isn't "can go achieve C latency" but rather "will every-day code written in Go achieve the same latency as every-day code written in C". And the answer is probably: it'll be slower, though usually in the same ballpark, but it will be easier to write, easier to maintain and have fewer bugs.

For me it is a very real question of whether "can Go achieve C latency" because if I'm going to deploy a Go application it is going to be to replace very performance critical components that are currently written in C. If they weren't latency sensitive neither C nor Go would be my choice (I'd go higher up the abstraction hierarchy to make it easier to write, easier to maintain etc).

If Go can't do that (or can't do that yet) it's fine by me, I'll just let it bake a few more years and reassess, but there have been tons of articles lately talking about how great Go's performance is. I'm just curious if that is an artifact of the original languages being compared to, or if it has broken through to C levels of latency. If it has, it becomes a lot more interesting to me.

In raw performance, Go is relatively close to C. But since you keep mentioning latency: the garbage collector makes Go unsuitable for hard realtime applications.

Well, according to the benchmark game Go tends to be about 3 times slower than C on tight, highly optomized benchmarks[1]. Python tends to be 40 times slower than C[2]. Those, of course, might not be representative of your tasks, or the optimization effort you're putting in.

[1]http://benchmarksgame.alioth.debian.org/u32/go.php

These benchmarks seems to rely heavily on math operations and the Go bench seems compiled with gc. I suspect that gccgo with the latest runtime (There was no release of gcc with the 1.1 runtime yet) can show prettier results with the use of the more mature gcc optimisations.

If you need hard realtime, go is not an appropriate solution. For a start you should expect occasional GC pauses on the order of tens of milliseconds, with no upper bound if you're using a lot of memory.

That said, go actually can come close to C on sustained throughput. (On some benchmarks, naive go programs beat naive C, but usually go is somewhat slower.) You can interoperate with C using cgo, and there is no penalty. (It may not work with all go compilers.) If you want to interoperate with C++ then see http://www.swig.org/Doc2.0/Go.html for the best solution. I believe that there is a performance penalty there.

> This article uses the term "realtime"

http://en.wikipedia.org/wiki/Real-time_web "The real-time web is fundamentally different from real-time computing"

This is true. :) Our definition of "realtime" is slightly different than a CS definition. Sub-1s end to end time usually falls under "realtime" when it comes to the web, but it depends on what the subject is of course. In our case, that's perfectly acceptable. We're obviously shooting for lower, but at this point, we can't do much to improve network latency and other factors involved. So for now... this is good. :)

Most of the latency involves other components in our system. This isn't just computational time. Most of the actual computation with our transformers and whatnot are done in less than 1ms.

Are you referring to the cgo stuff?

I was very curious about the claim that Go approached C speeds. I've not seen those claims before and the latencies cited certainly don't back that up.

C inter-op speed would be a big part of any such claims as any systems language would need to support that.

Well, the latency referred to is not factor of the Go code. It's more of a factor of our nginx front end which are handling a few million concurrent connections. The time spent doing computation is being measured in nanoseconds.

Reply on news.ycombinator.com