Yes, the return value of rand() should not be saved, is there anything confusing?
On Mon, Jul 28, 2014 at 6:26 PM, Sören Balko <[email protected]> wrote: > > 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 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.
