Generics can make your Go code slower • Hacker News Board

Re: Generics can make your Go code slower

#291

Post by shlurpy » Thu, Mar 31, 2022, 1:30 AM UTC

pionar wrote: post #90

geodel wrote: post #85

Earlier quoted context omitted.

Go has user defined value types which Java does not yet. It makes huge difference in memory density for typical data structures. This makes Go more suitable to low overhead web services, cli tools running on few MBs which Java at least needs few hundred MBs

> Go has user defined value types which Java does not yet. C# has this. A lot of people overlook C# in this area, probably because until recently, it was not cross-platform.

The games world has understood C# to be a reasonably capable language for a while. But that world often feels disjoint with the enterprise software world where Go has thrived, eating into Java's niche.

Re: Generics can make your Go code slower

#292

Post by blindmute » Thu, Mar 31, 2022, 1:40 AM UTC

nvarsj wrote: post #46

I'd argue that golang is inherently not a systems language, with its mandatory GC managed memory. I think it's a poor choice for anything performance or memory sensitive, especially a database. I know people would disagree (hence all the DBs written in golang these days, and Java before it), but I think C/C++/Rust/D are all superior for that kind of application. All of which is to say, I don't think it matters. Use t…

Honest question, what is golang a good choice for? It seems to inhabit the nether realm between high level productivity and low level performance, not being good at either.

Re: Generics can make your Go code slower

#293

Post by msla » Thu, Mar 31, 2022, 1:42 AM UTC

mcronce wrote: post #217

msla wrote: post #26

Earlier quoted context omitted.

I agree with the commenter you're replying to; I'd only add that Intel syntax is much more readable than AT&T.

FWIW, I'm fairly sure this is the assembly syntax used by Go - the author may not have made a decision to use this vs another

Possibly, but objdump can disassemble into Intel syntax.

Re: Generics can make your Go code slower

#294

Post by dahfizz » Thu, Mar 31, 2022, 2:03 AM UTC

pjmlp wrote: post #184

dahfizz wrote: post #117

Earlier quoted context omitted.

You need have some OS API, what is wrong with POSIX? And what does POSIX have to do with package management?

POSIX is UNIX rebranded as C runtime for OSes that aren't UNIX.

I don't even know how to parse that. POSIX is a standard which was based on the unix OS's of the time. POSIX is an API, not a runtime. Only Unix systems today implement posix (MacOs, Linux).

Re: Generics can make your Go code slower

#295

Post by throwawaylala1 » Thu, Mar 31, 2022, 2:08 AM UTC

ClumsyPilot wrote: post #289

throwawaylala1 wrote: post #273

Earlier quoted context omitted.

If you're needing to fight the GC to prevent crashes or whatever then you have a system design issue not a tooling/language/ecosystem issue. There are exceptions to this but they're rare and not worth mentioning in a broad discussion like this. Sadly very few people take interest in learning how to design systems properly. Instead they find comfort in tools that allow them to over-engineer the problems away. Like fal…

> Computers suck at networking. We have _a lot_ of complex layers to help make it feel somewhat reliable. I've got bad news pal: your SSD has a triple-core ARM processor and is connected to the CPU through a bus, which is basically a network, complete with error correction and exact same failure modes as your connection to the new york stock exchange. Even the connection between your CPU and it's memory can prodice e…

Computer systems are imperfect. No one is claiming otherwise. What matters more is the probability of failure, rates of failure in the real world, P95 latencies, how complex it is to mitigate common real world failures, etc, etc, etc.

"Turtles all the way down" is an appeal to purity. It's exactly the kind of fallacious thinking that leads to bad system design.

Re: Generics can make your Go code slower

#296

Post by chakkepolja » Thu, Mar 31, 2022, 2:11 AM UTC

SomeCallMeTim wrote: post #198

chakkepolja wrote: post #109

Earlier quoted context omitted.

We don't know of a way to implement generic types without (vtable dispatch + boxing) cost AND without monomorphization cost. Some languages do former, some latter, some combination of 2. Monomorphization: * code bloat * slow compiles * debug builds may be slow (esp c++) Dynamic dispatch & boxing (Usually both are needed): * not zero cost Pick your poison

"Zero-cost" in that context refers to runtime performance. It always refers to runtime performance. And code bloat, as I've said elsewhere, is vastly overblown as a problem. Another commenter pointed out that link-time optimization removes most of the bloat. The rest is customized code that's optimized per-instantiation. Slow compiles are an issue with C++ templates. They're literally a Turing-complete code-generatio…

> Slow compiles are an issue with C++ templates.

As far as I know

Rust has the same problem although to lesser extent. Monomorphization works well with judicious use. C++ STL is not written like that, they depend on 11111 layers of inlining to work well. Rust libraries aren't much better in this regard.

LTO removed some code bloat, but LTO itself takes more time. until thinLTO summary pass / equivalent pass in GCC WHOPR at least, middle end and early IR optimizations still have to happen, and Go wants to avoid that. I think that's a fine design choice. In Go's design, they have decided virtual calls aren't a cost they'd care anyway, pre 1.8 Go heavily used interfaces and that's not going to change.

> writing the code out customized for each given type should have identical performance to the template-generated version of the code

In theory yeah, but templates tend to generate more instantiations than strictly what you'd write by hand.

Also, obscure corner cases exist, but not big enough, thanks to those numerous man years spent on GCC and LLVM. https://travisdowns.github.io/blog/2020/01/20/zero.html

Re: Generics can make your Go code slower

#297

Post by jordanlewis » Thu, Mar 31, 2022, 2:15 AM UTC

zachruss92 wrote: post #145

For me Go has replaced Node as my preferred backend language. The reason is because of the power of static binaries, the confidence that the code I write today can still run ten years from now, and the performance. The difference in the code I’m working with is being able to handle 250 req/s in node versus 50,000 req/s in Go without me doing any performance optimizations. From my understanding Go was written with dev…

Director of engineering for CockroachDB SQL here.

One of the major pain points we have with Go is the lack of language support for monomorphization. We rely on a hand-built monomorphizing code generator [0] to compile CockroachDB's vectorized SQL engine [1]. Vectorized SQL is about producing efficient, type and operator specific code for each SQL operator. As such, we rely on true monomorphization to produce a performant SQL query engine.

I have a hope that, eventually, Go Generics will be performant enough to support this use case. As the author points out, there is nothing in the spec that prevents this potential future! That future is not yet here, but that's okay.

There are probably some less performance-sensitive use cases within CockroachDB's code base that could benefit from generics, but we haven't spend time looking into it yet.

[0]: https://github.com/cockroachdb/cockroach/blob/master/pkg/sql...

[1]: https://www.cockroachlabs.com/blog/how-we-built-a-vectorized...

Re: Generics can make your Go code slower

#298

Post by ovao » Thu, Mar 31, 2022, 2:15 AM UTC

socialdemocrat wrote: post #252

Really well written article. I liked that the author tried to keep a simple language around a fair amount of complex topics. Although the article paints the Go solution for generics somewhat negative, it actually made me more positive to the Go solution. I don't want generic code to be pushed everywhere in Go. I like Go to stay simple and it seems the choices the Go authors have made will discourage overuse of Generi…

I expect we’re going to see most generic Go code happening at the lower levels of the stack. So cintainer libraries, utility/algo functions, and probably in some contexts around databases/ORMs. Outside of these contexts —- and because most usage will be able to simply leverage type deduction —- I’d guess most app code will look pretty similar to what we’ve seen before.

Re: Generics can make your Go code slower

#299

Post by throwawaylala1 » Thu, Mar 31, 2022, 2:15 AM UTC

Karrot_Kream wrote: post #285

throwawaylala1 wrote: post #273

Earlier quoted context omitted.

If you're needing to fight the GC to prevent crashes or whatever then you have a system design issue not a tooling/language/ecosystem issue. There are exceptions to this but they're rare and not worth mentioning in a broad discussion like this. Sadly very few people take interest in learning how to design systems properly. Instead they find comfort in tools that allow them to over-engineer the problems away. Like fal…

It's because system design is a lot less theoretically clean than something like FP, zero-cost abstractions, GC-less coding, containerization, etc, and forces programmers to confront essential complexity head-on. Lots of engineers think that theoretically complex/messy/hacky solutions are, by their nature, lesser solutions. Networking is actually a great example. Real life networking is really complicated and there a…

> The real world is messy, as much as programmers want to think it's not.

You hit the nail on the head with the whole comment and that line in particular.

I'll add that one of the most effective ways to deal with some of the messiness/complexity is simply to avoid it. Doing that is easier said than done these days because complexity is often introduced through a dependency. Or perhaps the benefits of adopting some popular architecture (eg: containerization) is hiding the complexity within.

> It's because system design is a lot less theoretically clean

Yea this is a major problem. It's sort of a dark art.

Re: Generics can make your Go code slower

#300

Post by EdwardDiego » Thu, Mar 31, 2022, 2:31 AM UTC

zinekeller wrote: post #266

EdwardDiego wrote: post #231

Earlier quoted context omitted.

> A good portion of production outages are likely related to cascading failures due to too long GC pauses, and a good portion of developer time is spent testing and tuning GC parameters After 14 years in JVM dev in areas where latency and reliability are business critical, I disagree. Yes, excessive GC stop the world pauses can cause latency spikes, and excessive GC time is bad, and yes, when a new GC algorithm is re…

> I've never had to debug corrupted memory You're lucky! When OpenJDK was still closed-sourced Hotspot from Sun, we have chased bugs that Sun confirmed was a defect on how Hotspot handle memory (and this is on a ECC'd system of course), although these days I can't remind of anything remotely related. > or how a use after free bug let people exfiltrate data. Technically you're just outsourcing it :)

Yeah, have only ever hit one or two JVM bugs in very rare circumstances - which we usually fixed by upgrading.

> Technically you're just outsourcing it :)

Haha, very true. Luckily, to developers who are far better at that stuff than the average bear.

The recent log4j rigmarole is a great example of what I was describing in JVM dev though - no complicated memory issues involved, definitely not GC related, just developers making decisions using technologies that had very subtle footguns they didn't understand (the capacity to load arbitrary code via LDAP was, AFAIK, very poorly known, if not forgotten, until Log4Shell).