Hi Pepper, since your question is about the opinion of the developers who work on the Go-compiler, it might get more attention over at the sibling group https://groups.google.com/g/golang-dev .
I would add, if you can use tinygo, then you can use clang's optimizations today. https://tinygo.org/ has alot of limitations, but it is worth checking out. Jason On Saturday, November 30, 2024 at 9:37:52 PM UTC-6 Pepper Lebeck-Jobe wrote: > Dear golang-nuts, > > Summary: Would we be open to adding SROA as a compiler optimization to the > go compiler? > > I recently discovered via this rathole > <https://github.com/bddicken/languages/pull/44#issuecomment-2508940093> > that SROA is something that Clang does for the programming languages which > compile with it. The implementation is here > <https://github.com/llvm/llvm-project/blob/main/llvm/lib/Transforms/Scalar/SROA.cpp> > . > > I also think that the lack of this compiler optimization is why there is a > notable performance difference in the two benchmarks mentioned in > https://github.com/golang/go/issues/49785 > > On the one hand, I have heard that the go team generally favors fast > compilation times over compiler complexity and slower build times. On the > other hand, I suspect that this optimization could really speed up a lot of > go projects that exist in the wild. > > Before really being surprised by the differences between the C and go > performance in the bddicken/languages > <https://github.com/bddicken/languages>, I wouldn't have thought twice > about writing a loop that aggregates values in a slice or an array in go. > And, now that I've seen the performance difference, I'd much rather have > the compiler optimize this for me than to go combing through my projects > and manually allocating a local aggregation variable in the hopes of > getting to use a register. > > At this point, I'm just taking a "temperature" check to see if folks would > entertain the idea. I haven't really studied compilers, and would probably > need some guidance to successfully contribute it to gc. But, I don't want > to go through the learning and heavy-lifting if there's a major chance that > the PR review would end up sounding like, "While it clearly produces more > efficient binaries, we don't think it's worth the additional compilation > time." > > Let me know if I should "dive in" or just remember to be very careful when > aggregating operations in loops to a location in memory. > > Thanks, > Pepper > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion visit https://groups.google.com/d/msgid/golang-nuts/25670404-3e2e-45eb-a182-eeacb1abc7bcn%40googlegroups.com.
