I think it would be neat for the Go compiler to natively support profiles for profile-guided optimization <https://en.wikipedia.org/wiki/Profile-guided_optimization> to help make decisions about code generation for generics (and specialization for interfaces, for that matter). And also other random optimizations, for example inline aggressiveness. If you can manage a semi-realistic load test, or if you can (sometimes) profile in production, then no one needs to fiddle with knobs to get pretty good optimization decisions. Plus, if you can set something up regularly re-profile, then you can ensure that optimization decisions don't go stale like might happen with static knobs.
Then, someone could write a profile generator based on knobs or in-source annotations, if they really wanted to :) On Sunday, February 27, 2022 at 3:34:53 PM UTC-7 ren...@ix.netcom.com wrote: > I think that would be a miss. The size/speed trade-off cannot often not be > made accurately when viewed in isolation. E.g. it may be the best course of > action to generic 16 different implementations in some cases, but as a > general rule exploding every implementation x16 is probably unwise. > > Being able to turn knobs on these decisions will be critical to achieving > optimal overall application performance. > > On Feb 27, 2022, at 12:03 PM, 'Axel Wagner' via golang-nuts < > golan...@googlegroups.com> wrote: > > On Sun, Feb 27, 2022 at 6:33 PM robert engels <ren...@ix.netcom.com> > wrote: > >> I disagree that it wont be formally published - or at least have knobs to >> turn to control it - otherwise it will be nearly impossible to make the >> determination of when your generic’s usage will result in a performance >> penalty. >> > > This doesn't seem substantially different from escape analysis. Where > there is also no spec or any other formal description, but just a flag to > log decisions. > I would expect generics to work similar in that regard. > > >> This probably won’t matter for 95% of the code - but it if does matter - >> your only solution would be to always avoid generics and roll your own - >> which defeats the purpose. >> >> I can see build labels controlling the generation options. >> >> On Feb 26, 2022, at 5:51 PM, Ugorji Nwoke <ugo...@gmail.com> wrote: >> >> To your direct questions, the answer is a mix of both: C++ style where >> the generic block is a template and code is essentially generated for each >> type known at compile time with static dispatch, and java-like where it is >> similar to an interface call with dynamic dispatch. The compiler will >> strike the right balance of binary size, compile time and execution speed. >> To follow its heuristics rules (which will likely not be formally published >> to prevent people from depending on it), you might have to stay close to >> the development for that. >> >> On Friday, February 25, 2022 at 5:15:47 AM UTC-5 markus....@gain.pro >> wrote: >> >>> Correction: >>> >>> - it must be possible to express that T is comparable (so that you can >>> use map[K]V, were K must be comparable) >>> - it must be possible restrict T to a concrete list of types (f.e. >>> min(a, b T) T must be possible to write) >>> >>> On Friday, February 25, 2022 at 11:13:01 AM UTC+1 Markus Heukelom wrote: >>> >>>> I think the consensus in the Go community is to refrain from comparing >>>> Go language features with other programming languages. Rationale ~: >>>> >>>> - it is highly contentious >>>> - it is very difficult to answer, it's like asking "is purple more blue >>>> or more red" >>>> - no matter the answer, it will not help you a lot to write better >>>> programs or be more productive in Go >>>> >>>> However, maybe your real question is more like "what are/were the >>>> guiding principals for generics in Go?". As far as I understand, >>>> generics >>>> in Go follow the same principles as other language features in Go: >>>> >>>> - compilation should be very fast, but trade-offs are allowed so it >>>> does not need to be maximally fast >>>> - language features should be as orthogonal as possible, but trade-offs >>>> are allowed so they don't need to be maximally orthogonal >>>> - it should be a simple as possible but no simpler >>>> - ... >>>> >>>> For generics this has resulted in: >>>> >>>> - exotic use-cases are not supported (for example having an integer >>>> *constant* as *generic parameter*, such as you see in C++ fixed size >>>> matrix >>>> templates, is not supported) >>>> - it must be possible to express that T is comparable (f.e. min(a, b T) >>>> T must be possible to write) >>>> - it must be possible restrict T to a concrete list of types >>>> - it must be possible to restrict T to a type with method set that >>>> equals that of some interface (I *personally* think this violates the >>>> principle of orthogonality too much and will lead to confusion and design >>>> debate) >>>> >>>> Of course, neither list is exhaustive and is only my personal >>>> understanding of things. >>>> >>>> -Markus >>>> >>>> On Wednesday, February 23, 2022 at 9:41:14 PM UTC+1 Jason E. Aten wrote: >>>> >>>>> Back in 2009, Russ wrote a blog on generics, talking about the >>>>> tradeoffs in providing generics: >>>>> >>>>> "The generic dilemma is this: *do you want slow programmers, slow >>>>> compilers and bloated binaries, or slow execution times? " -- * >>>>> https://research.swtch.com/generic >>>>> >>>>> I haven't had the bandwidth to follow the generics detailed >>>>> discussions. I was just curious, at a high level, for creating a mental >>>>> model of Go's generics: which approach was taken? >>>>> >>>>> Thanks! >>>>> >>>>> J >>>>> >>>> >> -- >> 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 golang-nuts...@googlegroups.com. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/golang-nuts/8edf65b3-f499-4446-908e-8e35d3070739n%40googlegroups.com >> >> <https://groups.google.com/d/msgid/golang-nuts/8edf65b3-f499-4446-908e-8e35d3070739n%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> >> >> >> -- >> 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 golang-nuts...@googlegroups.com. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/golang-nuts/D2355A50-46F9-475B-8651-5C7B117DFB2D%40ix.netcom.com >> >> <https://groups.google.com/d/msgid/golang-nuts/D2355A50-46F9-475B-8651-5C7B117DFB2D%40ix.netcom.com?utm_medium=email&utm_source=footer> >> . >> > > -- > 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 golang-nuts...@googlegroups.com. > > To view this discussion on the web visit > https://groups.google.com/d/msgid/golang-nuts/CAEkBMfHthjk9Oj5GemTRxXoeYgvOeR_hkism8og3YtWtvoJRVQ%40mail.gmail.com > > <https://groups.google.com/d/msgid/golang-nuts/CAEkBMfHthjk9Oj5GemTRxXoeYgvOeR_hkism8og3YtWtvoJRVQ%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > > > -- 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 golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/a8d5cf8b-5309-4d28-828a-6c40938297bcn%40googlegroups.com.
