Oh i understand. Thank you for your detailed and kind reply!! Best regards. On Thursday, September 14, 2023 at 4:02:44 PM UTC+9 dmerc...@google.com wrote:
> Apologies for my `X / (C2 / C1)`, and thanks Marja for pointing it out :) > > > What steps can I take to validate the investment in optimization (cost > of optimization)? I'm curious if there are specific benchmarks you rely on > or if there are alternative methods. > > In general, I'd recommend talking to us before spending months > implementing an optimization that could turn out to not be worth it. > > If you have an optimization ready and you want to benchmark it, you can > look at its impact on JetStream2 and Speedometer2: performance of the > generated code will be correlated to the score of these benchmarks, and the > cost of running the optimization can be obtained by using the --turbo-stats > flag. Depending on what the optimization does, using micro-benchmarks (or > any other benchmark) to prove its usefulness can also be acceptable. > > Best, > Darius > > > > On Thursday, September 14, 2023 at 3:35:10 AM UTC+2 doit_man wrote: > >> I appreciate your helpful responses. >> >> It's evident that implementing optimizations in TurboFan entails careful >> consideration of potential unsafe scenarios. >> >> I now recognize the significance of TurboFan's compilation time. >> >> What steps can I take to validate the investment in optimization (cost of >> optimization)? I'm curious if there are specific benchmarks you rely on or >> if there are alternative methods. >> >> Thank you >> >> On Wednesday, September 13, 2023 at 6:28:30 PM UTC+9 Leszek Swirski wrote: >> >> This (in both cases) is a trivially unsafe transformation though (if >> applied without any range analysis), since you can have: >> >> X = MaxFloat64 >> C1 = 2 >> C2 = 4 >> >> (X*C1)/C2 = (MaxFloat64 * 2) / 4 = Infinity / 4 = Infinity >> X*(C1/C2) = MaxFloat64 * (2 / 4) = MaxFloat64 * 0.5 = whatever half of >> MaxFloat64 is >> >> On Wed, 13 Sept 2023, 10:57 'Marja Hölttä' via v8-dev, < >> v8-...@googlegroups.com> wrote: >> >> > > ```(X * C1) / C2 —> X / (C2 / C1)``` >> > You probably meant "X * (C2 / C1)" instead of "X / (C2 / C1)". >> >> Nah they probably meant just that. (X * 2) / 10 is X / (10 / 2) aka X / >> 5, not X * (10 / 2) aka X * 5. >> >> It would be the same as X * (C1 / C2) though, that's another possible >> simplification (if things don't overflow and so on). >> >> >> >> On Wed, Sep 13, 2023 at 9:43 AM 'dmerc...@google.com' via v8-dev < >> v8-...@googlegroups.com> wrote: >> >> Hi, >> >> In general, LLVM and ahead-of-time compilers have all the time in the >> world to optimize a function, while Turbofan tries to save every >> millisecond it can (it's not quite true: LLVM also tries to compile >> somewhat quickly, but it's orders of magnitude slower that Turbofan). As a >> result, Turbofan does fewer optimizations than LLVM, in particular when >> they have non-linear cost. That being said, Turbofan is not set in stone, >> and we are always happy to add new optimizations, provided that their cost >> can be justified by the improvements in generated code. >> >> > ```(A&B)|(A&C) —> A&(B|C)``` >> Optimizations such as this one are fairly cheap and straight-forward to >> implement. I'm guessing that the reason for their absence is that we didn't >> think about them or didn't see a specific case where they would improve the >> generated code. Feel free to submit patch to add them to >> Turboshaft's MachineOptimizationReducer ( >> https://source.chromium.org/chromium/chromium/src/+/main:v8/src/compiler/turboshaft/machine-optimization-reducer.h >> ). >> >> > ```(X * C1) / C2 —> X / (C2 / C1)``` >> You probably meant "X * (C2 / C1)" instead of "X / (C2 / C1)". Such >> mistakes are a good argument against implementing such optimizations unless >> we see a clear use-case: if they are wrong but almost never used, then they >> might cause random crashes (or security issues) that would be very hard to >> debug. >> Additionally, this simplification could be invalid depending on >> multiplication overflow, integer division and floating point >> approximations, which once again could easily introduce subtle bugs. >> >> > ```A+B --> A|B``` provided that A and B have no overlapping bits set. >> This one as well, I'm not sure we'd really want. First, it's probably >> rare that we know for a fact that 2 values don't have overlapping bits. And >> second, on most architectures that we support, an addition and a bitwise or >> have the same latency and throughput. >> >> Best, >> Darius >> >> >> On Wednesday, September 13, 2023 at 6:51:18 AM UTC+2 doit_man wrote: >> >> Hi v8 developers, >> >> I’m curious about the specific optimizations that TurboFan currently not >> support. >> >> Other ahead-of-time (AOT) compilers perform a wide range of >> optimizations, while TurboFan comparatively has fewer. >> >> >> For instance, the LLVM compiler employs optimization rules such as ```A+B >> --> A|B``` provided that A and B have no overlapping bits set. >> >> Similarly, ```(A&B)|(A&C) —> A&(B|C)``` and ```(X * C1) / C2 —> X / (C2 / >> C1)``` are examples of optimizations present in LLVM but absent in TurboFan. >> >> I think these kinds of rules could enhance TurboFan’s optimization >> capabilities. >> >> I’m interested in understanding whether this absence is due to TurboFan’s >> current state of implementation, inherent limitations of a just-in-time >> (JIT) compiler, or if there are other factors at play. >> >> >> Thanks. >> >> -- >> -- >> v8-dev mailing list >> v8-...@googlegroups.com >> 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 v8-dev+un...@googlegroups.com. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/v8-dev/9fcd075d-14b8-41f5-a793-7ddee3f4e322n%40googlegroups.com >> >> <https://groups.google.com/d/msgid/v8-dev/9fcd075d-14b8-41f5-a793-7ddee3f4e322n%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> >> >> >> -- >> >> Google Germany GmbH >> >> Erika-Mann-Straße 33 >> >> 80636 München >> >> >> Geschäftsführer: Paul Manicle, Liana Sebastian. >> >> Registergericht und -nummer: Hamburg, HRB 86891 >> >> Sitz der Gesellschaft: Hamburg >> >> >> Diese E-Mail ist vertraulich. Falls sie diese fälschlicherweise erhalten >> haben sollten, leiten Sie diese bitte nicht an jemand anderes weiter, >> löschen Sie alle Kopien und Anhänge davon und lassen Sie mich bitte wissen, >> dass die E-Mail an die falsche Person gesendet wurde. >> >> >> >> This e-mail is confidential. If you received this communication by >> mistake, please don't forward it to anyone else, please erase all copies >> and attachments, and please let me know that it has gone to the wrong >> person. >> >> -- >> -- >> v8-dev mailing list >> v8-...@googlegroups.com >> 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 v8-dev+un...@googlegroups.com. >> >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/v8-dev/CAED6dUCqPdxtE%2BGhbHfOvs5xeSauVZ5R9EXeutOOiZ%2BP4NdMqg%40mail.gmail.com >> >> <https://groups.google.com/d/msgid/v8-dev/CAED6dUCqPdxtE%2BGhbHfOvs5xeSauVZ5R9EXeutOOiZ%2BP4NdMqg%40mail.gmail.com?utm_medium=email&utm_source=footer> >> . >> >> -- -- v8-dev mailing list v8-dev@googlegroups.com 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 v8-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/v8-dev/2c03a763-1cbb-4b4c-acf2-c0ac18f6ea15n%40googlegroups.com.
