Generics can make your Go code slower • Hacker News Board

Re: Generics can make your Go code slower

#301

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

SomeCallMeTim wrote: post #190

BobbyJo wrote: post #122

Earlier quoted context omitted.

I think his point was that they definitely won't make it faster (more abstraction means more indirection), so the expectation from most (myself included) would be that using them incurs a performance penalty, maybe not directly via their implementation, but via their use in broader terms.

Using templates in C++ can make code faster, though. Because you can write the same routine with more abstraction and less indirection. I've used C++ templates effectively as a code generator to layer multiple levels of abstractions into completely customized code throughout the abstraction.

> Using templates in C++ can make code faster, though. Because you can write the same routine with more abstraction and less indirection

If we are talking about the same code using generics vs. not generics, one would expect similar or worse performance depending on implementation details, as you are strictly adding indirection or not. Think add two 'ints' vs add two 'T'. Depending on the implementation of generics, you're adding indirection, or not.

If we are talking about leveraging generics to write different code that is more efficient, code that is perhaps infeasible without generics, then yes, totally get what you are saying. I, and I think parent, were referencing the former however, which is maybe not the most helpful way of comparing things :)

> I've used C++ templates effectively as a code generator to layer multiple levels of abstractions into completely customized code throughout the abstraction.

Yeah, I've done the same to inline matrix operations for lidar data processing. Templates are pretty neat since they are completely expanded at compile time. I've yet to look into the details of Golang's generics as far as implementation details go, but since Go has had code generation built in for a while, and it creates static binaries, I imagine it is a very similar system.

EDIT: After reading the part of the post that goes into detail on Go's implementation of generics, it is very similar, but differs when there is indirection on the input types.

Re: Generics can make your Go code slower

#302

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

steveklabnik wrote: post #208

dahfizz wrote: post #71

Earlier quoted context omitted.

> C and C++ dont really have package management to speak of I hear this complaint often, but I consider it a feature of C. You end up with much less third party dependencies, and the libraries you do end up using have been battle tested for decades. I much prefer that to having to install hundreds of packages just to check if a number is even, like in JS.

> You end up with much less third party dependencies, https://wiki.alopex.li/LetsBeRealAboutDependencies

This just proves my point. A complex, fully featured GUI application written in C needs 122 libs total.

In Rust, just installing SQLx for sqlite bindings requires 75 crates. And sqlite is one very small part of what rviz does. An rviz equivalent written in rust would require an order of magnitude more dependencies.

Re: Generics can make your Go code slower

#303

Post by eliben » Thu, Mar 31, 2022, 3:28 AM UTC

Some of the issues pointed out by this (very good) article may already be fixed in tip Go, with https://go-review.googlesource.com/c/go/+/385274

Re: Generics can make your Go code slower

#304

Post by unscaled » Thu, Mar 31, 2022, 3:42 AM UTC

svnpenn wrote: post #260

TheDong wrote: post #238

Earlier quoted context omitted.

It was not a joke. Let's look at a common example: you want to return two different types of errors and have the caller distinguish between them. Let me show it to you in rust and go. Rust: #[derive(Error, Debug)] pub enum MyErrors { #[error("NotFound: {0}") NotFound(String), #[error("Internal error")] Internal(#[source] anyhow::Error), } The equivalent go would be something like: type NotFoundErr struct { msg string…

I dont think you realize how ridiculous this comment is. Youre comparing 10 lines of Go, with 200 of Rust: https://github.com/dtolnay/thiserror/blob/master/src/lib.rs

You've did notice the file you've linked to only has 7 non-comment/documentation lines, right?

Now, to be fair, there are 50 or so lines of code in other files, but I would still love to see a useful Go package which is that small.

Re: Generics can make your Go code slower

#305

Post by KerrAvon » Thu, Mar 31, 2022, 3:47 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…

Come now. Nobody can sever my connection to the CPU with a pair of hedge clippers in the backyard.

Re: Generics can make your Go code slower

#306

Post by unscaled » Thu, Mar 31, 2022, 3:47 AM UTC

svnpenn wrote: post #276

TheDong wrote: post #274

Earlier quoted context omitted.

As I said above: > In this case, the abstraction available in rust is cleaner and requires less code for me, the user of the package, so I don't think the lines of code used to build that abstraction matter. > Why do you see this as something that matters? It's true that the abstraction in rust has more code underlying it, but why does that matter? If you de-facto never have to implement the rust error trait by hand…

Thats a good outlook. Dont worry about any problem, just import something an its fixed! More imports the better! Hopefully we can do away with all code, and just import everything.

Well, before Go 1.13 came out, every decent production codebase in Go had to import Dave Cheney's pkg/errors[1] unless you totally gave up the idea of having useful error traces.

Go 1.13 has incorporated most of what this package does into the standard library. It really doesn't matter much whether the code is in a de-facto standard package or folded into the standard library IMHO, but Rust could do the same.

[1]: https://github.com/pkg/errors

Re: Generics can make your Go code slower

#307

Post by torginus » Thu, Mar 31, 2022, 4:02 AM UTC

This is essentially how C# generics have worked since forever. If you want performance, don't use pointer type arguments.

Re: Generics can make your Go code slower

#308

Post by randomdata » Thu, Mar 31, 2022, 4:13 AM UTC

hsn915 wrote: post #290

vorpalhex wrote: post #171

Earlier quoted context omitted.

> 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. Your node code should be in the 2k reqs/s range trivially, with many frameworks comfortable offering 5k+. It is never going to be as fast as go, but it will handle most cases.

esbuild is 100x faster than js build tools, so in general 100x speed up sounds about right.

Sucrase, written in Typescript, claims to be 2x faster than esbuild.

I'll leave you to your own benchmarks.

Re: Generics can make your Go code slower

#309

Post by chrisseaton » Thu, Mar 31, 2022, 4:31 AM UTC

coder543 wrote: post #283

astrange wrote: post #277

Earlier quoted context omitted.

Stack's just the youngest generation. I can see the difference being that you have to scan a generation but the entire stack can be freed at once, but it still seems like an overly specific term. The general term elsewhere for multiple allocations you can free at the same time is "arenas".

From a conceptual point of view, I agree, but... in practice, stacks are incredibly cheap. The entire set of local variables can be allocated with a single bump of the stack pointer upon entry into a function, and they can all be freed with another bump of the stack pointer upon exit. With heap allocations, even with the simplest bump allocator.. you still have to allocate once per object, which can easily be an orde…

> you still have to allocate once per object

Why can’t you bump once to allocate enough space for multiple objects?

Re: Generics can make your Go code slower

#310

Post by azth » Thu, Mar 31, 2022, 4:32 AM UTC

geodel wrote: post #177

azth wrote: post #43

Earlier quoted context omitted.

In practice, it's used as an alternative to python and ruby and nodejs. It can't fully do what Java or C# do.

I mean of coure. I have not seen IBM Websphere Server 6.0.1 written in Go. Neither is there a full fledge SOAP/WSDL engine in Go. So clearly Go is less capable.

I've seen similar abominations written in golang, but they're not public.