On the Scalability of Constraint Solving for Static/O ine ...On the Scalability of Constraint Solving for Static/O ine Real-Time Scheduling R. Gorcitz1 E. Kofman2 D. Potop-Butucaru2

On the Scalability of Constraint Solving forStatic/Offline Real-Time Scheduling

R. Gorcitz1 E. Kofman2 D. Potop-Butucaru2

R. De Simone2 Thomas Carle3

1CNES, France

2INRIA, France

3Brown University, USA

December 1, 2015 - Syncron 2015 - Kiel

1 / 27

Outline

Motivation

Contribution

Motivating example and encoding principles

Test cases

Solving and results

Conclusion

2 / 27

Motivation

3 / 27

Motivation

I Formal methods:I Many things can be done (qualitative point of view)I But which ones work in practice? (quantitative point of view)

I Particularly interesting question for NP-complete problemsI Exponential theoretical upper bound (cf. P 6=NP)I Many instances of NP-complete problems are rapidly solved.I Practical interest: SAT solving, some scheduling problems,

some compilation problems, etc.

I Empirical evaluation of the hardness is neededI Determine under which conditions NP-complete problems are

harder (or easier) to solve, on averageI Extensive evaluations for 3-SAT (and some other problems)

I E.g. 3-SAT problems are harder to solve when theclauses/variables ratio is 4.3 [Selman et al. 1993]

I Difficulty: each problem needs a separate evaluationI Different set of parameters to varyI Synthesis of meaningful test cases is application-dependent

4 / 27

Motivation

I Formal methods:I Many things can be done (qualitative point of view)I But which ones work in practice? (quantitative point of view)

I Particularly interesting question for NP-complete problemsI Exponential theoretical upper bound (cf. P 6=NP)I Many instances of NP-complete problems are rapidly solved.I Practical interest: SAT solving, some scheduling problems,

some compilation problems, etc.

I Empirical evaluation of the hardness is neededI Determine under which conditions NP-complete problems are

harder (or easier) to solve, on averageI Extensive evaluations for 3-SAT (and some other problems)

I E.g. 3-SAT problems are harder to solve when theclauses/variables ratio is 4.3 [Selman et al. 1993]

I Difficulty: each problem needs a separate evaluationI Different set of parameters to varyI Synthesis of meaningful test cases is application-dependent

4 / 27

Motivation

Figure: Y-chart design methodology

Allocating and scheduling tasks and messages over a network ofresources is NP-Complete (for most problem instances).

Two main approaches:

I Avoiding NP-Completeness: heuristics

I Accepting it: general solvers (Integer Linear Programming /SAT Modulo Theory / Constraint Programming)

I How far? (with “up to date” solvers)I Small size problems (can still be interesting)I Design for scalability (what problems scale better)

5 / 27

Motivation







5 / 27

Motivation






I How far?

(with “up to date” solvers)I Small size problems (can still be interesting)I Design for scalability (what problems scale better)

5 / 27

Motivation







5 / 27

Contribution

I Encoding of a variety of off-line real-time scheduling problemsas SMT/ILP/CP problems

I Synthetic and realistic test cases (open, try them!)I A new task set generatorI Platooning, FFT

I Empirical hardness related to various parameters:I Problem sizeI PreemtivenessI Satisfiability vs optimization objectiveI System loadI DependenciesI PipeliningI Resources homogeneityI Single-/Multi-period.

6 / 27


Control steering, speed (and image capture parameters) to followthe vehicle ahead.

Imagecapture

Detectioncorrection

DisplaySobel_V_0

Sobel_V_X

... Histo_V_0

Histo_V_X

...

Sobel_H_0

Sobel_H_X... Histo_H_0

Histo_H_X...

Figure: Platooning dataflow graph application

7 / 27


IC DC

DSV HV

SH HH

Figure: Platooning dataflow graph application, no pipelining, nodata-parallelism (X=0) and simplified labels...

Encoding: ILP/SMT/CP set of linear and Boolean constraints.Application constraints:

I ICStop = ICStart + ICDuration

I SHStart ≥ ICStop

I SVStart ≥ ICStop

I ...

8 / 27


IC DC

DSV HV

SH HH






I ...

8 / 27


IC DC

DSV HV

SH HH






I ...

8 / 27


IC DC

DSV HV

SH HH






I ...

8 / 27


IC DC

DSV HV

SH HH

P2 P3

P1

Figure: Platooning dataflow graph application single period, nodata-parallelism (X=0) and simplified labels...

Resource constraints:

I ICMap ∈ {P1,P2,P3},SHMap ∈ {P1,P2,P3}, ...if SHMap = SVMap then

SHStart ≥ SVStop or SHStop ≥ SVStart

I ...

9 / 27


IC DC

DSV HV

SH HH

P2 P3

P1



I ICMap ∈ {P1,P2,P3}, SHMap ∈ {P1,P2,P3}, ...

if SHMap = SVMap thenSHStart ≥ SVStop or SHStop ≥ SVStart

I ...

9 / 27


IC DC

DSV HV

SH HH

P2 P3

P1



I ICMap ∈ {P1,P2,P3}, SHMap ∈ {P1,P2,P3}, ...if SHMap = SVMap then

SHStart ≥ SVStop or SHStop ≥ SVStart

I ...

9 / 27


Realistic modeling (in plain English):

1. Each task is allocated on exactly one processor

2. If two tasks are ordered, the second starts after the first ends

3. If two tasks are allocated on the same processor, they must beordered

4. The source and destination of a dependency must be ordered5. The bus communication associated with a dependency (if any) must

start after the source task ends and must end before the destinationtask starts

6. When two dependencies require both a bus communication, thesecommunications must be ordered

7. If two dependencies are ordered, the first must end before the second starts8. All tasks must end at a date smaller or equal than the schedule length

9. ...

10 / 27


Encoding more complex scheduling problems (added complexity):I Pipelined scheduling

I Modulo scheduling, non-linear (modulo) operators

I Preemptive schedulingI Each task must be statically divided into atomic chunks

I Multi-period schedulingI Strict periodicity vs. Non-strictI Number of start date variablesI Implicitly pipelined

I Heterogenous vs. homogenous schedulingI Symmetry arguments, etc.

I Not done: Accounting for preemption costs, migrations, etc.

11 / 27


Result in the simple case:

P1

Bus

P2

0 0.005 0.01 0.015 0.02 0.025 0.03

ICIC

->SV

HHHV

HV->

DC

SV

DSH

SV->

DDC

time

Figure: Gantt diagram (optimal non-preemptive, non-pipelined schedule)

12 / 27

Test cases

Synthetic examples:

I Dependent task systems (algorithm of [Carle and Potop 2014])I Non-dependent task systems

I Classical synthesis algorithms cannot be used to provide abasis of comparison E.g. UUniFast of [Bini&Buttazzo 2005]cannot handle heterogenous architectures

I For each problem type:I Number of tasks n ranging from 7 to 147 with step 5I Number of processors ceil(n/5)I 40/25 problem instances for each problem and sizeI Periods chosen randomly in the set 5,10,15,20,30,60I Average system loads: 25%, 75%, 87.5%,125%I WCETs generated accordinglyI Allocation: 30% probability of fixed allocation (random CPU).

For open allocation: 70% probability that a task is allocatedto a given processor (heterogenous case).

13 / 27

Test cases

Realistic examples: FFT, Platooning (we need more!)

14 / 27

Test cases

Parameters that we tune:

I Problem type: schedulability vs. optimizationI Task set properties:

I PreemtivenessI Dependent vs. Non-dependentI Single-/Multi-periodI PipeliningI Resource homogeneity

I Problem size

I Average system load (25%, 75%, 87.5%,125%)

I Pipelining depth (for the platooning example)

15 / 27

Solving and results

We look at:

I Average solving time

I Timeout (1 hour) ratio

Figure: Timeout (1h) rate (preemptive, multi-periodic, heterogenous,75% load)

16 / 27

Solving and results

Figure: Single Period Non-Preemptive vs Multi Period Preemptive

→ Preemptive problems are more complex→ But non-preemptive scheduling has its bounds, too.

17 / 27

Solving and results

Figure: Homogeneous resources VS Heterogeneous resources

→ Not so clear

18 / 27

Solving and results

Figure: Complexity as a function of system load (single-period,non-preemptive, heterogenous)

→ Underloaded and overloaded systems are easier to handle.

19 / 27

Solving and results

Figure: Optimization vs. Schedulability analysis (single-period,non-preemptive, heterogenous, 75% load)

→ Optimization problems are extremely difficult

20 / 27

Solving and results

The dependent task synthetic examples:

I Removing dependencies always reduces solving time (intuitiveexplanation: having a smaller search space is less importantthan its complexity)

I Timeout rate:I dependent task systems: 55%I after dependency removal: 13%

21 / 27

Solving and results

The FFT example results (non-preemptive, single-period,dependent):

Figure: Pipelining: Cyclic dataflow graph to DAG

22 / 27

Solving and results

Consider 2 types of parallelism (separately):

I Pipelining.

I Data parallelism (split/merge).

Figure: Pipelining: Cyclic dataflow graph to DAG

Pipelining raises the depth of the graph

23 / 27

Solving and results

SobelH04

HistoH04

SobelH03

HistoH03

SobelH01

HistoH01

SobelV01

HistoV01

Display01

SobelV04

HistoV04

Display04

SobelV03

HistoV03

Display03

Detection01

Detection04

Read01

Read02

Detection03

HistoH02

Detection02

HistoV05

Detection05

HistoH00

Detection00

Read03

Read04

Display00

SobelH02

SobelH00

SobelV05

Display05

SobelV00

HistoV00

SobelV02

HistoV02

Display02

Read05

SobelH05

HistoH05

Read00

SobelV2

Display0

HistoV2 HistoV1

Detection0

SobelH5

HistoH5

SobelV3

HistoV3 HistoV4

Read0

SobelH4 SobelH3SobelV5 SobelH2 SobelH1 SobelV1SobelH0 SobelV0 SobelV4

HistoV0HistoH2 HistoH4 HistoH3HistoV5 HistoH1HistoH0

Figure: Pipelining vs. data parallelism

24 / 27

Solving and results

Split/merge parallelism that allows the application of symmetrybreaking techniques (homogenous architecture) !

Figure: Symmetry breaking helps on large graphs

Exponential curve, even after symmetry breaking.

Deep graphs will scale much better than large graphs (the deepgraph scales up to 100 tasks in our case).

25 / 27

Solving and results

Split/merge parallelism that allows the application of symmetrybreaking techniques (homogenous architecture) !

Figure: Symmetry breaking helps on large graphs

Exponential curve, even after symmetry breaking.Deep graphs will scale much better than large graphs (the deepgraph scales up to 100 tasks in our case).

25 / 27

Conclusion

Good practices for encoding scheduling problems:

I Certain problems (especially parallelized code) can exhibit alot of symmetry. It is imperative to use symmetry-breakingtechniques.

I Certain architectures (e.g. many-cores) exhibit a lot ofsymmetry.

I The more complex is to specify, the more complex is to solve.

26 / 27

Conclusion

Thank you

Questions ?

27 / 27

Conclusion

Thank you

Questions ?

27 / 27

Documents

On the Scalability of Constraint Solving for Static/O ine ...On the Scalability of Constraint Solving for Static/O ine Real-Time Scheduling R. Gorcitz1 E. Kofman2 D. Potop-Butucaru2