Thanks Keith - this is what I was looking for. On Saturday, November 24, 2018 at 6:49:33 PM UTC-5, Keith Randall wrote: > > 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> 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. >> 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.
