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/CAGRskv9VcuFPri7y6SBr2dbzQYPBP%2B1wsbmHm_YFs7p-w7_GCA%40mail.gmail.com.
