Great post.
I always feel smart when I find these kind of optimisations. Then I wonder why the compiler isnt smarter, I dont have to be.
Making a Go program faster with a one-character change
191–200 of 249 posts
Re: Making a Go program faster with a one-character change
#192> I did consider two other approaches: Changing Ruleset from being []Rule to []*Rule, which would mean we no longer need to explicitly take a reference to the rule. Returning a Rule rather than a *Rule. This would still copy the Rule, but it should stay on the stack instead of moving to the heap. > However, both of these would have resulted in a breaking change as this method is part of the public API. The problem wi…
Sometimes it doesn't matter if a public API is incorrect, because it's set in stone for whatever reason, and you just need to fix the problem internally.
The way to fix it in that manner here is to undo the 42% speedup and return the heap allocated object for the caller to mangle.
Re: Making a Go program faster with a one-character change
#193If you want to have a solid understanding and need to do it in just a few hours here's a few things to review. - The Go programming language spec https://go.dev/ref/spec - Effective Go https://go.dev/doc/effective_go - Advanced Go concurrency patterns https://go.dev/talks/2013/advconc.slide#1 - Plus many more talks/slides https://go.dev/talks/
I created this video on concurrency (maybe advanced) patterns a while back that some may find helpful but it's pretty long https://www.youtube.com/watch?v=U3_2xiPxyA8.
Re: Making a Go program faster with a one-character change
#194Is there any nice tooling / static analysis for golang that instruments the builds the process to add all the gcflags with verbose output and give you hints as to what can be optimized?
Re: Making a Go program faster with a one-character change
#195> I did consider two other approaches: Changing Ruleset from being []Rule to []*Rule, which would mean we no longer need to explicitly take a reference to the rule. Returning a Rule rather than a *Rule. This would still copy the Rule, but it should stay on the stack instead of moving to the heap. > However, both of these would have resulted in a breaking change as this method is part of the public API. The problem wi…
The best part is, there's a subtle API breakage here: the returned *Rule is now a reference to an element of the []Rule, so if the caller was previously modifying the returned value it'll change the slice.
It's debatable what API guarantees existed around this though; most of the time this would be unspecified.
Re: Making a Go program faster with a one-character change
#196Earlier quoted context omitted.
> perhaps the problem is implicit allocations rather than value semantics? I think that’s true. Expensive copies should never have been implicit. There was a story some time ago about a single keypress in the address bar of Chrome causing thousands of memory allocations. The culprit: lots of std::string arguments up and down the call stack. Rust gets this right, with the hindsight of C++’s example: “a = b” is a move…
> except for plain data types where copying is literally memcpy what do you mean by this? If I say `let x = 5; let y = x;` in rust, that's a "plain data type copy" of a stack value, but memcpy is usually used to copy heap memory. What connection between copying of primitive simple stack values and memcpy are you suggesting here?
Why do you think memcpy is normally used to copy heap memory? It's just a general bitwise copy from one location to the other.
I think the confusion here is that there isn't always a literal call to memcpy for copying small types like ints in the emitted code, but it's always doing something with the same effect and maybe sometimes using an actual memcpy (probably when copying arrays?).
Also something interesting is that memcpy is used for copying data between stack variables in C sometimes when you need to convert some type to another one without using a cast.
Re: Making a Go program faster with a one-character change
#197So, this is very basic Go design and you could write something about how it works in C and Go and why a older lang like C don't have this prob but then at the end of the day the Go fanclub will down vote the hell out you no matter what.
Go compiler is garbage by the design. A 20 year old C compiler does not have this prob. This is also why Go have declined so much during the last couple of years. The benefits of Go have not increased and most of the quirks are still there. Like the error handling, the naive compiler and the syntax sugar that somewhat hides the diff between pointers and direct heap allocs. -1
C is not a good match for modern cpus. https://queue.acm.org/detail.cfm?id=3212479
Re: Making a Go program faster with a one-character change
#198Earlier quoted context omitted.
Go compiler is garbage by the design. A 20 year old C compiler does not have this prob. This is also why Go have declined so much during the last couple of years. The benefits of Go have not increased and most of the quirks are still there. Like the error handling, the naive compiler and the syntax sugar that somewhat hides the diff between pointers and direct heap allocs. -1
I work on a code base that is a mixture of Go and C. It's IO, CPU and Memory hungry, and it's distributed. C is fast because it's close to how CPU and memory actually work. Go gives you 95+% of that plus easy to learn, easy to use language. A new person could start contributing useful features and bug fixes immediately. A senior person could get C-level performance. More and more of our code is moved from C to Go, wi…
Here’s an article that refutes your claims. https://queue.acm.org/detail.cfm?id=3212479
Re: Making a Go program faster with a one-character change
#199If you want to have a solid understanding and need to do it in just a few hours here's a few things to review. - The Go programming language spec https://go.dev/ref/spec - Effective Go https://go.dev/doc/effective_go - Advanced Go concurrency patterns https://go.dev/talks/2013/advconc.slide#1 - Plus many more talks/slides https://go.dev/talks/
The "How to write Go code" article https://go.dev/doc/code is also very useful to actually know how to structure a codebase
Re: Making a Go program faster with a one-character change
#200Well, technically it's either a 2-character or 0-character change! :-)