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> 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 <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+unsubscr...@googlegroups.com > <mailto:golang-nuts+unsubscr...@googlegroups.com>. > For more options, visit https://groups.google.com/d/optout > <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.
