> 19 июня 2020 г., в 1:11 PM, Mark Lam <mark....@apple.com> написал(а):
>> On Jun 19, 2020, at 10:24 AM, Geoffrey Garen <gga...@apple.com 
>> <mailto:gga...@apple.com>> wrote:
>>>> On Jun 19, 2020, at 8:04 AM, Geoffrey Garen <gga...@apple.com 
>>>> <mailto:gga...@apple.com>> wrote:
>>>> Can you explain more about what "O3 with no-inlining” is? How does 
>>>> --force-opt=O3 avoid inlining? Would this fully resolve Simon concern 
>>>> about stack traces, or would something still be different about stack 
>>>> traces?
>>> There doesn't exist a way to do this now, but it'd be trivial to add a way. 
>>> I won't claim it fixes all stack traces differences, but I'd think 
>>> compiling using "-fno-inline -fno-optimize-sibling-calls" would get us 
>>> pretty far in crashing stack traces being similar enough.
>> Sounds good.
>> I think we should try to refine the proposal along these lines, to minimize 
>> the downsides. I won’t speak for Simon, but for me, being able to ensure a 
>> clear backtrace from a bot would be a big improvement.
>>>> And again, I think this discussion would get a lot more focused if the 
>>>> change could apply only to JSC code, and not also to WTF code.
>>> I believe Mark's proposal, initially, is just to make JSC do this. So I 
>>> don't see the point of compiling WTF differently. JSC can kick off its own 
>>> build, and run Debug+O3 tests faster than it can run Debug+O0 tests. Given 
>>> people working on JSC want this, and people working on JSC defend these 
>>> tests, and that these test results are more stable (see below), we should 
>>> make this change for JSC.
>>> I was trying to convince folks defending non-JSC testing, that they too, 
>>> should want this. I'm not going to pull teeth here. If folks want their 
>>> tests to take ~10x longer to run, they're entitled to make that tradeoff.
>> Got it.
> I'm of the same mind as Saam.  We want this change for the JSC bots, and from 
> the time measurements I’ve collected, we can afford to do a clean build for 
> the JSC Debug test runs using O3, and still come out way ahead.

This seems like a reasonable plan. You didn't mention what hardware you 
measured with, but it seems certain to be beneficial on any current hardware.

I need to mention that we saw unexplained and very large impact on JSC test 
speed from enabling/disabling TCSM. That may be a good thing to look into while 
optimizing JSC test speed.

- Alexey

> As for non-JSC test runs, I have not actually measured what the time savings 
> are.  Given there is resistance to going with O3 there, we don’t have to 
> share the build artifacts for running the tests.  JSC test runs should be 
> able to just build JSC for each O3 Debug JSC test run and it is still a win 
> over the current status quo i.e. test runs never complete.
> Regarding Geoff’s earlier question about whether I know for sure that 
> switching to O3 will fix the current Debug JSC bot failures to run tests, the 
> answer is I’m not certain.  The failure is a timeout due to the master bot 
> not seeing any output from the tester bot for more than 20 minutes.  I’ve not 
> been able to reproduce this yet.  But with a Debug build test run taking 4+ 
> hours, it can only be a progression to switch the Debug JSC test bots to O3.
> Mark
>>>> And again, on the run more tests front, it would be helpful to know 
>>>> whether this change was enough to get the stress tests running or not.
>>> My experience running the tests locally supports this fully. I don't get 
>>> timeouts when running O3+Debug locally. When running Debug+O0 locally, I'd 
>>> get timeouts all the time, and the total test run would take ~4-8 hours. We 
>>> can wait for official confirmation from Mark.
>> Alexey, do the JSC stress tests run now on bots? If not, how fast would they 
>> need to run in order to be eligible to run on bots?
>> Thanks,
>> Geoff
>>> - Saam
>>>> Thanks,
>>>> Geoff
>>>>> On Jun 18, 2020, at 9:30 PM, Saam Barati <sbar...@apple.com 
>>>>> <mailto:sbar...@apple.com>> wrote:
>>>>> 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.
>>>>> 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:
>>>>> - 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>
>> _______________________________________________
>> webkit-dev mailing list
>> webkit-dev@lists.webkit.org <mailto:webkit-dev@lists.webkit.org>
>> 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

- Alexey

webkit-dev mailing list

Reply via email to