int<->uint conversions should never generate any machine code. They are free.
On Saturday, November 24, 2018 at 10:55:50 AM UTC-8, Andy Balholm wrote: > > There is nothing in the language spec that guarantees anything about > performance. But if logic tells you that it should be a no-op, and > examination of the generated code shows you that it is a no-op in the cases > you tested, you can safely assume that it is not going to be an issue for > your program’s performance. > > Andy > > On Nov 24, 2018, at 8:45 AM, Ugorji Nwoke <ugo...@gmail.com <javascript:>> > wrote: > > Thanks so much Silviu. I love this tool - I had seen it before, but didn't > realize it also supported go language. Thanks so much for bringing it up - > it should help me do more investigation on my own faster. > > I used it to compare the asm output, and I got the same thing as when I > did > go build -gcflags "-S" num_conversion.go > > i.e. it leads me to conclude, as I suspected, that conversion from int to > uint is free (no-op at runtime). > > However, I get concerned that my proof may be insufficient, or there may > be other reason why the asm looks same, and that is why I wanted a > definitive answer from someone familiar with the internals. > > > On Saturday, November 24, 2018 at 11:28:43 AM UTC-5, Silviu Capota Mera > wrote: >> >> A very nice tool from Matt Godbolt (and team of volunteers): >> https://godbolt.org/z/4nt5cJ >> >> You can switch compiler version (e.g. Go 1.4, 1.7, 1.9, 1.11, tip, etc) >> and/or gccgo, take a look at variations, etc >> >> On Saturday, 24 November 2018 11:07:51 UTC-5, Jan Mercl wrote: >>> >>> On Sat, Nov 24, 2018 at 4:31 PM Ugorji Nwoke <ugo...@gmail.com> wrote: >>> >>> > Jan, you and I have the same understanding i.e. float <-> int is >>> obviously non-free, but I can't think of why int <-> uint will not be free. >>> However, I want someone with knowledge of the >>> > compiler/runtime/codegeneration/SSA internals that can give me a >>> definitive answer. >>> >>> Any correct compiler is an implementation of the language specification. >>> From the language specification it follows that the compiler _may_ check >>> that - for example - 42 != 314 or 278 == 278 while performing the 'uint' >>> <-> 'int" conversion. It may also try to factor M4170639287. The question >>> is why to do so when nothing of that is mandated by the language >>> specification for a correct implementation? >>> >>> The next reasonable step is to assume Occam's razor is a thing. >>> >>> -- >>> >>> -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 <javascript:>. > For more options, visit https://groups.google.com/d/optout. > > > -- 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. For more options, visit https://groups.google.com/d/optout.
