--
You received this message because you are subscribed to the Google Groups "golang-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/golang-dev/CAB%3Df9xT9%2BYHA5qT2GmUAoQ-ne_a8RWg4uRKDXwSgdn0M5RxdTA%40mail.gmail.com.
But it's not fair to compare it to the container packages both because it will almost certainly perform much better than the container packages, and because the other major limitation of the container packages is usability, which any implementation of generics will address.
On Sep 17, 2020, at 7:24 PM, 'Austin Clements' via golang-dev <golan...@googlegroups.com> wrote:
On Thu, Sep 17, 2020 at 8:16 PM Austin Clements <aus...@google.com> wrote:But it's not fair to compare it to the container packages both because it will almost certainly perform much better than the container packages, and because the other major limitation of the container packages is usability, which any implementation of generics will address.I should clarify why I think it will perform better (partly because Ian said it will carry similar overhead about 60 seconds before I sent this claim :). Because the current containers (at least, the ones no one uses) use interface{}s in the data structures themselves, they force a level of indirection. Both stenciling and dictionary-passing will let us embed values directly in container types, significantly reducing the memory and GC overhead for storing scalar values (and slightly reducing it when storing pointer values by at least eliminating the "type" field implicit in the interface value). I think the container methods themselves would perform similarly to the interface{}-based ones. It will also save on the costs of type assertions for users of the containers, though that cost is probably small right now.
--
You received this message because you are subscribed to the Google Groups "golang-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/golang-dev/CALgmw1-rfiqzGiwYVOknT5kv2HdnRxh-828cd0oPepS-dbd1LA%40mail.gmail.com.
What stops doing both? A compile time flag or even based on thresholds of generic types used. Similar to how a compiler decides on inlining.
I thought it was already said somewhere that there'd be no point to this whole generics proposal if the implementation carried a runtime cost. I don't think it'll be used as much if it's slow or GC heavy at runtime (like how nobody uses the container packages in std)I'd hope for a hybrid: stenciling but sharing instantiations when they had the same GC bitmap shape.
To view this discussion on the web visit https://groups.google.com/d/msgid/golang-dev/CAFzRk0036aTkmR-wT89%3DBWFstPEboTXfAZp-Eq0nLodDaieAqw%40mail.gmail.com.
I believe Swift uses a “dictionary-passing” approach in its implementation of generics. There's a talk on it here: https://youtu.be/ctS8FzqcRugThey have a type system feature called "protocols," which are similar to interfaces. They use witness tables to capture the allocation, copying, and destruction of a value, as well as conform to its protocol.
The Go generics proposal is working its way through the proposal process. It's a very complicated proposal, which begs the question:If the generics proposal is accepted, how are we going to implement it?The Go team at Google has put some thought into this question all along, but we think now is the time to start thinking more seriously and widely about it. Hence this email. Note that the generics proposal is not accepted yet, so we'll have to discuss implementations without having a final accepted proposal in hand. Nevertheless, the outline of the proposal is pretty clear and provides a sufficient basis to consider implementation strategies, even if we might have to revise those strategies if changes to the proposal are forthcoming.Of course, if the proposal is declined we'll have wasted some work. If it is accepted in some form, however, we'll hopefully have accelerated the progress to an implementation.I've written up two design docs containing two possible strategies for implementing generics. They are:
- Stenciling. This strategy generates a separate implementation of a generic function for every instantiation (set of provided type arguments). This is more-or-less how C++ does generics.
- Dictionaries. This strategy generates a single implementation of a generic function which can handle all possible type arguments. This is kind-of how Java does generics, although the analogy is weaker than the stenciling-C++ one.
There may be other implementation strategies (including hybrids of the two above); these two are just to set the ball rolling on discussion.
What do people think? Which strategy do you like? What glaring showstopper are we forgetting?
On Friday, 18 September 2020 at 00:10:14 UTC+2 Keith Randall wrote:The Go generics proposal is working its way through the proposal process. It's a very complicated proposal, which begs the question:If the generics proposal is accepted, how are we going to implement it?The Go team at Google has put some thought into this question all along, but we think now is the time to start thinking more seriously and widely about it. Hence this email. Note that the generics proposal is not accepted yet, so we'll have to discuss implementations without having a final accepted proposal in hand. Nevertheless, the outline of the proposal is pretty clear and provides a sufficient basis to consider implementation strategies, even if we might have to revise those strategies if changes to the proposal are forthcoming.Of course, if the proposal is declined we'll have wasted some work. If it is accepted in some form, however, we'll hopefully have accelerated the progress to an implementation.I've written up two design docs containing two possible strategies for implementing generics. They are:
- Stenciling. This strategy generates a separate implementation of a generic function for every instantiation (set of provided type arguments). This is more-or-less how C++ does generics.
- Dictionaries. This strategy generates a single implementation of a generic function which can handle all possible type arguments. This is kind-of how Java does generics, although the analogy is weaker than the stenciling-C++ one.
There may be other implementation strategies (including hybrids of the two above); these two are just to set the ball rolling on discussion.What do people think? Which strategy do you like? What glaring showstopper are we forgetting?The way I'd write this today is using type switches over interface{} where I need to narrow the type. If the compiler rewrote to that, it would be "zero surprises" for me in terms of performance, so I'm wondering if that was considered before the Dictionaries suggestion? I could imagine many functions just plumb through to others without narrowing types, making dictionaries add overhead (memory and CPU) where it would be surprising to me.
At a high level, stenciling allows for better runtime performance, at the cost of larger binaries and slower compile times. Stenciling is also somewhat simpler to implement in the compiler. But those are generalizations and depend a lot on the code being compiled and the various mitigations (discussed in the design docs) that could be brought to bear.There are also lots of other smaller decisions we'll need to make about generics implementation. How do we modify the compiler's parser? Its internal type representation? What in the runtime needs to understand generics? All of these are also fair game for this discussion.And on a final note, I'd like to brainstorm about prep work we can do now that will make generics easier if/when the proposal gets accepted. We're obviously not going to have generics in for 1.16, but we might want to do some prep work in 1.16 for pieces we know we'll need, or think we'll need, for an eventual generics implementation. For example, I've been working on a prototype of variable-sized frames which would be useful for the dictionary proposal above, but might also be useful for other things, like reflect.Call. Another idea is cleaning up the compiler organization to make it easier to plug in a different typechecker.Process notes:- Let's start discussing the topics outlined above in this email thread. If the discussion gets verbose enough, we might want to move it somewhere else (e.g. a reddit thread). We'll cross that bridge when/if we get to it.- If you have specific edits to the docs linked above, you can mail me a CL.- This discussion is about implementation of the generics proposal, not the generics proposal itself. The line is a bit fuzzy, but if you're unsure you might consider discussing the generics proposal (currently happening on golang-nuts, search for the [generics] subject line) instead of posting here.
--
You received this message because you are subscribed to the Google Groups "golang-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/golang-dev/9dd39010-d1b5-4de9-8e85-96c06f9c3d93n%40googlegroups.com.
On Fri, 18 Sep 2020 at 00:46, Brad Fitzpatrick <brad...@golang.org> wrote:I thought it was already said somewhere that there'd be no point to this whole generics proposal if the implementation carried a runtime cost. I don't think it'll be used as much if it's slow or GC heavy at runtime (like how nobody uses the container packages in std)I'd hope for a hybrid: stenciling but sharing instantiations when they had the same GC bitmap shape.This is what I'd expect too. It'll still need a dictionary so that you can invoke generic operations (there wouldbe a runtime cost similar to the runtime cost of invoking methods on an interface because method calls wouldbe indirect), but at least you can copy values around and look up items on the stack without extra cost.In general, you can share code between implementations that have the same alignment and GC bitmap shapewithout changing the code generation for function bodies much. I actually prototyped this as an idea some time ago using the current compilerand writing the instantiated code as if it had been generated automatically. I just updated it to use the latestsyntax - it's at https://github.com/rogpeppe/genericdemo and contains a working (well, it's lightly tested at least)version of the graph example from the original generics draft protocol.
On Fri, Sep 18, 2020 at 4:51 AM roger peppe <rogp...@gmail.com> wrote:On Fri, 18 Sep 2020 at 00:46, Brad Fitzpatrick <brad...@golang.org> wrote:I thought it was already said somewhere that there'd be no point to this whole generics proposal if the implementation carried a runtime cost. I don't think it'll be used as much if it's slow or GC heavy at runtime (like how nobody uses the container packages in std)I'd hope for a hybrid: stenciling but sharing instantiations when they had the same GC bitmap shape.This is what I'd expect too. It'll still need a dictionary so that you can invoke generic operations (there wouldbe a runtime cost similar to the runtime cost of invoking methods on an interface because method calls wouldbe indirect), but at least you can copy values around and look up items on the stack without extra cost.In general, you can share code between implementations that have the same alignment and GC bitmap shapewithout changing the code generation for function bodies much. I actually prototyped this as an idea some time ago using the current compilerand writing the instantiated code as if it had been generated automatically. I just updated it to use the latestsyntax - it's at https://github.com/rogpeppe/genericdemo and contains a working (well, it's lightly tested at least)version of the graph example from the original generics draft protocol.There's some discussion in the stenciling doc about deduplicating implementations, which I think would capture the case of two types that have identical GC bitmap shapes. Do you think that would be sufficient, or not?
On Fri, Sep 18, 2020 at 8:43 AM Tommie Gannert <tgan...@gmail.com> wrote:On Friday, 18 September 2020 at 00:10:14 UTC+2 Keith Randall wrote:The Go generics proposal is working its way through the proposal process. It's a very complicated proposal, which begs the question:If the generics proposal is accepted, how are we going to implement it?The Go team at Google has put some thought into this question all along, but we think now is the time to start thinking more seriously and widely about it. Hence this email. Note that the generics proposal is not accepted yet, so we'll have to discuss implementations without having a final accepted proposal in hand. Nevertheless, the outline of the proposal is pretty clear and provides a sufficient basis to consider implementation strategies, even if we might have to revise those strategies if changes to the proposal are forthcoming.Of course, if the proposal is declined we'll have wasted some work. If it is accepted in some form, however, we'll hopefully have accelerated the progress to an implementation.I've written up two design docs containing two possible strategies for implementing generics. They are:
- Stenciling. This strategy generates a separate implementation of a generic function for every instantiation (set of provided type arguments). This is more-or-less how C++ does generics.
- Dictionaries. This strategy generates a single implementation of a generic function which can handle all possible type arguments. This is kind-of how Java does generics, although the analogy is weaker than the stenciling-C++ one.
There may be other implementation strategies (including hybrids of the two above); these two are just to set the ball rolling on discussion.What do people think? Which strategy do you like? What glaring showstopper are we forgetting?The way I'd write this today is using type switches over interface{} where I need to narrow the type. If the compiler rewrote to that, it would be "zero surprises" for me in terms of performance, so I'm wondering if that was considered before the Dictionaries suggestion? I could imagine many functions just plumb through to others without narrowing types, making dictionaries add overhead (memory and CPU) where it would be surprising to me.I'm not entirely sure what you are suggesting. Do you mean that we type-erase, i.e. replace every occurrence of a generic type T with interface{}, then add casts in the appropriate places?I don't think this entirely works. What about:func index[T any](a []T, i int) T {return a[i]
}r := index[int64]([]int64{1,2,3}, 1)We can't just treat []T as []interface{}, because int and interface{} have different sizes, so the indexing computation required is type-dependent.
Same for the return value. The caller is expecting an 8-byte return value, not a 16-byte interface that it needs to cast. Especially if you do:f := index[int64]r := f([]int64{1,2,3}, 1)Maybe we could introduce wrappers functions for situations like this?
--
You received this message because you are subscribed to the Google Groups "golang-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/golang-dev/CAB%3Df9xT9%2BYHA5qT2GmUAoQ-ne_a8RWg4uRKDXwSgdn0M5RxdTA%40mail.gmail.com.
I too feel that stenciling would be *simpler* to implement. It is not clear to me if slow C++ compile time issues apply here. Presumably each unique concrete type or functions constructed out of generics can be cached?
To view this discussion on the web visit https://groups.google.com/d/msgid/golang-dev/CA7196F5-BC29-4DAD-AB61-279D75E1F4D7%40iitbombay.org.
On Sat, 19 Sep 2020, 06:07 Bakul Shah, <ba...@iitbombay.org> wrote:I too feel that stenciling would be *simpler* to implement. It is not clear to me if slow C++ compile time issues apply here. Presumably each unique concrete type or functions constructed out of generics can be cached?What do you mean by that?
On Sep 19, 2020, at 1:45 AM, minux <mi...@golang.org> wrote:On Sat, Sep 19, 2020 at 3:25 AM roger peppe <rogp...@gmail.com> wrote:On Sat, 19 Sep 2020, 06:07 Bakul Shah, <ba...@iitbombay.org> wrote:I too feel that stenciling would be *simpler* to implement. It is not clear to me if slow C++ compile time issues apply here. Presumably each unique concrete type or functions constructed out of generics can be cached?What do you mean by that?
I think it means that we can make our go build cache caching not only objects built from whole packages,but also unique instantiations of generic functions and methods.In fact, while I thought about this, we probably can split the objects into two parts: non-generic part andgeneric instantiations, while the latter will not be saved in the package object file, but as standaloneobject files that will be pulled in as necessary by the linker. This avoids the other code bloat problemof C++ templates, where the C++ compiler must be conservative and generate implementationfor all used template instantiations in the output object file for each source file and relying on the linkerto dedup them. As the Go compiler knows about the cache, it can check to see if the implementationalready exists before recreating it.
Of course, we still need to be able to inline generic functions/methods, so only those parts that can'tbe inlined should be stored separately in the build cache.Furthermore, such a caching system might be able to support a more generic form of deduplicationby making it a content addressable cache keyed by the object code & its distinguishing metadata(e.g. for structs, only the types of fields are necessary part of the key, the name of the fields can bediscarded.)This generalized deduplication is not limited to generic code though, if we split the package objectfiles up into meaningful smaller parts that are separately cached.
> My thoughts on it
We should not assume that if generics land, that they will only be used as areplacement for current uses of code generation or type assertions. Even afew higher-order functions could cause a binary size and compile-time blowupif they are used everywhere. Things like map/filter/fold, channel manipulationfunctions, or error handling helpers.
> Things like map/filter/fold, channel manipulationfunctions, or error handling helpers.
Didn't though about it indeed. Then the combined approachseems reasonable:1) Generic types and their methods are via stenciling.2) Generic functions with type list constraints are via stenciling too.3) Generic functions with "generic" constraints are dictionary based.This seems mostly OK for our needs (can't say for everyone of course):
On Sep 21, 2020, at 11:29 AM, roger peppe <rogp...@gmail.com> wrote:
--
You received this message because you are subscribed to the Google Groups "golang-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/golang-dev/CAJhgacj9Lyo1hJd6s1cnnxvXpbdQ-RafZSpBD%2B-ABgTU81Ymnw%40mail.gmail.com.
You mention recursive generic functions. This can become quite pathological if we're not careful about the rules.For example, here's a short program that generates over 300k different generic functions: https://go2goplay.golang.org/p/GjBIOAYc_uu
--
You received this message because you are subscribed to the Google Groups "golang-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/golang-dev/12a5df38-25a2-423f-bc3a-07f9dbb33555n%40googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/golang-dev/CAB%3Df9xSGuHG4%3DBk_KOzaf278DS%3DwiD-M0dWiNWr8Ljhg7M%2BwzQ%40mail.gmail.com.
> I'd hope for a hybrid: stenciling but sharing instantiations when they had the same GC bitmap shape.> This is what I'd expect too. It'll still need a dictionary so that you can invoke generic operations (there would be a runtime cost similar to the runtime cost of invoking methods on an interface because method calls would be indirect), but at least you can copy values around and look up items on the stack without extra cost.I've been thinking some more about this idea. Basically, we could have one implementation per GC shape, where GC shape includes the size, alignment, and pointer bitmap for each instantiated type.The great thing about this idea is that a lot of the dictionary complexity goes away. Stack frames are constant sized, and all of the stack layout and pointer map sections of the dictionaries are no longer needed.We'd still want other parts of the dictionaries, like the derived types and subdictionaries.I'm not sure how much this would buy us, though. It would deduplicate the code for f[int64] and f[uint64], but not f[int64] and f[string]. The deduplication we get would probably be very similar to what we would get with full stenciling + linker deduplication of identical bodies.
The only differing cases would be ones which did something "nonstandard", by which I mean creating a derived type or assigning a type parameter value to an interface{}. It's not clear to me that the additional complexity of runtime dictionaries is better than the additional complexity of linker deduplication.
> That said, to be clear, I think that the memory performance of a generic data structure has to be perfect. I think it's important that people be able to easily understand the memory requirements of their generic data structures.One place where this may not be true is escape analysis. Escape analysis without fully stenciling means that we have to make conservative assumptions about methods on generic types escaping their arguments. Not sure how often that would come up in practice, but it is a worry.
> Something that I haven't seen talked about much yet is how to deal with the requirement that the instantiations for a generic type must be seen before you can generate the code for that type. This surely has implications for module compilation: would the body of every generic method and function need to be exported as source like potentially inlined functions are exported today, or would there be some kind of intermediate language involved? (SSA?)Yes, we'll have to export full source code bodies for generic functions in object files (like we do for inlining).
> Are there any stats on how many different generic types/functions are used in Java / C++ programs? I am wondering about how much is "larger binaries" a real problem vs imagined.This paper describes a mechanism to remove duplicate code in C++. They find about 6% duplication, which isn't huge. There may be some survivorship bias there though (maybe people already avoid large blowups when writing their code).
--On Mon, Sep 21, 2020 at 11:55 AM 'Carla Pfaff' via golang-dev <golan...@googlegroups.com> wrote:--On Monday, 21 September 2020 at 17:33:07 UTC+2 rog wrote:You mention recursive generic functions. This can become quite pathological if we're not careful about the rules.For example, here's a short program that generates over 300k different generic functions: https://go2goplay.golang.org/p/GjBIOAYc_uuA cautionary tale on monomorphization:The recent Rust 1.46 release broke the compilation of Rust code in the Fuchsia project and many other projects, due to monomorphization blowup: https://github.com/rust-lang/rust/issues/54540#issuecomment-689163436They had to increase the "type_length_limit", which limits the maximum number of type substitutions made when constructing a concrete type during monomorphization [1], to over 18 million.
You received this message because you are subscribed to the Google Groups "golang-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/golang-dev/12a5df38-25a2-423f-bc3a-07f9dbb33555n%40googlegroups.com.
You received this message because you are subscribed to the Google Groups "golang-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/golang-dev/CAB%3Df9xSGuHG4%3DBk_KOzaf278DS%3DwiD-M0dWiNWr8Ljhg7M%2BwzQ%40mail.gmail.com.
On Fri, 25 Sep 2020, 16:58 'Keith Randall' via golang-dev, <golan...@googlegroups.com> wrote:> I'd hope for a hybrid: stenciling but sharing instantiations when they had the same GC bitmap shape.> This is what I'd expect too. It'll still need a dictionary so that you can invoke generic operations (there would be a runtime cost similar to the runtime cost of invoking methods on an interface because method calls would be indirect), but at least you can copy values around and look up items on the stack without extra cost.I've been thinking some more about this idea. Basically, we could have one implementation per GC shape, where GC shape includes the size, alignment, and pointer bitmap for each instantiated type.The great thing about this idea is that a lot of the dictionary complexity goes away. Stack frames are constant sized, and all of the stack layout and pointer map sections of the dictionaries are no longer needed.We'd still want other parts of the dictionaries, like the derived types and subdictionaries.I'm not sure how much this would buy us, though. It would deduplicate the code for f[int64] and f[uint64], but not f[int64] and f[string]. The deduplication we get would probably be very similar to what we would get with full stenciling + linker deduplication of identical bodies.Isn't there a very significant difference here? With full stenciling, all method calls on concrete parameter types will be direct (and inlineable). With the hybrid approach, that's not the case: since there's a dictionary, method calls are indirect and hence indistinguishable, so the compiler should be able to dedupe more, I think.
On Fri, Sep 25, 2020 at 3:47 PM roger peppe <rogp...@gmail.com> wrote:On Fri, 25 Sep 2020, 16:58 'Keith Randall' via golang-dev, <golan...@googlegroups.com> wrote:> I'd hope for a hybrid: stenciling but sharing instantiations when they had the same GC bitmap shape.> This is what I'd expect too. It'll still need a dictionary so that you can invoke generic operations (there would be a runtime cost similar to the runtime cost of invoking methods on an interface because method calls would be indirect), but at least you can copy values around and look up items on the stack without extra cost.I've been thinking some more about this idea. Basically, we could have one implementation per GC shape, where GC shape includes the size, alignment, and pointer bitmap for each instantiated type.The great thing about this idea is that a lot of the dictionary complexity goes away. Stack frames are constant sized, and all of the stack layout and pointer map sections of the dictionaries are no longer needed.We'd still want other parts of the dictionaries, like the derived types and subdictionaries.I'm not sure how much this would buy us, though. It would deduplicate the code for f[int64] and f[uint64], but not f[int64] and f[string]. The deduplication we get would probably be very similar to what we would get with full stenciling + linker deduplication of identical bodies.Isn't there a very significant difference here? With full stenciling, all method calls on concrete parameter types will be direct (and inlineable). With the hybrid approach, that's not the case: since there's a dictionary, method calls are indirect and hence indistinguishable, so the compiler should be able to dedupe more, I think.I guess it depends on whether you think "any" will be the most common type constraint, or something more restrictive. "any" code is easy to dedupe.
More constrained types (where that constraint is actually used) are harder. I don't think we really know which will end up being more common, but it seems my hunch is different than yours...
On Sat, 26 Sep 2020, 00:08 Keith Randall, <k...@google.com> wrote:On Fri, Sep 25, 2020 at 3:47 PM roger peppe <rogp...@gmail.com> wrote:On Fri, 25 Sep 2020, 16:58 'Keith Randall' via golang-dev, <golan...@googlegroups.com> wrote:> I'd hope for a hybrid: stenciling but sharing instantiations when they had the same GC bitmap shape.> This is what I'd expect too. It'll still need a dictionary so that you can invoke generic operations (there would be a runtime cost similar to the runtime cost of invoking methods on an interface because method calls would be indirect), but at least you can copy values around and look up items on the stack without extra cost.I've been thinking some more about this idea. Basically, we could have one implementation per GC shape, where GC shape includes the size, alignment, and pointer bitmap for each instantiated type.The great thing about this idea is that a lot of the dictionary complexity goes away. Stack frames are constant sized, and all of the stack layout and pointer map sections of the dictionaries are no longer needed.We'd still want other parts of the dictionaries, like the derived types and subdictionaries.I'm not sure how much this would buy us, though. It would deduplicate the code for f[int64] and f[uint64], but not f[int64] and f[string]. The deduplication we get would probably be very similar to what we would get with full stenciling + linker deduplication of identical bodies.Isn't there a very significant difference here? With full stenciling, all method calls on concrete parameter types will be direct (and inlineable). With the hybrid approach, that's not the case: since there's a dictionary, method calls are indirect and hence indistinguishable, so the compiler should be able to dedupe more, I think.I guess it depends on whether you think "any" will be the most common type constraint, or something more restrictive. "any" code is easy to dedupe.Not entirely: if an "any" type is converted to an interface type, the code will need the actual type, so that code can't be deduped AFAICS. That might turn out quite common (eg logging statements, sprintf "%T", use of legacy non-generic APIs).
Once we get a register ABI working, we'll also need to worry about whether a function parameter is float or int.
To view this discussion on the web visit https://groups.google.com/d/msgid/golang-dev/CAHOpXeVBHUx7X-GTeNpuwts2GfiwjdcOd3qhkN3qHKofFehS4w%40mail.gmail.com.
On Fri, 25 Sep 2020, 18:27 'David Chase' via golang-dev, <golan...@googlegroups.com> wrote:Once we get a register ABI working, we'll also need to worry about whether a function parameter is float or int.I said "you'd need to have a ternary pointer/float/other layout map, I think, but not much else changes" but then I realised that perhaps one doesn't always need to distinguish float from other data - it depends on how the ABI treats structs. For example, would struct{a, b float64} be passed as two float registers or not? If not, then perhaps you'd only need to distinguish floats from other data if the parameter type is exactly float64 or float32 (or complex? is complex treated just like a struct in this respect?) In a brief scan of the ABI proposal document, I didn't see any discussion of how structs are passed.
--
You received this message because you are subscribed to the Google Groups "golang-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/golang-dev/CALgmw1-6QJ_Skfi10npwF_E2a0WUBXac9gCp9uSZSypRUKy6KA%40mail.gmail.com.
Just a couple of thoughts from a random community member, if the 100 %
stencilling approach can--even theoretically--significantly slow down
compilation, like in rog@'s example, then I don't think it is the way
to go. After working for a bit with some large C++ code bases and some
smaller Rust projects in the past, I started to appreciate Go's current
compile speed even more.
The 100 % dictionary approach or some sort of a hybrid approach will
probably work better. The runtime cost--imo--won't be that bad
and probably won't matter that much, especially in the type of tasks
people use Go the most (backend services and command line utilities).
And if some project actually ends up with a bottleneck in the generic
code, they can always just generate a “stencilled” implementation.
--
You received this message because you are subscribed to the Google Groups "golang-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/golang-dev/CAJhgacj_kuD7mVJK_QOiCO-x7Na_QJSNhnxpi%2BSB0%3DJ8UN2iSQ%40mail.gmail.com.
At the callsite to g from f, f has no way to know what dictionary it should use, because the type parameterizing the instantiation of g is a generic type. So the caller of f must provide that dictionary.
Recursion - can a dictionary ever reference itself? How do we build it, and the corresponding proto-dictionaries, then? I haven’t wrapped my head around the cases in which this could come up.