Sorry I didn't make it clear, suppose that `func` is a function that we want to transform, which contains the following statements
f(g1(), g2(), g3()); Suppose that g1,g2,g3 are all async, and we the the return values of them. Without the transformation, there's no point to store the return value of g*() into HEAP, but now suppose that g2() is called after g1(), we need to save the value of g1() before g2(), and restore it afterwards. Also note that g*() could be both sync or async, e.g. if(rand() % 2) emscripten_sleep(); And we want the sync case to be as fast as before, so we don't want to always save g*() to HEAP. Does this make sense? For the optimization, I think so, but not 100% sure about the cases you mentioned. Maybe you can do some experiments. regards, - Lu On Mon, Jul 28, 2014 at 6:10 PM, Sören Balko <[email protected]> wrote: > > On 29 Jul 2014, at 11:02, Lu Wang <[email protected]> wrote: > > Regarding return values: consider f(g()), where would you store the return > value of g() ? > > > Not at all - why would I want to store it? My understanding is that > somewhere in g, there is a call to emscripten_sleep(). Hence you need to > store all local variables of g and f that are declared and initialised > before that. The return value of g is only produced after > emscripten_sleep() returns - hence no need to store it. Or am I overlooking > something. > > > If you compile a normal c code with local primitive variables, you would > probably see that most local variables are NOT stored in the HEAP. In your > previous example you were using structures, but normally local variables > are mostly integers or pointers. > E.g. > ``` > int s = 0; > for(int i = 0; i < 100; ++i) s += i; > ``` > > I remember that putting local variables to HEAP is slower than in > registers, also it is costly to iterating all the local variables, and I do > want to avoid that if possible, but I don't want it affect the performance > of the sync cases. > > > Fair point - I do not know if elements of a typed array (which is the > representation of the HEAP array), are ever cached in registers. Portions > of the array reside in a nearline CPU cache, but - admittedly - not > necessarily in registers. > > Btw, do you also perform some data flow analysis to limit the number of > to-be-saved local variables? I mean, you wouldn’t need to save local > variables which were *only* used before the emscripten_sleep() call, but > not after it. Same is true for local variables that are only used after > emscripten_sleep() returns (like in case of the return value). > > > > regards, > - Lu > > > On Mon, Jul 28, 2014 at 5:43 PM, Soeren Balko <[email protected]> wrote: > >> I am not entirely sure why you would need to save return values, as >> producing that value and exiting from the function happens concurrently, >> i.e., there is no room for an asynchronous break-out to >> emscripten_sleep(...) in between, no? >> >> But regardless of all that - I think that instead of creating local >> variables in the resulting Javascript function, you *could* as well place >> all local variables in a continuous region in the asm.js HEAP array (as it >> already happens to any variables, which cannot be represented as an >> asm.js-compliant Javascript variable). Once all local variables are >> represented in this manner, saving them is as simple as remembering the >> current value of STACKTOP. The offset of the variables on the stack (HEAP >> array) is static information that is fixed at compile time (essentially, >> offsets from the current stack frame), i.e., no extra runtime effort is >> needed when restoring the local variables. >> >> But anyhow: that's an optimization only - perhaps saving all the >> variables by iteratively copying their values somewhere isn't all that >> costly. >> >> Soeren >> >> >> On Monday, July 28, 2014 1:55:36 PM UTC+10, 王璐 wrote: >> >>> That's not completely correct, some are not stored in the heap/stack, >>> for example, return values of functions called, or phi nodes. >>> >>> >>> On Sun, Jul 27, 2014 at 8:53 PM, Sören Balko <[email protected]> wrote: >>> >>>> At compile time: there were no reall local variables any more, >>>> everything was in the HEAP array, starting at the address represented by >>>> STACKTOP. A function scope was no real JS object but merely a continuous >>>> range of bytes in the HEAP array. >>>> >>>> Am 28 Jul 2014 um 1:44 pm schrieb Lu Wang <[email protected]>: >>>> >>>> How could you create the scope object with all the necessary local >>>> variables, without traversing all of them? >>>> >>>> -- >>>> You received this message because you are subscribed to a topic in the >>>> Google Groups "emscripten-discuss" group. >>>> To unsubscribe from this topic, visit https://groups.google.com/d/ >>>> topic/emscripten-discuss/kSMH2N0CoLg/unsubscribe. >>>> To unsubscribe from this group and all its topics, send an email to >>>> [email protected]. >>>> For more options, visit https://groups.google.com/d/optout. >>>> >>>> >>>> -- >>>> You received this message because you are subscribed to a topic in the >>>> Google Groups "emscripten-discuss" group. >>>> To unsubscribe from this topic, visit https://groups.google.com/d/ >>>> topic/emscripten-discuss/kSMH2N0CoLg/unsubscribe. >>>> To unsubscribe from this group and all its topics, send an email to >>>> [email protected]. >>>> For more options, visit https://groups.google.com/d/optout. >>>> >>> >>> >> -- >> You received this message because you are subscribed to a topic in the >> Google Groups "emscripten-discuss" group. >> To unsubscribe from this topic, visit >> https://groups.google.com/d/topic/emscripten-discuss/kSMH2N0CoLg/unsubscribe >> . >> To unsubscribe from this group and all its topics, send an email to >> [email protected]. >> For more options, visit https://groups.google.com/d/optout. >> > > > -- > You received this message because you are subscribed to a topic in the > Google Groups "emscripten-discuss" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/emscripten-discuss/kSMH2N0CoLg/unsubscribe > . > To unsubscribe from this group and all its topics, send an email to > [email protected]. > For more options, visit https://groups.google.com/d/optout. > > > Soeren Balko, PhD > Founder & Director > zfaas Pty Ltd > Brisbane, QLD > Australia > > > > -- > You received this message because you are subscribed to a topic in the > Google Groups "emscripten-discuss" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/emscripten-discuss/kSMH2N0CoLg/unsubscribe > . > To unsubscribe from this group and all its topics, send an email to > [email protected]. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "emscripten-discuss" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
