What I am thinking is to measure time for each "make" (prerun) and split
them equally (by time) to different cores in later run.
Hai
On Thu, Sep 7, 2017 at 1:00 AM, Hai Nguyen <nhai.qn.gmail.com> wrote:
>
>
> On Thu, Sep 7, 2017 at 12:32 AM, David Cerutti <dscerutti.gmail.com>
> wrote:
>
>> This sounds like a great idea to me--the only thing, I think, that could
>> prevent serial tests from running properly in parallel is that some of
>> them
>> write to the same files. Could we use make dependencies to ensure that
>> the
>> tests are all run safely, then just let people do the old make -j8?
>>
>>
>>
> I've run my local script with several cores in casegroup and got below
> summary. Most of the failures are from FEW test.
> Given the number of small failures, we can fix it (hopefully easily).
>
> 2098 file comparisons passed
>
> 14 file comparisons failed
>
> 3 tests experienced errors
>
> Finished testing AmberTools in 41.56 (minutes)
>
>
> Hai
>
>
>>
>> On Wed, Sep 6, 2017 at 4:46 PM, Hai Nguyen <nhai.qn.gmail.com> wrote:
>>
>> > On Wed, Sep 6, 2017 at 1:33 PM, David Cerutti <dscerutti.gmail.com>
>> wrote:
>> >
>> > > One other thing we might do is have each of us go into our respective
>> > > projects and ensure that the tests are running as efficiently as
>> > possible.
>> > > For example, rather than 50 steps of MD printing every ten iterations,
>> > can
>> > > the same quality assurance be got in ten steps printing every two
>> > > iterations? For sander/pmemd, startup time is still a significant
>> > > overhead, but shave 40% off many of the test cases and that'll take
>> the
>> > > edge off the problem. (Another thing to mention is that if your test
>> > needs
>> > > 50 steps to monitor numbers with four places after the decimal and
>> ensure
>> > > the code is not subtly corrupted, a more sensitive metric needs to be
>> > > devised to get at lower significant figures.) I think that part of the
>> > > problem here is like pollution: each test contributing an extra few
>> > seconds
>> > > goes a long way to making the suite as a whole bloated.
>> > >
>> > >
>> > I am also working on split the serial tests to run them in parallel.
>> >
>> > Hai
>> >
>> >
>> > > Dave
>> > >
>> > >
>> > > On Wed, Sep 6, 2017 at 12:14 PM, Daniel Roe <daniel.r.roe.gmail.com>
>> > > wrote:
>> > >
>> > > > On Wed, Sep 6, 2017 at 10:30 AM, Jason Swails <
>> jason.swails.gmail.com>
>> > > > wrote:
>> > > > > My suggestion is to move from gitosis to a tool that implements a
>> > > > > PR/CI-gating workflow like GitLab (which can be self-hosted).
>> > Disable
>> > > > > pushing directly to master and make every change pass through a
>> gated
>> > > > pull
>> > > > > request that enforces some level of quality before merging is
>> > > permitted.
>> > > >
>> > > > Yes, let's do this! But only once we've come up with a far more
>> > > > compact test suite per DAC's previous request. The full test suite
>> can
>> > > > still be run nightly.
>> > > >
>> > > > -Dan
>> > > >
>> > > > --
>> > > > -------------------------
>> > > > Daniel R. Roe
>> > > > Laboratory of Computational Biology
>> > > > National Institutes of Health, NHLBI
>> > > > 5635 Fishers Ln, Rm T900
>> > > > Rockville MD, 20852
>> > > > https://www.lobos.nih.gov/lcb
>> > > >
>> > > > _______________________________________________
>> > > > AMBER-Developers mailing list
>> > > > AMBER-Developers.ambermd.org
>> > > > http://lists.ambermd.org/mailman/listinfo/amber-developers
>> > > >
>> > > _______________________________________________
>> > > AMBER-Developers mailing list
>> > > AMBER-Developers.ambermd.org
>> > > http://lists.ambermd.org/mailman/listinfo/amber-developers
>> > >
>> > _______________________________________________
>> > AMBER-Developers mailing list
>> > AMBER-Developers.ambermd.org
>> > http://lists.ambermd.org/mailman/listinfo/amber-developers
>> >
>> _______________________________________________
>> AMBER-Developers mailing list
>> AMBER-Developers.ambermd.org
>> http://lists.ambermd.org/mailman/listinfo/amber-developers
>>
>
>
_______________________________________________
AMBER-Developers mailing list
AMBER-Developers.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber-developers
Received on Wed Sep 06 2017 - 22:30:03 PDT
