Allocation Efficiency in High-Performance Go Services | Hacker News Reader

Allocation Efficiency in High-Performance Go Services

segment.com

106 pointsmrbbk13 comments

When you need to start worrying about memory allocation control, garbage collection latency, pointers, byte padding, and CPU instructions per operation, Go might be not be the best tool for the job anymore. Seems like Rust might be a better choice here? Instead of reverse engineering what the compiler might do, then structuring the code in subtle ways to get the compiler to actually do what you intend to do, why not pick a language that lets you command the compiler do to what you want?

We've invested a lot in Go at Segment and introducing a new language isn't cost-free, building the expertise, tools, and processes to work with a new technology takes time and energy. It's way more time efficient for us to learn how to build better Go code. While this post focuses on the optimizations, this is only part of the development process, and Go is still an amazing tool to design, implement, and test software, and on top of that it gives us the ability to address those performance issues when they come up.

Garbage collection simplifies but does not eliminate memory management. That's okay, because even though it does not eliminate the need for memory management completely, it does still save the programmer from an awful lot of work.

Anyway, the choice of Rust vs Go should not be based on a single factor like "Rust is not garbage collected". Especially since many common coding patterns require some form of garbage collection, even in Rust!

I love the work they are doing in regards to low level systems coding and safety, but in general a GC + ability to statically allocate feels more productive, specially as former Oberon user and Modula-3 fan.

Languages like Eiffel, Modula-3, Active Oberon, Sing#, System C#, D are good examples on how to have GC productivity and control over memory allocation.

What Go lacks is the ability to explicit state that a value must live in the stack, leaving it implicit and open to escapes.

Using the first example in D, x will definitely be stack allocated.

    import std.stdio;

    void main()
    {
        auto x = 42;
        writeln(x);
    }

What happens if you take the address of x in that example, and store it in some data-structure that is on the heap?

Would that be a recipe for a "segfault"? Do all these languages allow segfaults to happen?

At least in Oberon there is no "address of" operator.

Sure there is.

    MODULE Crash;
    IMPORT SYSTEM;
    VAR
      source: LONGINT;
      sourceAddress: INTEGER
      source2: LONGINT;

    BEGIN
      source := 23;
      sourceAddress := SYSTEM.ADR(source);
      SYSTEM.GET(sourceAddress, source2);
      (* .... *)
    END Crash.

The issue is that any module that imports SYSTEM is considered unsafe by the compiler.

Yes, that can happen.

However in some of those languages those type of assignments are only allowed in unsafe code, for example in Modula-3 you can only do that in an unsafe module package and the target variable has to be declared as UNTRACED REF.

The interface problem seems like something the compiler team should fix or mitigate. I worry this post is going to cause a lot of premature restrictionism.

I agree, there's area for improvement for the compiler here and hopefully in the future we won't have to worry about those issues. For now those are constraints we have to deal with to make our software more efficient unfortunately.

I noticed there's a go:noescape compiler directive that seems to provide an escape hatch for a lot of this unexpected compiler behaviour:

https://golang.org/cmd/compile/#hdr-Compiler_Directives

Does that actually work?

go:noescape is meant to be used on functions that are implemented in assembly because escape analysis only works on Go code. As far as I know a etting this tag on a function that is implemented in Go has no effect.

Reply on news.ycombinator.com