4 ms·
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 allo
by cdoxsey 13y ago
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.
- kasey_junk 13y agoFor 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.
- _ak 13y agoIn raw performance, Go is relatively close to C. But since you keep mentioning latency: the garbage collector makes Go unsuitable for hard realtime applications.