Saving a Third of Our Memory by Re-Ordering Go Struct Fields (2020)

Re:Saving a Third of Our Memory by Re-Ordering Go Struct Fie... by pjmlp on Monday January 10, 2022 @02:01AM (#29871480)

Doing it automatically messes up ABI and binary libraries infrastructure.

There is more to it than lazy language designers.

[ Parent | on HN ]

Re:Saving a Third of Our Memory by Re-Ordering Go Struct Fie... by masklinn on Monday January 10, 2022 @03:55AM (#29872096)

> Doing it automatically messes up ABI and binary libraries infrastructure.

Neither is an issue in Go, since everything’s statically compiled and it doesn’t make any ABI guarantee.

Making this opt-out (or making precise layout opt-in) actually improves the situation there, because then you have clear, explicit guarantees.

[ Parent | on HN ]

Re:Saving a Third of Our Memory by Re-Ordering Go Struct Fie... by pjmlp on Monday January 10, 2022 @04:00AM (#29872125)

Apparently people keep missing the news that Go nowadays also does dynamic linking.

[ Parent | on HN ]

Re:Saving a Third of Our Memory by Re-Ordering Go Struct Fie... by Joker_vD on Monday January 10, 2022 @04:43AM (#29872441)

It does? Could you please point to a good introduction/summary? I am actually quite interested to see how they manage the ABI compatibility compared to e.g. Swift.

[ Parent | on HN ]

Re:Saving a Third of Our Memory by Re-Ordering Go Struct Fie... by pjmlp on Monday January 10, 2022 @05:54AM (#29872947)

Swift is one of the few AOT compiled languages where they went the extra mile to ensure some kind of ABI compatibility across language versions, Go just did the usual stuff and no guarantees are given.

As for the documentation,

Check -dynlink and -shared on "go compile"

https://pkg.go.dev/cmd/[email protected]

Also -buildmode and -shared on "go link"

https://pkg.go.dev/cmd/link#hdr-Command_Line

You can either create a dynamic linked package, that will dynamically link with other Go compiled code (from same toolchain), or expose a C ABI from a Go compiled .so (which may or may not include the runtime as well).

As for one possible example,

https://www.ardanlabs.com/blog/2020/07/extending-python-with...

[ Parent | on HN ]

Re:Saving a Third of Our Memory by Re-Ordering Go Struct Fie... by Joker_vD on Monday January 10, 2022 @06:19AM (#29873136)

Huh. So it's basically undocumented w.r.t. the actual implementation details, I was mostly interested in how they manage to bolt interfaces onto structs when they're separately compiled: e.g. if libFoo.so has "struct Foo {}" and "func (x Foo) Frob() { ... }" in it, and if libFrob.so has "interface Frobber { func Frob() }", and then they're linked together to the main application, will Foo actually implement Frobber? If yes, how?

[ Parent | on HN ]

Re:Saving a Third of Our Memory by Re-Ordering Go Struct Fie... by pjmlp on Monday January 10, 2022 @01:33PM (#29879273)

I guess that is the whole point of not having a stable ABI, you also won't find much documentation how C++ compilers do it, beyond reading the code.

[ Parent | on HN ]

Re:Saving a Third of Our Memory by Re-Ordering Go Struct Fie... by fulafel on Monday January 10, 2022 @02:48AM (#29871719)

Yes, JIT runtimes have an easier time here (and can more easily do feedback based optimizations on access patterns). For AOT you can do LTO / whole program opt and punt on calls to outside libs, plus provide generics style specializable library code that is not AOT compiled.

I submit it's mostly solvable in language design. They're not all lazy of course, but claiming to be very performance-oriented is a half truth as long as you don't have a strong story here.

[ Parent | on HN ]

Re:Saving a Third of Our Memory by Re-Ordering Go Struct Fie... by pjmlp on Monday January 10, 2022 @03:46AM (#29872030)

That doesn't work in environments based on shared libraries or OS IPC component models.

[ Parent | on HN ]