On 29 Jul 2014, at 11:19, Lu Wang <[email protected]> wrote: > 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?
It does - in case of the f(g1(), g2(), g3()) example. Even though I still do not see why you would need to store the result of rand() in the other example. It is only ever used _before_ you call emscripten_sleep() and never after this. Why would you need to restore it after the asynchronous callback from emscripten_sleep(). I mean if the code would still need it, it had to explicitly assign it to some local variable, no? > > > > For the optimization, I think so, but not 100% sure about the cases you > mentioned. Maybe you can do some experiments. I will, by manually modifying the example I posted yesterday. > > > 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 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 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.
