Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Generics can make your Go code slower

planetscale.com

Post reply on HN
Print view View original

81–90 of 418 posts

Re: Generics can make your Go code slower

#81

Post by titzer »

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…

You really haven't given any supporting information for your argument other than a vague feeling that GC is somehow bad. In fact you just pointed out many counterexamples to your own argument, so I'm not sure what to take away.

I've seen this sentiment a lot, and I never see specifics. "GC is bad for systems language" is an unsupported, tribalist, firmly-held belief that is unsupported by hard data.

On the other hand, huge, memory-intensive and garbage-collected systems have been deployed in vast numbers by thousands of different companies for decades, long before Go, within acceptable latency bounds. And shoddy, poorly performing systems have been written in C/C++ and failed spectacularly for all kinds of reasons.

Re: Generics can make your Go code slower

#82

Post by jpgvm »

Thaxll wrote: post #69
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…

There are very fast DB written in Go so this comment is irrelevant, what is the equivalent of https://github.com/VictoriaMetrics/VictoriaMetrics in an other language?

Gorilla which many of VM ideas are based on is in C++.

Druid is Java and very fast but not like for like as it's an event database not a timeseries database. Pinot is in the same vein.

Most of the very big and very fast databases you have used indirectly though web services like Netflix (Cassandra), etc are written in Java.

Re: Generics can make your Go code slower

#83

Post by ohYi55 »

svnpenn wrote: post #62
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…

Typical gatekeeping. I like Go, because it lets me get stuff done. You could say the same about JavaScript, but I think Go is better because of the type system. C, C++ and Rust are faster in many cases, but man are they awful to work with. C and C++ dont really have package management to speak of, its basically "figure it out yourself". I tried Rust a couple of times, but the Result/Option paradigm basically forces y…

git clone?

I mean do we need bespoke package management tooling for everything now?

Seems like an outdated systems admin meme that violates KISS, explodes dependency chains, risks security, etc. IT feels infected by sunk cost fallacy.

It’s electron state in machines. The less altogether the better.

Re: Generics can make your Go code slower

#84

Post by throwaway894345 »

stingraycharles wrote: post #66
baq wrote: post #58

Earlier quoted context omitted.

this has been argued ad nauseum a decade ago and it boils down to your definition of 'systems'. at google scale, a system is a mesh of networked programs, not a kernel or low-level bit-banging tool.

By that definition, Java is a systems language as well. I think Go makes a better trade-off than Java, but I struggle to come up with decent examples of projects one could write in Go and not in Java. Most of the “systems” problems that Java is unsuitable for, also apply to Go.

I don't think it's useful to frame "fitness for a given domain" as a binary, but yes, Java is often used successfully for this domain (although personally I think Go is an even better fit for a variety of reasons).

Re: Generics can make your Go code slower

#85

Post by geodel »

stingraycharles wrote: post #66
baq wrote: post #58

Earlier quoted context omitted.

this has been argued ad nauseum a decade ago and it boils down to your definition of 'systems'. at google scale, a system is a mesh of networked programs, not a kernel or low-level bit-banging tool.

By that definition, Java is a systems language as well. I think Go makes a better trade-off than Java, but I struggle to come up with decent examples of projects one could write in Go and not in Java. Most of the “systems” problems that Java is unsuitable for, also apply to Go.

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

Re: Generics can make your Go code slower

#86

Post by titzer »

SomeCallMeTim wrote: post #55
klodolph wrote: post #32

I'm excited about generics that gives you a tradeoff between monomorphization and "everything is a pointer". The "everything is a pointer" approach, like Haskell, is incredibly inefficient wrt execution time and memory usage, the "monomorphize everything" approach can explode your code size surprisingly fast. I wouldn't be surprised if we get some control over monomorphization down the line, but if Go started with th…

> "monomorphize everything" approach can explode your code size surprisingly fast. It can in the naive implementation. Early C++ was famous for code bloat and (apparently) hasn't shaken that outdated impression. In practice, monomorphization of templates hasn't been a serious issue in C++ for a long time. The compiler and linker technologies have advanced significantly.

> The compiler and linker technologies have advanced significantly.

AFAICT the linker de-duplicates identical pieces of machine code. You still can get multi-megabyte object files for every source file. I used to work on V8. Almost every .o is 3+MB. Times hundreds, plus bigger ones, it's more than a gigabyte of object files for a single build. That's absurd. Not V8's fault--stupid C++ compilation and linking model.

Re: Generics can make your Go code slower

#87

Post by mcronce »

svnpenn wrote: post #62
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…

Typical gatekeeping. I like Go, because it lets me get stuff done. You could say the same about JavaScript, but I think Go is better because of the type system. C, C++ and Rust are faster in many cases, but man are they awful to work with. C and C++ dont really have package management to speak of, its basically "figure it out yourself". I tried Rust a couple of times, but the Result/Option paradigm basically forces y…

What, specifically, do you mean when you say Rust is "awful to work with"? With C and C++ I agree, but I've had a drastically better development experience in Rust than Go.

Re: Generics can make your Go code slower

#88

Post by fbkr »

josefx wrote: post #77
SomeCallMeTim wrote: post #51

Earlier quoted context omitted.

In C++, generics (templates) are zero-cost abstractions. So no, generics do not de facto make code slower.

C++ can suffer from negative performance from template bloat in two ways: Templated symbol names are gigantic. This can impact program link and load times significantly in addition to the inflated binary size. Duplication of identical code for every type, for example the methods of std::vector and std::vector should compile to the same instructions. There are linker flags that allow some deduplication but those have…

> There are linker flags that allow some deduplication but those have their own drawbacks

As long as you use --icf=safe I don't see any drawback, and most of the time it results in almost identical reductions to --icf=all since not many real programs compare addresses of functions.

Re: Generics can make your Go code slower

#89

Post by siftrics »

pphysch wrote: post #29

My first use of Go generics has been for a concurrent "ECS" game engine. In this case, the gains are pretty obvious. I think. I get to write one set of generic methods and data structures that operate over arbitrary "Component" structs, and I can allocate all my components of a particular type contiguously on the heap, then iterate over them with arbitrary, type-safe functions. I can't fathom that doing this via a Co…

Assuming your generic functions take _pointers_ to Components as input, full monomorphization does not occur and you're suffering a performance hit similar in magnitude, if not strictly greater empirically, to interface "dereferences".

On this basis, I don't believe your generic implementation is as faster than an interface implementation as you claim.

Re: Generics can make your Go code slower

#90

Post by pionar »

geodel wrote: post #85
stingraycharles wrote: post #66

Earlier quoted context omitted.

By that definition, Java is a systems language as well. I think Go makes a better trade-off than Java, but I struggle to come up with decent examples of projects one could write in Go and not in Java. Most of the “systems” problems that Java is unsuitable for, also apply to Go.

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.

Post reply on HN