On Thursday, July 29, 2021 at 3:22:35 AM UTC-4 axel.wa...@googlemail.com wrote:
> FWIW I did take a look at the output (I ended up curious enough): > https://go.godbolt.org/z/WK8xYd1E3 > > Insert and Insert2 generate pretty different code. In particular, Insert2 > uses makeslicecopy, to fold the `make` and the `copy(s2, a)` (avoiding > having to zero the relevant memory). `Insert` uses makeslice and a memmove > for the `copy(s2, s[:k])`. > > I assume that's because the compiler can easily prove that `len(s2) == > len(a)+len(b)+len(c) > len(a)`, therefore it sees that the `copy` actually > copies all of `a`. For `Insert`, it needs to do extra bounds checks. > > So, looking at this output might've answered your question before posting > it. It certainly would've provided helpful context for anyone trying to > explain the behavior who isn't a domain expert in how the compiler > optimizes things like this. i.e. it certainly would've increased the > likelihood that any questions remaining *will* get an answer. > I also found elements of s2[:len(a)] are not reset. This could explain why Insert2 is faster than Insert. However, this doesn't answer why Insert2 is less performant than Insert when N == 16384. > > On Thu, Jul 29, 2021 at 8:08 AM Axel Wagner <axel.wa...@googlemail.com> > wrote: > >> It would have taken you less time to look at the generated code and/or a >> CPU profile than it would have to post this - let alone the rest of the >> discussion. I also believe it likely would take more time to type out the >> answer to your question, than it would for you to look at the generated >> code and/or a CPU profile. So no, I reject your reasoning that this is more >> convenient. Even *if* it saves time in absolute terms (i.e. even *if* >> someone can send an answer faster than you could do these most basic >> checks), it's still a tradeoff between taking up *your* time and taking up >> *their* time. It's still rude. >> >> I also reject your reasoning that "golang-nuts is for communication". >> There are clear and written limitations on that (in the form of the CoC) >> and also unwritten limitations (otherwise we'd get constant >> recruiter-spam). If multiple people ask you to do a bit more research >> yourself before asking these questions, it's an indicator that you are >> stepping closer to these unwritten limitations. You should at least take >> them seriously. >> >> Lastly, it's, again, not like your questions are not *interesting*. I'd >> likely want to read about them, based on the topic. I'm generally >> interested in optimizations and compiler internals. But I would prefer them >> to be pre-filtered to actual conundrums, instances where I can reasonably >> help or learn something new. So, IMO, it would also be in your best >> interest to do this. Not only do you learn more about investigating these >> things, you also will likely increase the usefulness of the answers, if >> people *don't* just discard your message as "oh, it's one of these again". >> >> Anyways. To repeat this one last time: I'd respectfully ask you to >> conduct a little bit more reasearch on your own, before sending these >> mails. Namely look at the generated code (the Compiler Explorer >> <https://go.godbolt.org/> makes this really simple) and look at the >> relevant profiling information (this blog post >> <https://blog.golang.org/pprof>, while a little dated, still gives a >> good intro). I genuinely think this is more helpful advice than trying to >> answer your question. >> >> On Thu, Jul 29, 2021 at 5:24 AM tapi...@gmail.com <tapi...@gmail.com> >> wrote: >> >>> >>> >>> On Wednesday, July 28, 2021 at 10:42:58 PM UTC-4 Kurtis Rader wrote: >>> >>>> On Wed, Jul 28, 2021 at 7:24 PM tapi...@gmail.com <tapi...@gmail.com> >>>> wrote: >>>> >>>>> I will when I confirm that no one could give an answer without much >>>>> effort. If you feel frustrated, you can ignored it. ;D >>>>> >>>> >>>> Like Axel, I too am mildly annoyed by your questions. Primarily because >>>> you don't seem to understand that the Go community isn't your private >>>> unpaid research team and every time you start one of these threads you >>>> omit >>>> important facts. Also, you don't seem to understand why things like the >>>> CPU >>>> architecture, cache line size, L1 & L2 cache sizes, and similar factors >>>> are >>>> frequently significant for the types of questions you keep asking. >>>> Frankly, >>>> as Axel pointed out, you should be figuring out the answer and sharing >>>> your >>>> findings with the community. >>>> >>> >>> The go-nuts community is for communicating, right? >>> I think it is not hard to ignore the uninterested topics. >>> >>> I will figure out the answer with as less effort as possible. >>> If someone happens knows the answer, I'm very appreciated. >>> If no one could give a confirmed answer, then I will seek other routes. >>> >>> >>>> >>>> -- >>>> Kurtis Rader >>>> Caretaker of the exceptional canines Junior and Hank >>>> >>> -- >>> 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/74c0a27f-0e3e-4ee6-937b-67bf36dd8ae2n%40googlegroups.com >>> >>> <https://groups.google.com/d/msgid/golang-nuts/74c0a27f-0e3e-4ee6-937b-67bf36dd8ae2n%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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/a34ecafb-7ba3-4153-95cb-6b92dae155a2n%40googlegroups.com.
