> On Jun 19, 2020, at 9:53 AM, Alexey Proskuryakov <a...@webkit.org > <mailto:a...@webkit.org>> wrote: > > > >> 18 июня 2020 г., в 9:30 PM, Saam Barati <sbar...@apple.com >> <mailto:sbar...@apple.com>> написал(а): >> >> Why are we insisting on doing something on the bots that takes ~10x longer >> to run than necessary? I’d rather have that time spent running more tests. > > Replying to this point specifically, I wanted to point out that WebKit tests > take 2x longer in debug, not 10x longer. JSC tests take 3.6x longer.
Since I collected real data on this last night on the actual bot that runs the JSC stress tests, I’ll share the data here: Build time A clean build using buid-jsc for a normal Debug build on bot638 takes about 4.5 minutes. A clean build using build-jsc for a --force-opt=O3 Debug build on bot638 takes about 6 minutes. Test run time Running with a regular Debug build, the test completed in about 4 hours 41 minutes with 1 timeout. Running with a --force-opt=O3 Debug build, the test completed in about 39 minutes with 0 timeouts. The difference in test run time is 281 minutes vs 29 minutes. That is a 7.2x ratio, not 3.6x. >> Overall, how we’re doing things now feels like a bad allocation of bot >> resources. The differences I see between O3 with no-inlining vs O0 is: > > Last time this was discussed, we talked about -Og, which is specifically > designed for the purpose I believe. Where do we stand on understanding and > adopting that? I tried -Og last time after your suggestion, and I remember thinking that the perf was not acceptable back then. I’ll collect the data again and report back with real number later today. Mark > > - Alexey > >> - Some race conditions will behave differently. Race conditions are already >> non predictable. I don’t think we’re losing anything here. >> - O0 vs O3 is a different compiler. We may encounter bugs in O3 we don’t in >> O0, and vice versa. In general, we probably care more about O3 compiler bugs >> than O0, since we don’t ship O0, but ship a lot of O3. >> >> (And if we’re going to insist on “I want it to run what I build at my desk”: >> I run debug with O3 at my desk, and I can run debug tests in a reasonable >> amount of time now.) >> >> In evaluating what’s the better setup, I think it’s helpful to think about >> this from the other side. Let’s imagine we had Debug+O3 as our current >> setup. And someone proposed to move it to O0 and make our tests take ~10x >> longer. I think that’d be a non-starter. >> >> - Saam >> >>> On Jun 17, 2020, at 9:48 PM, Simon Fraser <simon.fra...@apple.com >>> <mailto:simon.fra...@apple.com>> wrote: >>> >>> I also object to losing good stack traces for crashes on Debug bots. >>> >>> Also, I don't think Debug bots should build something different from what I >>> build at my desk. >>> >>> Simon >>> >>>> On Jun 17, 2020, at 1:36 PM, Mark Lam <mark....@apple.com >>>> <mailto:mark....@apple.com>> wrote: >>>> >>>> Hi folks, >>>> >>>> We're planning to switch the JSC EWS bot and build.webkit.org >>>> <http://build.webkit.org/> Debug build and test bots to building with the >>>> following set first: >>>> ./Tools/Scripts/set-webkit-configuration --force-opt=O3 >>>> >>>> This means the Debug builds will be built with optimization level forced >>>> to O3. >>>> >>>> Why are we doing this? >>>> 1. So that the JSC EWS will start catching ASSERT failures. >>>> 2. JSC stress test Debug bots have been timing out and not running tests >>>> at all. Hopefully, this change will fix this issue. >>>> 3. Tests will run to completion faster and we’ll catch regressions sooner. >>>> >>>> The downside: crash stack traces will be like Release build stack traces. >>>> But I don’t think we should let this deter us. It’s not like there’s no >>>> stack information. And just as we do with debugging Release build test >>>> failures, we can always do a Debug build locally to do our debugging. >>>> >>>> We would like to apply this change to all Debug build and test bots, not >>>> just the JSC ones. Does anyone strongly object to this change? >>>> >>>> Thanks. >>>> >>>> Cheers, >>>> Mark >>>> >>>> _______________________________________________ >>>> webkit-dev mailing list >>>> webkit-dev@lists.webkit.org <mailto:webkit-dev@lists.webkit.org> >>>> https://lists.webkit.org/mailman/listinfo/webkit-dev >>>> <https://lists.webkit.org/mailman/listinfo/webkit-dev> >>> >>> _______________________________________________ >>> webkit-dev mailing list >>> webkit-dev@lists.webkit.org <mailto:webkit-dev@lists.webkit.org> >>> https://lists.webkit.org/mailman/listinfo/webkit-dev >>> <https://lists.webkit.org/mailman/listinfo/webkit-dev> >> _______________________________________________ >> webkit-dev mailing list >> webkit-dev@lists.webkit.org <mailto:webkit-dev@lists.webkit.org> >> https://lists.webkit.org/mailman/listinfo/webkit-dev >> <https://lists.webkit.org/mailman/listinfo/webkit-dev> > > - Alexey > > > _______________________________________________ > webkit-dev mailing list > webkit-dev@lists.webkit.org <mailto:webkit-dev@lists.webkit.org> > https://lists.webkit.org/mailman/listinfo/webkit-dev > <https://lists.webkit.org/mailman/listinfo/webkit-dev>
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev