Another way to understand the general topic is by comparison to Lindenmayer systems. The compiler is an iterated rewrite framework and the exact code that you get can be a surprise the same way L-System graphics vary.
On Thu, Sep 24, 2020 at 10:36 PM cs.ali...@gmail.com < cs.alikoyu...@gmail.com> wrote: > I understood perfectly now, thanks for the explanations and the link! I > really appreciate you guys! > > On Thursday, September 24, 2020 at 3:28:10 AM UTC+3 Ian Lance Taylor wrote: > >> On Wed, Sep 23, 2020 at 1:10 AM cs.ali...@gmail.com >> >> >> <cs.ali...@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/b2aa2ac3-a7da-4415-9534-7076551da5e7n%40googlegroups.com > <https://groups.google.com/d/msgid/golang-nuts/b2aa2ac3-a7da-4415-9534-7076551da5e7n%40googlegroups.com?utm_medium=email&utm_source=footer> > . > > > -- *Michael T. jonesmichael.jo...@gmail.com <michael.jo...@gmail.com>* -- 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/CALoEmQxuSfsGaiExNCdvHZcYkZn9qKZxD3i_yhzct4PFoz9U-Q%40mail.gmail.com.
