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/e60b85f7-33b7-4841-bf79-b81e3ac1d36en%40googlegroups.com.
