bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: gnulib-tool: Ensure that long-running tests are executed last


From: Bruno Haible
Subject: Re: gnulib-tool: Ensure that long-running tests are executed last
Date: Fri, 2 Apr 2010 23:13:12 +0100
User-agent: KMail/1.9.9

Hi Eric, Jim,

> >> This ensures that long-running tests are executed last. So that the user
> >> gets the maximum of information as quickly as possible.
> >
> > That goes counter to the idea of parallel execution, where you want the
> > long-running tests front-loaded so that the shorter tests can fill in
> > the gaps.  If the long-running tests are last, then the entire parallel
> > operation is stuck waiting for the last test.
> 
> I have deliberately reordered some tests to put long-running
> ones early enough so that a parallel (often -j5 or more) build
> completes as quickly as possible.

Hmm, it seems we are trying to optimize for different execution models and
different goals:
  - I was assuming a sequential execution (since this is the default with
    "make") and the goal of maximizing the information that is available
    within a short time after starting the test.
  - You are assuming a parallel execution with several processors, and
    the only goal being to minimize the turnaround time, that is, assuming
    that the user wants to execute all tests and is only interested in the
    final summary result.

I agree that in the scenario of parallel execution and the only goal being
to minimize the turnaround time, the long-running tasks need to be started
first.

But we don't know what the user's goals will be.

> > Is there any way this can
> > be made conditional, because there are good arguments for both orderings?

In theory, we could build up two variables TESTS1 and TESTS2, instead of just
TESTS, and decide at "make" time whether to use
  TESTS = $(TESTS1) $(TESTS2)
or
  TESTS = $(TESTS2) $(TESTS1).
Maybe even by inspecting the MAKEFLAGS.

But this sounds like a big hack: Basically, we would be adding a context
dependent choice of a scheduler algorithm in a particular Makefile. It would
be better if we could some way declare the expected running time to GNU make,
and have GNU make choose its scheduler algorithm itself.

Bruno




reply via email to

[Prev in Thread] Current Thread [Next in Thread]