On Wed, Sep 23, 2020 at 1:10 AM cs.ali...@gmail.com <cs.alikoyu...@gmail.com> wrote: > > I am not actually questioning the current design, as you both said it is not > a good practice to call a return statement as I wrote above, I am trying to > understand the relation between memory, interface and order of evaluation. It > is clear that the compiler takes account of whether a return statement is an > interface or a struct and the memory size of the returned value, If I return > a struct rather than an interface, it changes the order, If I add fields to > the structs it changes the order. Is there a paper that I can find why the > compiler considers them for ordering, why it is important for performance or > anything else?
I'm not aware of any paper specific to the Go compiler. I find it most useful to consider a compiler as creating a set of constraints derived from the input based on the language semantics. These are constraints like in "a = b; b = c" the read of b in the first assignment must be completed before the store to b in the second assignment. Once the set of constraints is created, the compiler must solve those constraints given an instruction architecture including a set of registers. The goal is to optimize execution time while minimizing compilation time without violating any constraints. Because compilation time matters, compilers do not fully analyze all possible solutions; instead, when it comes to things like memory load/store order, instruction selection, and register allocation, they are full of heuristics that tend to give good results in practice. When you view a compiler in that way, a question like "why does adding fields to a struct change the order of memory loads and stores" becomes uninteresting. The reason has to do with the details of all the constraints that applied while compiling that particular package. There is no rule that says "if the struct has more fields, do this." It's just that the set of heuristics happened to produce a particular result. Changing some other piece of code in some other part of the package might produce a different result. Or a different version of the compiler might apply different heuristics and get different results. Ian -- 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/CAOyqgcX__%2BKDDnzQ2LjuYm-1gMdrQy%3DLoNB0MmMj%3DaTGJPAF1A%40mail.gmail.com.
