Hi, I have an additional question if you don't mind. What happens if I call %GetOptimizationStatus(fn) and the nodes that are part of fn are dead-eliminated? I suspect it will return kTurboFanned if the block function was optimized regardless of whether some nodes were eliminated, but what if the entire function node was "eliminated"?
I tried to simulate a function where some branches could be eliminated by the compiler and the results I got by getting the optimization status after each 1000 iterations were kTurboFanned & kInterpreted. I might have answered my own question, but I wanted to double-check anyway. Thanks in advance! Em segunda-feira, 9 de setembro de 2024 às 13:52:41 UTC-3, Rafael Gonzaga escreveu: > Alright. I understand. > > Thank you for taking the time to answer it > > Cheers, > > Rafael Gonzaga > > Em segunda-feira, 9 de setembro de 2024 às 12:22:04 UTC-3, > [email protected] escreveu: > >> On Mon, Sep 9, 2024 at 1:57 PM Rafael Gonzaga <[email protected]> >> wrote: >> >>> We have previously considered using %DoNotOptimize or even >>> %OptimizeOnNextCall (to ensure a proper warmup). But, we concluded that it >>> won't be realistic as some modules might be very well optimized and some of >>> them will be full of deoptimization. Doing so, we've assumed both would be >>> equally _efficient_ which might not be true. >>> >> >> Your call -- fwiw this is how I'd measure it though, because I'd rather >> introduce some measurable systematic inefficiency like DoNotOptimize than >> unpredictable optimization like this example. In all honesty, you're >> running a microbenchmark, so realism is anyway out of the window; I >> would personally focus more on stability and repeatability. >> >> >>> Does V8 trigger any event on dead-code elimination where I could >>> intercept? static probes, for instance. Otherwise, I can manually patch >>> https://github.com/nodejs/node/tree/main/deps/v8 to do so. However, I >>> assume is not that simple, right? >>> >> >> Your assumption is right, it's not that simple -- the dead code >> elimination works on a lower level than you'd be thinking in JS -- it >> doesn't process JS basic blocks or loops, removing entire blocks in a way >> that is interceptable. Rather, the compiler transforms the JS into a graph, >> and expands and trims nodes in that graph. The dead code elimination could >> almost be considered a side effect of various other optimisations, like, >> say, branch elimination, and it fires for a _lot_ of the intermediate >> generated nodes. Trying to interpret any sort of hook into that would be no >> better than trying to interpret turbolizer. >> >> >>> - Rafael Gonzaga >>> >>> Em segunda-feira, 9 de setembro de 2024 às 06:49:29 UTC-3, >>> [email protected] escreveu: >>> >>>> Hi Rafael, >>>> >>>> It's not easy to analyze optimizations with turbolizer, it's intended >>>> more as a compiler developer tool than an end-user tool. Even if you did, >>>> you might be disappointed if the current benchmark is fine and nothing is >>>> eliminated right now, but a future iteration of Turbofan/shaft ends up >>>> eliminating that loop because of some new analysis. In particular, if we >>>> were to detect that structuredClone has no side-effects, we could >>>> theoretically collapse your loop to just execute the last iteration. >>>> >>>> You're probably better off using some intrinsics >>>> (--allow-natives-syntax) to ensure that the object escapes, and make sure >>>> that it escapes on each iteration (and then maybe compare that against a >>>> loop that does nothing). For example, you could write >>>> >>>> function DoNotOptimize(x) {} >>>> >>>> // Prevent DoNotOptimize from optimizing or being inlined. >>>> >>>> %NeverOptimize(DoNotOptimize); >>>> >>>> ... >>>> >>>> for (let i = 0; i < n; ++i) >>>>> DoNotOptimize(structuredClone(blob)); >>>>> >>>> >>>> This would be similar to DoNotOptimize in the google C++ benchmarking >>>> library >>>> <https://github.com/google/benchmark/blob/main/docs/user_guide.md#:~:text=DoNotOptimize(%3Cexpr%3E)%20forces%20the%20result%20of%20%3Cexpr%3E%20to%20be%20stored%20in%20either%20memory%20or%20a%20register.> >>>> . >>>> >>>> - Leszek >>>> >>>> On Tue, Sep 3, 2024 at 11:24 PM Rafael Gonzaga <[email protected]> >>>> wrote: >>>> >>>>> Hi folks! >>>>> >>>>> I'm member of Node.js team and I'm conducting a research on our >>>>> benchmark suite (https://github.com/nodejs/node/tree/main/benchmark). >>>>> >>>>> In our benchmarks, we attempt to avoid the measured block from being >>>>> eliminated by V8 dead-code elimination by making use of a state and >>>>> checking the state after the benchmark run. Example: >>>>> https://github.com/nodejs/node/blob/main/benchmark/blob/clone.js#L24 >>>>> >>>>> However, this is an assumption, we do not check if the measured block >>>>> is being eliminated so, the benchmark result will be noop or we are >>>>> measuring it correctly. I tried to run the benchmark with --trace-turbo >>>>> and >>>>> analyzing it with tools/turbolizer, but I couldn't find a way to identify >>>>> which blocks were removed. >>>>> >>>>> Is there a way to do that? I understand that usually micro-benchmarks >>>>> are far from reliable, but at the moment I don't see how we could make it >>>>> more sophisticated and specific. >>>>> >>>>> Thanks in advance >>>>> >>>>> -- >>>>> -- >>>>> v8-dev mailing list >>>>> [email protected] >>>>> http://groups.google.com/group/v8-dev >>>>> --- >>>>> You received this message because you are subscribed to the Google >>>>> Groups "v8-dev" group. >>>>> To unsubscribe from this group and stop receiving emails from it, send >>>>> an email to [email protected]. >>>>> To view this discussion on the web visit >>>>> https://groups.google.com/d/msgid/v8-dev/4e060cb2-477c-4037-876a-bd2f5aab245fn%40googlegroups.com >>>>> >>>>> <https://groups.google.com/d/msgid/v8-dev/4e060cb2-477c-4037-876a-bd2f5aab245fn%40googlegroups.com?utm_medium=email&utm_source=footer> >>>>> . >>>>> >>>> -- >>> -- >>> v8-dev mailing list >>> [email protected] >>> http://groups.google.com/group/v8-dev >>> --- >>> You received this message because you are subscribed to the Google >>> Groups "v8-dev" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to [email protected]. >>> >> To view this discussion on the web visit >>> https://groups.google.com/d/msgid/v8-dev/9a3745a6-8515-4d17-b7b1-ed053da1c2b2n%40googlegroups.com >>> >>> <https://groups.google.com/d/msgid/v8-dev/9a3745a6-8515-4d17-b7b1-ed053da1c2b2n%40googlegroups.com?utm_medium=email&utm_source=footer> >>> . >>> >> -- -- v8-dev mailing list [email protected] http://groups.google.com/group/v8-dev --- You received this message because you are subscribed to the Google Groups "v8-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/v8-dev/3381ba55-6db0-4173-97bc-e3b1c66f6bd5n%40googlegroups.com.
