61
SITE, 2008 - HARDWARE/SOFTWARE CODESIGN OF EMBEDDED SYSTEMS 1 Hardware/ Software Codesign of Embedded Systems OPTIMIZATION II Voicu Groza SITE Hall, Room 5017 562 5800 ext. 2159 [email protected]. ca

Hardware/Software Codesign of Embedded Systems

Embed Size (px)

DESCRIPTION

Hardware/Software Codesign of Embedded Systems. OPTIMIZATION II. Voicu Groza SITE Hall, Room 5017 562 5800 ext. 2159 [email protected]. Hill Climbing Simulated Annealing Tabu search. Hill Climbing (Gradient Descent). Trying to maximize a function - PowerPoint PPT Presentation

Citation preview

Page 1: Hardware/Software Codesign of Embedded Systems

SITE, 2008 - HARDWARE/SOFTWARE CODESIGN OF EMBEDDED SYSTEMS

1

Hardware/Software Codesign of

Embedded Systems

OPTIMIZATION II Voicu Groza SITE Hall, Room 5017

562 5800 ext. [email protected]

Page 2: Hardware/Software Codesign of Embedded Systems

SITE, 2008 - HARDWARE/SOFTWARE CODESIGN OF EMBEDDED SYSTEMS

2

• Hill Climbing

• Simulated Annealing

• Tabu search

Page 3: Hardware/Software Codesign of Embedded Systems

SITE, 2008 - HARDWARE/SOFTWARE CODESIGN OF EMBEDDED SYSTEMS

3

Hill Climbing (Gradient Descent)

3. Choose the neighbour with the best quality and move to that state.

4. Repeat 2 through 4 until all the neighbouring states are of lower quality.

5. Return the current state as the solution state.

Trying to maximize a function 1. Pick a random point

in the search space.2. Consider all the

neighbours of the current state.

http://www.ndsu.nodak.edu/instruct/juell/vp/cs724s00/hill_climbing/hill_climbing.html

Page 4: Hardware/Software Codesign of Embedded Systems

SITE, 2008 - HARDWARE/SOFTWARE CODESIGN OF EMBEDDED SYSTEMS

4

Hill Climbing AlgorithmFunction HILL-CLIMBING(Problem) returns a solution state

Inputs: Problem, problemLocal variables: Current, a node

Next, a node

Current = MAKE-NODE(INITIAL-STATE[Problem])

Loop doNext = a highest-valued successor of CurrentIf VALUE[Next] < VALUE[Current] then return CurrentCurrent = Next

End(Russell, 1995)

Page 5: Hardware/Software Codesign of Embedded Systems

SITE, 2008 - HARDWARE/SOFTWARE CODESIGN OF EMBEDDED SYSTEMS

5

Problems in Hill Climbing

• Foothills are potential traps for the algorithm. • A plateau is a flat area of the search space in which a whole set of neighbouring

states have the same value. On a plateau, it is not possible to determine the best direction in which to move by making local comparisons.

• Possible solutions:• Try several runs, multi-start hill-climb: each starting at a random point in the search

space. • Increase the size of the neighbourhood

There is no guarantee to find a global optimum.

Tendency to get stuck at foothills, a plateau or a ridge. If the algorithm reaches any of them,  it will fail to find a solution.

• Local maxima = states that are better than all its neighbours but are not better than some other states farther away.

http://www.cs.nott.ac.uk/~gxk/courses/g5baim/Hill%20Climbing/Hill02-problems.html

Page 6: Hardware/Software Codesign of Embedded Systems

SITE, 2008 - HARDWARE/SOFTWARE CODESIGN OF EMBEDDED SYSTEMS

6

Simulated Annealing Motivated by the physical annealing process Material is heated and slowly cooled into a uniform structure Simulated annealing mimics this process The first SA algorithm was developed in 1953 (Metropolis) Compared to hill climbing the main differences are that

SA allows downwards steps; a move is selected at random and then decides whether to accept it

In SA better moves are always accepted. Worse moves are not always accepted!?

Dr. Graham Kendall, The University of Nottingham, UK

Page 7: Hardware/Software Codesign of Embedded Systems

SITE, 2008 - HARDWARE/SOFTWARE CODESIGN OF EMBEDDED SYSTEMS

7

To accept or not to accept - SA?

P = exp(-c/t) > rwhere

– c is change in the evaluation function

– t the current temperature– r is a random number

between 0 and 1

• Example

Change in Evaluation Function

Temperature of System exp(-C/T)

Change in Evaluation Function

Temperature of System exp(-C/T)

10 100 0.904837418 10 10 0.36787944120 100 0.818730753 20 10 0.13533528330 100 0.740818221 30 10 0.04978706840 100 0.670320046 40 10 0.01831563950 100 0.60653066 50 10 0.00673794760 100 0.548811636 60 10 0.00247875270 100 0.496585304 70 10 0.00091188280 100 0.449328964 80 10 0.00033546390 100 0.40656966 90 10 0.00012341

100 100 0.367879441 100 10 4.53999E-05110 100 0.332871084 110 10 1.67017E-05120 100 0.301194212 120 10 6.14421E-06130 100 0.272531793 130 10 2.26033E-06140 100 0.246596964 140 10 8.31529E-07150 100 0.22313016 150 10 3.05902E-07160 100 0.201896518 160 10 1.12535E-07170 100 0.182683524 170 10 4.13994E-08180 100 0.165298888 180 10 1.523E-08190 100 0.149568619 190 10 5.6028E-09200 100 0.135335283 200 10 2.06115E-09

Probability of accepting with high temperature

Probability of accepting with low temperature

SImulated Annealing Acceptance Probability

00.10.20.30.40.50.60.70.80.9

1

1 3 5 7 9 11 13 15 17 19

Change in Evaluation

Pro

babili

ty o

f A

ccepta

nce

Temp = 100

Temp = 10

The law of thermodynamics states that at temperature t, the probability of an increase in energy of magnitude, δE, is given by

P(δE) = exp(-δE /kt)where k is Boltzmann’s constant

Page 8: Hardware/Software Codesign of Embedded Systems

SITE, 2008 - HARDWARE/SOFTWARE CODESIGN OF EMBEDDED SYSTEMS

8

To accept or not to accept - SA?

The probability of accepting a worse state is a function of both the temperature of the system and the change in the cost function

As the temperature decreases, the probability of accepting worse moves decreases

If t = 0, no worse moves are accepted (i.e. hill climbing)

Page 9: Hardware/Software Codesign of Embedded Systems

SITE, 2008 - HARDWARE/SOFTWARE CODESIGN OF EMBEDDED SYSTEMS

9

SA AlgorithmThe most common way of implementing an SA algorithm is to implement hill climbing with an accept function and modify it for SA

Function SIMULATED-ANNEALING(Problem, Schedule) returns a solution state

Inputs: Problem, a problemSchedule, a mapping from time to

temperatureLocal Variables : Current, a node

Next, a nodeT=“temperature” controlling the probability of downward steps

Current = MAKE-NODE(INITIAL-STATE[Problem])Russell/Norvig

Page 10: Hardware/Software Codesign of Embedded Systems

SITE, 2008 - HARDWARE/SOFTWARE CODESIGN OF EMBEDDED SYSTEMS

10

SA Algorithm

For i = 1 to do

T = Schedule[i]

If T = 0 then return Current

Next = a randomly selected successor of Current

E = VALUE[Next] – VALUE[Current]

if E > 0 then Current = Next

else Current = Next only with probability exp(- E/T)

Page 11: Hardware/Software Codesign of Embedded Systems

SITE, 2008 - HARDWARE/SOFTWARE CODESIGN OF EMBEDDED SYSTEMS

11

SA Algorithm - Observations• The cooling schedule is hidden in this algorithm,

and important are– Starting Temperature– Final Temperature– Temperature Decrement– Iterations at each temperature

• The algorithm assumes that annealing will continue until temperature is zero - this is not necessarily the case

Page 12: Hardware/Software Codesign of Embedded Systems

SITE, 2008 - HARDWARE/SOFTWARE CODESIGN OF EMBEDDED SYSTEMS

12

SA Cooling Schedule - Starting Temperature

• Must be hot enough to allow moves to almost neighbourhood state (else we are in danger of implementing hill climbing)

• Must not be so hot that we conduct a random search for a period of time

• Problem is finding a suitable starting temperature

Page 13: Hardware/Software Codesign of Embedded Systems

SITE, 2008 - HARDWARE/SOFTWARE CODESIGN OF EMBEDDED SYSTEMS

13

SA Cooling Schedule – Starting Temperature

• Starting Temperature - Choosing– If we know the maximum change in the cost

function we can use this to estimate

– Start high, reduce quickly until about 60% of worse moves are accepted. Use this as the starting temperature

– Heat rapidly until a certain percentage are accepted the start cooling

Page 14: Hardware/Software Codesign of Embedded Systems

SITE, 2008 - HARDWARE/SOFTWARE CODESIGN OF EMBEDDED SYSTEMS

14

SA Cooling Schedule - Final Temperature

• It is usual to let the temperature decrease until it reaches zeroHowever, this can make the algorithm run for a lot longer, especially when a geometric cooling schedule is being used

• In practice, it is not necessary to let the temperature reach zero because the chances of accepting a worse move are almost the same as the temperature being equal to zero

• => the stopping criteria can either be a suitably low temperature or when the system is “frozen” at the current temperature (i.e. no better or worse moves are being accepted)

Page 15: Hardware/Software Codesign of Embedded Systems

SITE, 2008 - HARDWARE/SOFTWARE CODESIGN OF EMBEDDED SYSTEMS

15

SA Cooling Schedule - Temperature Decrement

Theory states that: • should allow enough iterations at each temperature so

that the system stabilises at that temperature• the number of iterations at each temperature to achieve

this might be exponential to the problem size

=> compromise:

– doing a large number of iterations at a few temperatures, or

– a small number of iterations at many temperatures or

– a balance between the two

Page 16: Hardware/Software Codesign of Embedded Systems

SITE, 2008 - HARDWARE/SOFTWARE CODESIGN OF EMBEDDED SYSTEMS

16

SA Cooling Schedule - Temperature Decrement

• Linear

– temp = temp - x

• Geometric

– temp = temp * α

– Experience has shown that α should be between 0.8 and 0.99, with better results being found in the higher end of the range. Of course, the higher the value of α, the longer it will take to decrement the temperature to the stopping criterion

Page 17: Hardware/Software Codesign of Embedded Systems

SITE, 2008 - HARDWARE/SOFTWARE CODESIGN OF EMBEDDED SYSTEMS

17

SA Cooling Schedule - Iterations

POSSIBLE APPROACHES:

1. A constant number of iterations at each temperature

2. Lundy, 1986: do only one iteration at each temperature, but to decrease the temperature very slowly

• t = t/(1 + βt)• where β is a suitably small value

3. Dynamically change the number of iterations as the algorithm progresses:

– at lower temperatures a large number of iterations are done so that the local optimum can be fully explored

– at higher temperatures, the number of iterations can be less

Page 18: Hardware/Software Codesign of Embedded Systems

SITE, 2008 - HARDWARE/SOFTWARE CODESIGN OF EMBEDDED SYSTEMS

18

Problem Specific Decisions• The cooling schedule is all about SA but there are other

decisions which we need to make about the problem

• These decisions are not just related to SA

Page 19: Hardware/Software Codesign of Embedded Systems

SITE, 2008 - HARDWARE/SOFTWARE CODESIGN OF EMBEDDED SYSTEMS

19

Problem Specific Decisions - Cost Function

• The evaluation function is calculated at every iteration• Often the cost function is the most expensive part of the

algorithm=> Need to evaluate the cost function as efficiently as possible

– Use Delta Evaluation– Use Partial Evaluation

• The cost function should be designed to lead the search– Avoid cost functions where many states return the same value.

This can be seen as representing a plateau in the search space which the search has no knowledge about which way it should proceed

Page 20: Hardware/Software Codesign of Embedded Systems

SITE, 2008 - HARDWARE/SOFTWARE CODESIGN OF EMBEDDED SYSTEMS

20

Problem Specific Decisions - Cost Function

Many cost functions cater for the fact that some solutions are illegal. This is achieved using constraints

• Hard Constraints : these constraints cannot be violated in a feasible solution

• Soft Constraints : these constraints should, ideally, not be violated but, if they are, the solution is still feasible

– Hard constraints are given a large weighting. The solutions which violate those constraints have a high cost function

– Soft constraints are weighted depending on their importance– Weights can be dynamically changed as the algorithm

progresses. This allows hard constraints to be accepted at the start of the algorithm but rejected later

Page 21: Hardware/Software Codesign of Embedded Systems

SITE, 2008 - HARDWARE/SOFTWARE CODESIGN OF EMBEDDED SYSTEMS

21

Problem Specific Decisions - Neighbourhood

• How do you move from one state to another?• When you are in a certain state, what other states are

reachable?• Some results have shown that the neighbourhood

structure should be symmetric. That is, if you move from state i to state j then it must be possible to move from state j to state i

• However, a weaker condition can hold in order to ensure convergence.

• Every state must be reachable from every other. Therefore, it is important, when thinking about your problem to ensure that this condition is met

Page 22: Hardware/Software Codesign of Embedded Systems

SITE, 2008 - HARDWARE/SOFTWARE CODESIGN OF EMBEDDED SYSTEMS

22

Problem Specific Decisions - Performance

• What is performance?– Quality of the solution returned– Time taken by the algorithm

• We already have the problem of finding suitable SA parameters (cooling schedule)

Page 23: Hardware/Software Codesign of Embedded Systems

SITE, 2008 - HARDWARE/SOFTWARE CODESIGN OF EMBEDDED SYSTEMS

23

Problem Specific Decisions - Initialisation

– Start with a random solution and let the annealing process improve on that.

– Might be better to start with a solution that has been heuristically built (e.g. for the TSP problem, start with a greedy search)

Page 24: Hardware/Software Codesign of Embedded Systems

SITE, 2008 - HARDWARE/SOFTWARE CODESIGN OF EMBEDDED SYSTEMS

24

Problem Specific Decisions - Hybridisation

… or mimetic algorithms:

Combine two search algorithms– Often a population based search strategy is used as

the primary search mechanism, and a local search mechanism is applied to move each individual to a local optimum

– It may be possible to apply some heuristic to a solution in order to improve it

Page 25: Hardware/Software Codesign of Embedded Systems

SITE, 2008 - HARDWARE/SOFTWARE CODESIGN OF EMBEDDED SYSTEMS

25

Example: VLSI Floorplanning with Simulated Annealing

Modules are displayed as yellow rectangles; terminals are marked by small black rectangles. Connections between modules are displayed using red lines. This display of nets is sometimes known as a "rat's nest" diagram. On the left, it displays a diagram of a floorplan and its estimated cost.

On the right, it displays annealing status information, controls, and a plot of maximum (red), average (black), and minimum (green) accepted configuration costs at each temperature.

http://foghorn.cadlab.lafayette.edu/cadapplets/fp/fpApplet.html

Page 26: Hardware/Software Codesign of Embedded Systems

SITE, 2008 - HARDWARE/SOFTWARE CODESIGN OF EMBEDDED SYSTEMS

26

SA Modifications – Acceptance Probability

• The probability of accepting a worse move is normally based on the physical analogy (based on the Boltzmann distribution)

• Is there any reason why a different function will not perform better for all, or at least certain, problems?

• Why should we use a different acceptance criteria?– The one proposed does not work. Or we suspect we might be

able to produce better solutions– The exponential calculation is computationally expensive.– (Johnson, 1991) found that the acceptance calculation took

about one third of the computation time

Page 27: Hardware/Software Codesign of Embedded Systems

SITE, 2008 - HARDWARE/SOFTWARE CODESIGN OF EMBEDDED SYSTEMS

27

SA Modifications – Acceptance Probability

• Johnson experimented with

P(δ) = 1 – δ/t• This approximates the exponential• A better approach was found by building

a look-up table of a set of values over the range δ/t• During the course of the algorithm δ/t was rounded to the

nearest integer and this value was used to access the look-up table

• This method was found to speed up the algorithm by about a third with no significant effect on solution quality

time(n) t = t / (1 + ßt)time(0) 100time(1) 90.90909091time(2) 83.33333333time(3) 76.92307692time(4) 71.42857143time(5) 66.66666667time(6) 62.5time(7) 58.82352941time(8) 55.55555556time(9) 52.63157895time(10) 50time(11) 47.61904762time(12) 45.45454545time(13) 43.47826087time(14) 41.66666667time(15) 40time(16) 38.46153846time(17) 37.03703704time(18) 35.71428571time(19) 34.48275862time(20) 33.33333333

Page 28: Hardware/Software Codesign of Embedded Systems

SITE, 2008 - HARDWARE/SOFTWARE CODESIGN OF EMBEDDED SYSTEMS

28

SA Modifications - Cooling• If you plot a typical cooling schedule you are likely to find

that at high temperatures many solutions are accepted• If you start at a too higher temperature a random search

is emulated and until the temperature cools sufficiently any solution can be reached and could have been used as a starting position

• At lower temperatures, a plot of the cooling schedule, is likely to show that very few worse moves are accepted; almost making simulated annealing emulate hill climbing

• Taking this one stage further, we can say that simulated annealing does most of its work during the middle stages of the cooling schedule

Page 29: Hardware/Software Codesign of Embedded Systems

SITE, 2008 - HARDWARE/SOFTWARE CODESIGN OF EMBEDDED SYSTEMS

29

SA Modifications - Cooling• Connolly suggested annealing at a constant temperature! • But what temperature?• It must be high enough to allow movement but not so low

that the system is frozen• But, the optimum temperature will vary from one type of

problem to another and also from one instance of a problem to another instance of the same problem

• One solution to this problem is to spend some time searching for the optimum temperature and than stay at that temperature for the remainder of the algorithm

• The final temperature is chosen as the temperature that returns the best cost function during the search phase

Page 30: Hardware/Software Codesign of Embedded Systems

SITE, 2008 - HARDWARE/SOFTWARE CODESIGN OF EMBEDDED SYSTEMS

30

SA Modifications - Neighbourhood

• The neighbourhood of any move is normally the same throughout the algorithm but…

• The neighbourhood could be changed as the algorithm progresses

• For example, a cost function based on penalty values can be used to restrict the neighbourhood if the weights associated with the penalties are adjusted as the algorithm progresses

Page 31: Hardware/Software Codesign of Embedded Systems

SITE, 2008 - HARDWARE/SOFTWARE CODESIGN OF EMBEDDED SYSTEMS

31

SA Modifications – Cost Function

• The cost function is calculated at every iteration of the algorithm

• Various researchers (e.g. Burke,1999) have shown that the cost function can be responsible for a large proportion of the execution time of the algorithm

• Some techniques have been suggested which aim to alleviate this problem: (Rana, 1996) - Coors Brewery

– GA but could be applied to SA– The evaluation function is approximated (one tenth of a second)– Potentially good solution are fully evaluated (three minutes)

Page 32: Hardware/Software Codesign of Embedded Systems

SITE, 2008 - HARDWARE/SOFTWARE CODESIGN OF EMBEDDED SYSTEMS

32

SA Modifications – Cost Function

• (Ross, 1994) uses delta evaluation on the timetabling problem– Instead of evaluating every timetable as only small

changes are being made between one timetable and the next, it is possible to evaluate just the changes and update the previous cost function using the result of that calculation

• (Burke, 1999) uses a cache– The cache stores cost functions (partial and complete)

that have already been evaluated– They can be retrieved from the cache rather than having

to go through the evaluation function again

Page 33: Hardware/Software Codesign of Embedded Systems

SITE, 2008 - HARDWARE/SOFTWARE CODESIGN OF EMBEDDED SYSTEMS

33

Tabu Search Overview• Tabu – socially or culturally proscribed: forbidden to be

used, mentioned, or approached because of social or cultural rather than legal prohibitions. (http://encarta.msn.com/dictionary_1861698691/taboo.html)

• The Tabu search proceeds according to the supposition that there is no point in accepting a new (poor) solution unless it is to avoid a path already investigated.

• Tabu search is based on introducing flexible memory structures in conjunction with strategic restrictions (Tabu lists) and aspiration levels as a means for exploiting search spaces.

Page 34: Hardware/Software Codesign of Embedded Systems

SITE, 2008 - HARDWARE/SOFTWARE CODESIGN OF EMBEDDED SYSTEMS

34

Characteristics• Always performs best move or least non-improving move • Employs a memory to diversify or intensify the search • Is deterministic (although probabilistic elements may

exist)• Three main strategies:

– Forbidding strategy: control what enters the tabu list– Freeing strategy: control what exits the tabu list and when– Short-term strategy: manage interplay between the

forbidding strategy and freeing strategy to select trial solutions

Page 35: Hardware/Software Codesign of Embedded Systems

SITE, 2008 - HARDWARE/SOFTWARE CODESIGN OF EMBEDDED SYSTEMS

35

• To exploit memory in tabu search => classify a subset of the moves in a neighborhood as forbidden (or tabu)*

• A neighborhood is constructed to identify adjacent solutions that can be reached from current solution.

• The classification depends on the history of the search, and particularly on the recency or frequency that certain move or solution components, called attributes, have participated in generating past solutions*.

• A tabu list records forbidden moves, which are referred to as tabu moves [5].

• Tabu restrictions are subject to an important exception. When a tabu move has a sufficiently attractive evaluation where it would result in a solution better than any visited so far, then its tabu classification may be overridden. A condition that allows such an override to occur is called an aspiration criterion*.

Basic Ingredients of Tabu Search

* Glover, F. and Laguna, M., “Tabu Search.,” Norwell, MA: Kluwer Academic Publishers, 1997

Page 36: Hardware/Software Codesign of Embedded Systems

SITE, 2008 - HARDWARE/SOFTWARE CODESIGN OF EMBEDDED SYSTEMS

36

Components of Tabu Search

• Encoding• Initial solution• Objective Function• Move operator• Definition of Neighbourhood • Structure of Tabu list(s)• Aspiration criteria (optional)• Termination criteria

procedure tabu searchbegin initialize Tabu List (TL) = empty generate a (current} solution S let S* = S be the best solution so far

repeat repeat select the best point B in the neighbourhood of S: N(S) if(B is not Tabu: B TL) accept move: S=B update Tabu List: TL = TL B if(eval(B) > eval(S*)) S* = B else if (eval(B) > eval(S*)) accept move: S = B update best: S* = B end until (acceptable move found) until (halting-criterion)

Page 37: Hardware/Software Codesign of Embedded Systems

SITE, 2008 - HARDWARE/SOFTWARE CODESIGN OF EMBEDDED SYSTEMS

37

Components

Initial Solution – Random– Constructive

Memory Aspects1.Recency (short term)

How recently was I here?2.Frequency (long term)

How often have I been here ?3.Quality (aspiration)

How good is being here?4.Influence (aspiration)

How far away am I from where I have just been ?

Page 38: Hardware/Software Codesign of Embedded Systems

SITE, 2008 - HARDWARE/SOFTWARE CODESIGN OF EMBEDDED SYSTEMS

38

ComponentsTabu List Specifics

• The main objective of the tabu list is to avoid “cycles”, thus making a global optimizer rather than a local optimizer.

• Length – fixed or dynamic (generally 7 to 20)• Content - “from” attributes, “to” attributes; “move”

attributes; the more specific, the less restrictive• Frequency - tallying similar solutions through tabu

content. Usually used in penalty form rather than strict tabu.

Page 39: Hardware/Software Codesign of Embedded Systems

SITE, 2008 - HARDWARE/SOFTWARE CODESIGN OF EMBEDDED SYSTEMS

39

ComponentsNeighbourhood• Complete (deterministic)• Partial (probabilistic)• First improvement• Only improving

Aspiration criteria specifics • Best so far (Global)• Best in neighbourhood (Local)• Dissimilar to existing solution (diversification)• Similar to existing solution (intensification)• High influence – degree of change in structure or feasibility

Page 40: Hardware/Software Codesign of Embedded Systems

SITE, 2008 - HARDWARE/SOFTWARE CODESIGN OF EMBEDDED SYSTEMS

40

Basic Tabu Search Algorithm• Step 1: Choose an initial solution i in S. Set i* = i and k=0.

• Step 2: Set k=k+1 and generate a subset V* of solution in N(i,k) such that either one of the Tabu conditions is violated or at least one of the aspiration conditions holds.

• Step 3: Choose a best j in V* and set i=j.

• Step 4: If f(i) < f(i*) then set i* = i.

• Step 5: Update Tabu and aspiration conditions.

• Step 6: If a stopping condition is met then stop. Else go to Step 2.

Page 41: Hardware/Software Codesign of Embedded Systems

SITE, 2008 - HARDWARE/SOFTWARE CODESIGN OF EMBEDDED SYSTEMS

41

Tabu Search Stopping Conditions

Some immediate stopping conditions could be the following:

1. N(i, K+1) = 0. (no feasible solution in the neighborhood of solution i)2. K is larger than the maximum number of iterations allowed.3. The number of iterations since the last improvement of i* is larger than

a specified number.4. Evidence can be given than an optimum solution has been obtained.

Hillier and Lieberman outlined the tabu search stopping criterion by, for example, using a fixed number of iterations, a fixed amount of CPU time, or a fixed number of consecutive iterations without an improvement in the best objective function value. Also stop at any iteration where there are no feasible moves into the local neighborhood of the current trial solution.

Page 42: Hardware/Software Codesign of Embedded Systems

SITE, 2008 - HARDWARE/SOFTWARE CODESIGN OF EMBEDDED SYSTEMS

42

Flowchart of a Tabu Search AlgorithmInitial solution

(i in S)

Create a candidate list of solutions

Evaluate solutionsChoose the best

admissible solution

Stopping conditions satisfied ?

Update Tabu & AspirationConditions

Final solution

No

Yes

Page 43: Hardware/Software Codesign of Embedded Systems

SITE, 2008 - HARDWARE/SOFTWARE CODESIGN OF EMBEDDED SYSTEMS

43

Example : N-Queens Problem• Consists of placing n queens on an n n

chessboard in such a way that no two queens capture each other (aspiration criterion)

Q

Q Q

Q

3

2

1

1 2 3 4

4

Page 44: Hardware/Software Codesign of Embedded Systems

SITE, 2008 - HARDWARE/SOFTWARE CODESIGN OF EMBEDDED SYSTEMS

44

Encoding• The n-queens problem can be represented as a

permutation problem.• Let the queens be indexed by i• Mark queen i with the row’s index i• Let (i) be the index of the column where queen i is placed • A configuration is given by the permutation

= {(1),(2),…(n)}

Q

QQ

Q

3

2

1

1 2 3 4

4

= {3,1,4,2}

Q1: (1) = 3

Q2: (2) = 1

Q3: (3) = 4

Q4: (4) = 2

Page 45: Hardware/Software Codesign of Embedded Systems

SITE, 2008 - HARDWARE/SOFTWARE CODESIGN OF EMBEDDED SYSTEMS

45

Neighbourhood

• Swaps (pair-wise exchanges) can be used to define neighborhoods in permutation problems.

54 63 17 2

Current solution

14 63 57 2

Swap queens 2 and 6

=

’ =

move operator

Page 46: Hardware/Software Codesign of Embedded Systems

SITE, 2008 - HARDWARE/SOFTWARE CODESIGN OF EMBEDDED SYSTEMS

46

Structure of Tabu List

• To prevent the search from repeating swapping combinations tried in the recent past, we will classify all swaps Tabu for three iterations.

6

5

4

3

2

1

2 3 4 5 6 7

Tabu Memory

Each cell contains the # iterations remaining until the corresponding queens are allowed to exchange positions again

**

Page 47: Hardware/Software Codesign of Embedded Systems

SITE, 2008 - HARDWARE/SOFTWARE CODESIGN OF EMBEDDED SYSTEMS

47

54 63 17 2

Current solution

71 -2

swap value

42 -2

62 -2

65 -2

51 1

Top 5 (of 21) Candidates

6

5

4

3

2

1

2 3 4 5 6 7

Tabu Memory

3

2

1

1 2 3 4 5 6 7

7

6

5

4

# collisions = 4

QQ

QQQ

QQ

Iteration - 0

Page 48: Hardware/Software Codesign of Embedded Systems

SITE, 2008 - HARDWARE/SOFTWARE CODESIGN OF EMBEDDED SYSTEMS

48

52 63 17 4Current solution:

42 -1

swap value

61 0

52 0

21 1

31 1

Top 5 (of 20) Candidates

3

6

5

4

3

2

1

2 3 4 5 6 7

Tabu Memory

# collisions = 2

3

2

1

1 2 3 4 5 6 7

7

6

5

4

QQ

QQQ

QQ

Iteration - 1

54 63 17 2From Iteration 0:

Swap Q1 with Q7

Page 49: Hardware/Software Codesign of Embedded Systems

SITE, 2008 - HARDWARE/SOFTWARE CODESIGN OF EMBEDDED SYSTEMS

49

62 53 17 4Current solution:

31 0

swap value

71 1

42 1

54 1

76 1

Top 5 (of 19) Candidates

32

6

5

4

3

2

1

2 3 4 5 6 7

Tabu Memory

Tabu

Tabu

3

2

1

1 2 3 4 5 6 7

7

6

5

4

# collisions = 1

QQ

QQ

QQ

Q

Iteration - 2

From Iteration 1:

swap Q2 with Q4

52 63 17 4

Page 50: Hardware/Software Codesign of Embedded Systems

SITE, 2008 - HARDWARE/SOFTWARE CODESIGN OF EMBEDDED SYSTEMS

50

63 52 17 4Current solution

31 0

swap value

71 0

75 1

76 1

21 2

Top 5 (of 18) Candidates

23 1

6

5

4

3

2

1

2 3 4 5 6 7

Tabu Memory

3

2

1

1 2 3 4 5 6 7

7

6

5

4

# collisions = 1

QQ

QQ

QQ

QTabu

Tabu

Iteration - 3

From Iteration 2:

62 53 17 4

swap Q1 with Q3

Page 51: Hardware/Software Codesign of Embedded Systems

SITE, 2008 - HARDWARE/SOFTWARE CODESIGN OF EMBEDDED SYSTEMS

51

63 52 14 7

74 -1

swap value

75 -1

51 0

52 0

42 2

Top 5 (of 18) Candidates

1

3

2

6

5

4

3

2

1

2 3 4 5 6 7

Tabu Memory

3

2

1

1 2 3 4 5 6 7

7

6

5

4

# collisions = 2

QQ

QQ

QQ

QTabu

Tabu

Iteration - 4

63 52 17 4

Current solution

From Iteration 3:

swap Q5 with Q7

Page 52: Hardware/Software Codesign of Embedded Systems

SITE, 2008 - HARDWARE/SOFTWARE CODESIGN OF EMBEDDED SYSTEMS

52

63 72 14 5

31 -1

swap value

61 0

75 0

65 1

71 2

Top 5 (of 18) Candidates

32

1

6

5

4

3

2

1

2 3 4 5 6 7

Tabu Memory

3

2

1

1 2 3 4 5 6 7

7

6

5

4

# collisions = 1

QQ

QQ

QQ

Q*Tabu

Tabu

Iteration - 5

Satisfies aspiration criterion!!!

63 52 14 7

Current solution

From Iteration 4:

swap Q4 with Q7

*

Page 53: Hardware/Software Codesign of Embedded Systems

SITE, 2008 - HARDWARE/SOFTWARE CODESIGN OF EMBEDDED SYSTEMS

53

62 73 14 5

21

6

5

4

3

2

1

2 3 4 5 6 7

Tabu Memory

3

2

1

1 2 3 4 5 6 7

7

6

5

4

# collisions = 0

QQ

QQ

QQ

Q

Iteration - 6

Search Terminates

63 72 14 5

Current solution

From Iteration 5:

swap Q1 with Q3

Page 54: Hardware/Software Codesign of Embedded Systems

SITE, 2008 - HARDWARE/SOFTWARE CODESIGN OF EMBEDDED SYSTEMS

54

Example*– Minimum spanning tree problem with constraints.– Objective: Connects all nodes with minimum costs

A

B

D

C E

20 30

15 40

10 5

25

A

B

D

C E

20 30

15 40

10 5

25

Costs

An optimal solution without considering constraints

Constraints 1: Link AD can be included only if link DE also is included. (penalty:100)Constraints 2: At most one of the three links – AD, CD, and AB – can be included.(Penalty of 100 if selected two of the three, 200 if all three are selected.)

* Hillier, F.S. and Lieberman, G.J., “Introduction to Operations Research.” New York, NY: McGraw-Hill. 8th Ed., 2005

Page 55: Hardware/Software Codesign of Embedded Systems

SITE, 2008 - HARDWARE/SOFTWARE CODESIGN OF EMBEDDED SYSTEMS

55

Example

New cost = 75 (iteration 2)

( local optimum)

A

B

D

C E

20 30

15 40

10 5

25Delete Add

Iteration 1Cost=50+200 (constraint penalties)

Add Delete Cost

BE

BE

BE

CE

AC

AB

75+200=275

70+200=270

60+100=160

CD

CD

AD

AC

60+100=160

65+300=365

DE

DE

DE

CE

AC

AD

85+100=185

80+100=180

75+0=75

Constraints 1: Link AD can be included only if link DE also is included. (penalty:100)Constraints 2: At most one of the three links – AD, CD, and AB – can be included.(Penalty of 100 if selected two of the three, 200 if all three are selected.)

* Hillier, F.S. and Lieberman, G.J., “Introduction to Operations Research.” New York, NY: McGraw-Hill. 8th Ed., 2005

Page 56: Hardware/Software Codesign of Embedded Systems

SITE, 2008 - HARDWARE/SOFTWARE CODESIGN OF EMBEDDED SYSTEMS

56

Example

* A tabu move will be considered only if it would result in a better solution than the best trial solution found previously (Aspiration Condition)

Iteration 3 new cost = 85 Escape local optimum

A

B

D

C E

20 30

15 40

10 5

25Tabu

DeleteAdd

Tabu list: DEIteration 2 Cost=75

Add Delete Cost

AD

AD

AD

DE*

CE

AC

Tabu move

85+100=185

80+100=180

BE

BE

BE

CE

AC

AB

100+0=100

95+0=95

85+0=85

CD

CD

DE*

CE

60+100=160

95+100=195

Constraints 1: Link AD can be included only if link DE also is included. (penalty:100)Constraints 2: At most one of the three links – AD, CD, and AB – can be included.(Penalty of 100 if selected two of the three, 200 if all three are selected.)

* Hillier, F.S. and Lieberman, G.J., “Introduction to Operations Research.” New York, NY: McGraw-Hill. 8th Ed., 2005

Page 57: Hardware/Software Codesign of Embedded Systems

SITE, 2008 - HARDWARE/SOFTWARE CODESIGN OF EMBEDDED SYSTEMS

57

Add25

Example

* A tabu move will be considered only if it would result in a better solution than the best trial solution found previously (Aspiration Condition)

Iteration 4 new cost = 70 Override tabu status

A

B

D

C E

20 30

15 40

10 5

Tabu

Tabu

Delete

Tabu list: DE & BEIteration 3 Cost=85

Add Delete Cost

AB

AB

AB

BE*

CE

AC

Tabu move

100+0=100

95+0=95

AD

AD

AD

DE*

CE

AC

60+100=160

95+0=95

90+0=90

CD

CD

DE*

CE

70+0=70 105+0=105

Constraints 1: Link AD can be included only if link DE also is included. (penalty:100)Constraints 2: At most one of the three links – AD, CD, and AB – can be included.(Penalty of 100 if selected two of the three, 200 if all three are selected.)

* Hillier, F.S. and Lieberman, G.J., “Introduction to Operations Research.” New York, NY: McGraw-Hill. 8th Ed., 2005

Page 58: Hardware/Software Codesign of Embedded Systems

SITE, 2008 - HARDWARE/SOFTWARE CODESIGN OF EMBEDDED SYSTEMS

58

Example

Optimal Solution

Cost = 70Additional iterations only find

inferior solutions

A

B

D

C E

20 30

15 40

10 5

25

* Hillier, F.S. and Lieberman, G.J., “Introduction to Operations Research.” New York, NY: McGraw-Hill. 8th Ed., 2005

Page 59: Hardware/Software Codesign of Embedded Systems

SITE, 2008 - HARDWARE/SOFTWARE CODESIGN OF EMBEDDED SYSTEMS

59

Pros and Cons• Pros:– Allows non-improving solution to be accepted in order to escape

from a local optimum– The use of Tabu list– Can be applied to both discrete and continuous solution spaces– For larger and more difficult problems (scheduling, quadratic

assignment and vehicle routing), tabu search obtains solutions that rival and often surpass the best solutions previously found by other approaches [1].

• Cons:– Too many parameters to be determined– Number of iterations could be very large– Global optimum may not be found, depends on parameter

settings

Page 60: Hardware/Software Codesign of Embedded Systems

SITE, 2008 - HARDWARE/SOFTWARE CODESIGN OF EMBEDDED SYSTEMS

60

Advanced Topics

• Intensification: penalize solutions far from the current solution

• Diversification: penalize solutions close to the current solution

Page 61: Hardware/Software Codesign of Embedded Systems

SITE, 2008 - HARDWARE/SOFTWARE CODESIGN OF EMBEDDED SYSTEMS

61

Some Convergence Results

• Memory Tabu Search converges to the global optimum with probability one if randomly generated vectors (x) follows Gaussian or uniform distribution [6].

• Convergent Tabu Search converges to the global optimum with probability one [3].