GRASP with Ejection Chains for the dynamic memory allocation in embedded systems Marc Sevaux1 , André Rossi1 , Marı́a Soto2 , Abraham Duarte3 , Rafael Martı́4 1 Université de Bretagne-Sud, Lab-STICC, CNRS Centre de recherche B.P. 92116 F-56321 Lorient Cedex, France 2 Université de Technologie de Troyes Troyes, France 3 Universidad Rey Juan Carlos Dept. Ciencias de la Computación c/ Tulipán s/n, 28933 Móstoles, Madrid, Spain 4 Universidad de Valencia Dept. de Estadı́stica e Investigación Operativa c/ Dr. Moliner 50, 46100 Burjassot (Valencia), Spain March 13, 2013 Abstract In the design of electronic embedded systems, the allocation of data structures to memory banks is a main challenge faced by designers. Indeed, if this optimization problem is solved correctly, a great improvement in terms of efficiency can be obtained. In this paper, we consider the dynamic memory allocation problem, where data structures have to be assigned to memory banks in different time periods during the execution of the application. We propose a GRASP to obtain high quality solutions in short computational time, as required in this type of problem. Moreover, we also explore the adaptation of the ejection chain methodology, originally proposed in the context of tabu search, for improved outcomes. Our experiments with real and randomly generated instances show the superiority of the proposed methods compared to the state-of-the-art method. 5 10 15 20 25 1 Introduction The continuous advances in nano-technology have made possible a significant development in embedded systems (such as smartphones) to surf the Web or to process HD pictures. While technology offers more and more opportunities, the design of embedded systems becomes more complex. Indeed, the design of an integrated circuit, whose size is calculated in billions of transistors, thousands of memories, etc., requires the use of competitive computer tools. These tools have to solve optimization problems to ensure a low cost in terms of silicium area and running time. There exist some Computer Assisted Design (CAD) tools such as Gaut [2] to generate the architecture of a circuit from its specifications. However, the designs produced by CAD softwares are generally not energy aware, which is of course a major drawback. In the design of embedded systems, memory allocation is among the main challenges that electronic designers have to face. Indeed, electronics practitioners, to some extent, consider that minimizing power consumption is equivalent to minimizing the running time of the application to be executed by the embedded system [1]. Moreover, the power consumption of a given application can be estimated using an empirical model as in [6], and parallelization of data access is viewed as the main action point for minimizing execution time, and consequently power consumption. This paper is focused on memory allocation in embedded systems because of its significant impact on power consumption as shown by Wuytack et al. in [14]. We have addressed various simpler versions of the memory 1 30 35 40 45 50 55 60 allocation problem: in Soto et al. [12], we have proposed a mixed linear formulation and a variable neighborhood search (VNS) algorithm for the static version, and studied an even more simplified version of this problem in Soto et al. [11]. We have also dealt with the dynamic memory allocation problem in Soto et al. [13] for which an integer linear formulation and two iterative approaches have been devised. In this paper, we propose a GRASP with Ejection Chains for the dynamic memory allocation problem in embedded systems and compare it with the previous iterative approaches. The considered memory architecture is similar to the one of a TI C6201 device [6]. It is composed of m memory banks whose capacity is cj kilo Bytes (kB) for all j ∈ {1, . . . , m} and an external memory denoted by m + 1, which does not have a practical capacity limit. The processor needs q milliseconds for accessing data structures located in a memory bank, and it spends p × q more time when data structures are in the external memory. Time horizon is split into T time intervals whose durations may be different. The application to be implemented is assumed to be given as C source code, whose n data structures (i.e. variables, arrays, structures) have to be loaded in memory banks or the external memory. The size of data structure si for i ∈ {1, . . . , n} is expressed in kB. During each time interval t, the application requires accessing a given subset At of its data structures. We denote with a pair (a, b) when data structures a and b are simultaneously accessed. The set Dt contains all these pairs in time period t. The combinatorial nature of this problem comes from the fact that the processor can access all the memory banks simultaneously. For example, given a specific time interval, to compute a + b we may access a and b simultaneously. If they are allocated to different memory banks, we can access both of them at the same time, with the associated time saving, but if they are allocated to the same memory bank, we have to perform two different accesses. Thus, the cost of accessing simultaneously data structures a and b is d(a,b) , and if they are allocated to the same memory bank, the total access cost is 2 × d(a,b) , i.e. accessing sequentially a and b. However, if a or b are allocated to the external memory, the cost is p × d(a,b) , and if both are allocated to the external memory the cost is 2 × p × d(a,b) . Note that when we perform an operation such as a = a + 1, the accessing cost can be either 2 × d(a,a) or 2 × p × d(a,a) depending whether a is in a memory bank or the external memory. Finally, a data structure can be accessed in isolation (i.e., not in a pair) when for example, we perform the operation a = 5, then its cost is d(a,0) if it is in a memory bank, and p × d(a,0) if it is in the external memory. If we want to take into account the dynamic structure of the problem, the cost of changing a data structure between memory banks or with the external memory from the previous time interval to the current one is related to its size. In particular, if data structure a is in a memory bank at time interval t − 1 and in a different memory bank at time interval t we have a cost of ℓ × sa where ℓ is the duration of this physical move in milliseconds per kilo Bytes (ms/kB). Alternatively, if we change the allocation of a data structure between a memory bank and the external memory, the cost is v × sa where now the factor is given by v ms/kB. The later cost is particularly relevant because of hardware requirements. All the data structures are initially (say in t = 0) allocated to the external memory and therefore we assume this as initial solution for each data structure allocated to a memory bank in t = 1. We assume that v ≥ ℓ and v < p because a DMA (Direct Memory Access) controller is supposed to be part of the memory architecture, which allows for a direct access to data structures. Table 1 summarizes all the costs described above for a specific time interval. Table 1: Costs to evaluate a solution in a specific time interval Type Value Description Access d(a,b) 2 × d(a,b) p × d(a,b) 2p × d(a,b) ℓ × sa v × sa if a and b are in different memory banks if a and b are in the same memory bank if a or b is in the external memory if a and b are in the external memory a changed between memory banks a changed between a memory bank and the external memory Change 65 This paper is organized as follows. Section 2 shows how to represent a solution and evaluate it on an illustrative example. Section 3 presents the GRASP with the Ejection Chains methods. The proposed method is first tuned in our preliminary experimentation and then compared to previous iterative approaches in Section 5. Finally, Section 6 presents conclusions and future work for this problem. 2 2 70 75 80 85 Step by step example For the sake of illustration, this section presents a detailed computation of the cost of a solution. From now, we represent a solution x as a matrix with data structures in rows and time intervals in columns. Thus, given a data structure i in {1, . . . , n}, and a time interval t in {1, . . . , T }, x(i, t) = j with j in {1, . . . , m + 1} indicates that data structure i is allocated to memory bank j at time period t. Consider an example in which we have to allocate n = 12 data structures in m = 3 memory banks and the external memory, with T = 4 time periods. Additionally, consider that the size of the data structures is given by {65, 18, 95, 88, 99, 12, 19, 81, 10, 4, 79, 80} and each memory bank has a capacity of 111 kB. Then, a feasible solution x is given by the following (12,4)-matrix ⎛ ⎞ 1 4 4 4 ⎜2 2 2 2⎟ ⎜ ⎟ ⎜3 3 4 4⎟ ⎜ ⎟ ⎜2 2 2 4⎟ ⎜ ⎟ ⎜4 4 4 4⎟ ⎜ ⎟ ⎜1 1 1 1⎟ ⎜ ⎟. x=⎜ ⎟ ⎜1 1 1 1⎟ ⎜4 4 3 3⎟ ⎜ ⎟ ⎜3 3 3 2⎟ ⎜ ⎟ ⎜3 3 3 3⎟ ⎜ ⎟ ⎝4 4 4 2⎠ 4 1 1 1 As mentioned above, the entries in the matrix indicate the indexes of the memory banks (where 4 refers to the external memory). For example, in row 4, column 1, we have x(4, 1) = 2 which means that data structure 4 is allocated to memory bank 2 at time interval 1. If we consider the data structures at the same time interval (a column of the matrix) that are assigned to the same memory bank, we can see that the sum of their sizes do not exceed the capacity of this bank. For example, in the second column, we can see that memory bank 1 appears in rows 6, 7, and 12 (i.e., x(6, 2) = 1, x(7, 2) = 1, and x(12, 2) = 1). If we sum the sizes of these data structures, we obtain s6 + s7 + s12 =12 + 19 + 80 = 111, which is exactly the capacity of memory bank 2. It is easy to check that solution x verifies the capacity constraints of the three memory banks in the four time periods. Figure 1 illustrates the first two time periods (t = 1 and t = 2) of this solution in a diagram, in which memory banks appear as vertical boxes, labeled as MB1 , MB2 and MB3 respectively, and the external memory as a rectangular horizontal box labeled as MB4 . MB4 MB4 t=1 5 8 11 t=2 12 1 5 8 11 1 2 3 12 2 3 6 4 9 6 4 9 10 7 MB3 MB1 7 MB1 MB2 10 MB2 MB3 Figure 1: Example 90 Consider now that in the first time period we have to access the data structures A1 = {1, 2, 3, 4, 7, 9} with 6 pairs accessed simultaneously: D1 = {(1, 2), (1, 3), (1, 4), (1, 7), (2, 3) (2, 9)}, with associated costs: 62, 68, 37, 83, 18, and 33. To compute the total cost associated with the first time period, we note in Figure 1 that data structures 1 and 2 are in different memory banks (data structure 1 is in MB1 and data structure 2 is in MB2 ), therefore we consider their access cost of 62. Similarly for pairs (1,3), (1,4), (2,3), and (2,9) since their data structures are in 3 95 100 105 different memory banks. On the contrary, the cost of pair (1,7) is 2 × d(1,7) since data structures 1 and 7 are both in MB1 . The total access cost is therefore 62 + 68 + 37 + 2 × 83 + 18 + 33 = 384. To complete the cost computation at time period t = 1, we have to consider that initially (i.e., at t = 0), the n = 12 data structures are in the external memory and therefore, the data structures in the three memory banks, 1, 2, 3, 4, 6, 7, 9, and 10, have an associated cost of change of v × (65 + 18 + 95 + 88 + 12 + 19 + 10 + 4) = 311v. Therefore, the total cost at t = 1 is 384 + 311v. Similarly, we compute the cost of period t = 2, considering that A2 = {2, 3, 4, 5, 6, 10, 11, 12} and the following 5 pairs are accessed simultaneously: D2 = {(2, 10), (3, 11), (3, 12), (4, 5), (4, 6)}, with associated costs: 99, 45, 71, 17, and 98. To calculate the access cost in this time interval, we have to consider that data structure 4 is allocated to MB2 but data structure 5 is allocated to the external memory (as indicated with an arrow in Figure 1), and therefore the cost of pair (4,5) is p × d(4,5) = 17p. Similarly with pair (3,11) given that data structure 11 is in the external memory. Therefore the total access cost is now 99 + 45p + 71 + 17p + 98 = 268 + 62p. The cost of change computed at t = 2 accounts for the fact that data structure 1 is in the external memory (indicated with a circle in Figure 1), and it is in MB1 at t = 1. This has an associated cost of v × s1 = 65v. Similarly, data structure 12 is allocated to the external memory at time t = 1, and to MB1 at time t = 2 (highlighted with a circle in the figure). Therefore the cost is v × s12 = 80v. Then, the total cost generated at time period 2 is 268 + 62p + 145v. 3 110 115 120 125 The GRASP metaheuristic was developed in the late 1980s [3]. Each GRASP iteration consists in constructing a trial solution with some greedy randomized procedure and then applying local search from the constructed solution. This two-phase process is repeated until some stopping condition is satisfied. A best local optimum found over all local searches is returned as the solution of the heuristic. We refer the reader to [10] for recent surveys of this metaheuristic. Algorithm 1 shows the pseudo-code for a generic GRASP for minimization. The greedy randomized construction seeks to produce a diverse set of good-quality starting solutions from which to start the local search phase. Let x be the partial solution under construction in a given iteration and let C be the candidate set with all the remaining data structures that can be added to x. The GRASP construction uses a greedy function g(c) to measure the contribution of each candidate data structure c ∈ C to the partial solution x. A restricted candidate list RCL is the subset of candidate data structures from C with good evaluations according to g. In particular, if gmin and gmax are the minimum and maximum evaluations of g in C respectively, then RCL = {c ∈ C | g(c) ≤ gmin + α(gmax − gmin )}, where α is a number in [0, 1]. At each step, the method randomly selects a data structure c∗ from the restricted candidate list and adds this data structure to the partial solution. The construction is repeated in the inner while loop (steps 4 to 10) until there are no further candidates. If C = ∅ and x is infeasible, then a repair procedure needs to be applied to make x feasible (steps 12 to 14). Once a feasible solution x is available, a local search improvement is applied. The resulting solution is a local minimum. The GRASP algorithm terminates when a stopping criterion is met (typically a maximum number of iterations, time limit, or a target solution quality). The best overall solution x∗ is returned as the output of the heuristic. 3.1 130 135 140 GRASP Constructive methods To construct a solution we have to allocate the data structures, one by one, to the memory banks or the external memory in each time period. In this section we propose two different approaches; the first one sequentially constructs a solution starting with time period t = 1 and moving to next time period once the allocation of all data structures in the current one is completed. On the other hand, the second constructive method gives priority to the allocation of data structures that might generate the largest cost, regardless of their time period. Sequential approach In the sequential approach, SEQ, we first complete the assignments in a period and then we start the assignments in the next one. From the costs in Table 1, it is clear that the best option for a pair of data structures is to be allocated to different memory banks; however, they have a limited capacity and some data structures have to be eventually allocated to the same bank or in the external memory. Consider a partial solution in which we have assigned the data structures to the memory banks in time periods 1 to t − 1 and we have already assigned some of the data structures in period t. Let Ct be the candidate set of unassigned data structures at time period t. To determine the data structure and memory bank for the next assignment in our construction process, we compute for each data structure i ∈ Ct its evaluation g(i, t, j) to any possible memory bank j, or to the external memory (for which j = m + 1). 4 Algorithm 1: GRASP algorithm 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 145 f∗ ← ∞ while stopping criterion not satisfied do x←∅ Compute C with the candidate data structures that can be added to x while C = ∅ do forall the c ∈ C do compute g(c), gmin = minc∈C g(c) and gmax = maxc∈C g(c) Define RCL ← {c ∈ C | g(c) ≤ gmin + α(gmax − gmin )} with α ∈ [0, 1] Select c∗ at random from RCL(C) Add c∗ to partial solution: x ← x ∪ {c∗ } Update C with the candidate data structures that can be added to x x ← LocalSearch(x) if f (x) < f (x∗ ) then x∗ ← x; f ∗ ← f (x) return x∗ To compute g(i, t, j), we consider two types of costs. The first one is the cost related to the access to data structure i in the memory bank j at time interval t. This cost is denoted by total access(i, t, j) and defined by: |Ni,t | total access(i, t, j) =  access(j, x(ak , t), d(i,ak ),t ) (1) k=1 150 where Ni,t is the set of data structures which are in conflict with data structure i at time interval t, thus ak ∈ Ni,t . Two data structures i and ak are said to be in conflict at time period t if (i, ak ) ∈ Dt . Function access(j1 , j2 , d) defined in Equation (2) computes the access cost produced by a conflict whose cost is d and where its corresponding data structures are allocated to memory banks j1 and j2 respectively. Thus access(j, x(ak , t), d(i,ak ),t ) is the access cost generated by conflict (i, ak ) at time interval t where data structure i is allocated to memory bank j and x(ak , t) ∈ {1, . . . , m + 1} is the memory bank where ak is allocated. ⎧ d, if j1 = j2 and jk = m + 1, ∀k = 1, 2 ⎪ ⎪ ⎨ 2 × d, if j1 = j2 = m + 1 access(j1 , j2 , d) = (2) 2p × d, if j1 = j2 = m + 1 ⎪ ⎪ ⎩ p × d, otherwise The other cost involved in the evaluation function g(i, t, j) is the cost related to the change of a data structure between memory banks or between the external memory and a memory bank in consecutive time intervals. It is computed as follows: ⎧ if j1 = j2 ⎨ 0, (3) ℓ × si , if j1 = j2 and jk = m + 1, ∀k = 1, 2 change(i, j1, j2 ) = ⎩ v × si , otherwise 155 Thus, the evaluation function g(i, t, j) is given by: g(i, t, j) = total access(i, t, j) + change(i, x(i, t − 1), j) 160 (4) When the data structure i is not accessed during time period t, we have to consider the cost of change from the allocation in time interval t − 1, x(i, t − 1), and its trial allocation in t. Thus, the evaluation function is g(i, t, j) = change(i, x(i, t − 1), j) for all i ∈ / At . Equation (4) computes the increment in the cost of the current partial solution under construction, if data structure i ∈ At is assigned to a memory bank or to the external memory. However, feasible assignments only are considered; i.e., those for which data structure i can be added to a memory bank without exceeding its capacity. Once all feasible assignments have been evaluated, we compute the minimum and maximum of those values as: 5 gmin(t) = min {g(i, t, j) ∀j ∈ {1, . . . , m + 1}} i∈Ct gmax (t) = max {g(i, t, j) ∀j ∈ {1, . . . , m + 1}} i∈Ct Then, as shown in Algorithm 1, we compute the restricted candidate list RCL(t ) with the pairs of data structures in conflict and memory banks for which the evaluation is within the customary GRASP limits. Specifically, RCL(t ) = {(i, j) : i ∈ Ct and g(i, t, j) ≤ gmin (t) + α(gmax (t) − gmin (t))}, 165 170 175 180 185 190 195 200 205 where α is a number in [0, 1]. At each step, the method randomly selects a pair (i, j) from the restricted candidate list and performs the associated assignment (i.e., it assigns i to j at time interval t). The constructive algorithm, called SEQ, terminates when all the data structures have been assigned, for all the time periods. Conflict priority approach Our third constructive method, CPA, has two stages. In the first one we allocate the pairs of data structures from Dt for any time period t, and in the second one we allocate the remaining elements not in At for any time period t. T In the first stage we define D as the ordered set of pairs in t=1 Dt in decreasing values of the cost d(a,b),t . The restricted candidate list RCL is here simply computed as a fraction of the pairs in D. Specifically, we consider a percentage α of the largest elements in D. We then select one pair (a⋆ , b⋆ ) in RCL at random and allocate its elements in their time period t. To do that, we compute g(a⋆ , t, j) and g(b⋆ , t, j) ∀j ∈ {1, . . . , m + 1} and perform the best allocation. Once a pair has been allocated, it is removed from D. This operation is repeated as long as D = ∅. Note that the construction of the restricted candidate list does not follow the conventional adaptive scheme. In other words, the d(a,b),t values do not change from one construction step to the next. However, note also that finding the best allocation for the selected pair involves the computation of an adaptive value since g(i, t, j) depends on the previous assignments. In the second stage we allocate the remaining elements (i.e., those not present in the pairs). As previously defined, let Ct be the candidate set of unassigned data structures at time period t. We define C as the ordered T set of pairs (i, t) in t=1 Ct in decreasing values of the size si . As in the first stage, RCL contains a fraction α of the largest elements, from which we select one pair (a⋆ , t) at random. Finally, we allocate a⋆ in time t in the best memory bank according to g(i, t, j) and update C. The method finishes when all the elements in C have been allocated. The randomized nature of the constructive process permits to generate different solutions in each construction. We have empirically found that in some instances the allocation of all the elements in the external memory banks produces a trivial solution with a relatively good value. Therefore, we have included this trivial solution as the first construction of this method. 3.2 Local Search Since there is no guarantee that a randomized greedy solution is optimal, local search is usually applied after each construction step to attempt to find an optimal solution, or at least to obtain an improved solution with smaller cost than that of the constructed solution. This idea originates in the seminal paper by [3] for set covering and was later referred to as GRASP [4]. Given a feasible solution x of a combinatorial optimization problem, we define a neighborhood N (x) of x to consist of all feasible solutions that can be obtained by making a predefined modification to x. We say a solution x∗ is locally optimal if f (x∗ ) ≤ f (x) for all x ∈ N (x∗ ), where f is the objective function that we are minimizing. Given a feasible solution, a local search procedure finds a locally optimal solution by exploring a sequence of neighborhoods, starting from it. At the i-th iteration it explores the neighborhood of solution xi . If there exists some solution y ∈ N (xi ) such that f (y) < f (xi ), it sets xi+1 = y and proceeds to iteration i + 1. Otherwise, x∗ = xi is declared a locally optimal solution and the procedure stops. Insertions are used as the primary mechanism to move from a solution to another in the local search for the memory allocation problem. Specifically, given a solution x and a data structure i allocated to memory bank j at time period t (i.e., x(i, t) = j), we define move(i, t, j ′ ) as the removal of i from its current memory bank j, followed by its insertion in memory bank j ′ at time period t. This operation results in the solution y, as follows: 6 y(i, t) = j ′ y(i, t) = x(i, t) for t = t′ y(i′ , t) = x(i′ , t) for i′ = i and for all t Given a solution x and a data structure i in memory bank j at time period t, we define h(i, t, j) as its contribution to the solution value. If data structure i is accessed in one or more pairs in t, it can be computed as: h(i, t, j) = total access(i, t, j) + change(i, x(i, t − 1), j) + change(i, x(i, t + 1), j) 210 (5) This expression is similar to (4) in which we compute the cost for accessing data structure i in the memory bank j to execute the operation at time interval t. The second and third terms in (5) compute respectively the cost of change of i from period t − 1 to t and from t to t + 1. The later term was not involved in (4) since we computed there the cost of a partial solution under construction in which no data structure was assigned to period t + 1 at that stage. Therefore, h(i, t, j) sums all the costs generated with the assignment of data structure i in {1, . . . , n} to its current location j in {1, . . . , m + 1} at time interval t in {1, . . . , T }. Algorithm 2: Local Search 1 2 3 4 5 6 t←1 while t ≤ T do improved ←false At ← SortElementsInConf licts(t) forall the i ∈ At do j ⋆ ← arg min h(i, t, j ′ ) ′ 1≤j ≤m 7 8 9 10 11 12 13 14 215 220 225 230 j ← CurrentM emoryBank(i) if j = j ⋆ then move(i, t, j ⋆ ) improved ←true if improved = true and t = 1 then t←t−1 else t←t+1 Considering that we have n data structures at a given time period t (where we start with t = 1), there are n possible candidates for an insertion move. In other words, we can consider an allocation change for any data structure in this time period for improving the solution. However, instead of enumerating all these possibilities (i.e., scanning the entire neighborhood of the solution), we implement the so-called first strategy, in which we perform the first insertion move that improves the solution. In order to study first those data structures that are more likely to provide improving moves, our local search method first computes the contribution of all the data structures in a time period and orders them according to these values. Then, it scans the data structures in this order, where the data structure with the largest contribution comes first. As a result, it first explores those data structures with a large contribution since we can consider them as “badly allocated” and tries to re-allocate them in a different, and better, memory bank. Algorithm 2 shows the main steps of the local search method. In line 1, the time period t is initialized to 1. In line 4, we order the elements in conflict (accessed simultaneously) in time period t, At , according to their contribution. Once we select a data structure i ∈ At allocated to memory bank j at time period t, we compute h(i, t, j ′ ) for all memory banks. In line 6, we select the best memory bank j ⋆ . If j ⋆ = j (line 8), which indicates that h(i, t, j ⋆ ) < h(i, t, j), we move (in line 9) data structure i from memory bank j to j ⋆ if there is room in bank j ⋆ , since it results in a reduction of the solution value. Specifically, we perform move(i, t, j ⋆ ) and the value of the solution is reduced by h(i, t, j) − h(i, t, j ⋆ ). Once we have explored the possible assignments of data structure i to a different memory bank, and eventually moved it, we resort to the next data structure in the ordered list to study its associated moves. When we explore all the data structures with a positive contribution, we stop the scan of the candidate list (there is no point in moving data structures with a null contribution). At this stage, we set t = t − 1 7 235 240 if t > 1 in line 12 and explore the previous time period. The rational behind this strategy is to perform a backward step to re-allocate the elements linked with those recently moved in the current time period. Alternatively, if we have not found any improvement move in t, we set t = t + 1 in line 14, and apply the improvement method in the next time period. In any case, we compute the contribution of the data structures and proceed in the same fashion. The local search LS terminates when no data structure is moved after scanning all the time periods. It returns the associated local optimum. 4 Ejection chains MB4 6 1 4 12 3 5 11 9 2 10 7 8 MB1 MB3 MB2 Figure 2: Memory banks at t = 3 245 250 255 260 265 Consider the example in Section 2 in which we have to allocate n = 12 data structures in m = 3 memory banks and the external memory, in T = 4 time periods. We apply the greedy randomized constructive method to this instance with parameter values q = 1, p = 16, ℓ = 1 and v = 4, and we obtain a solution with a value of 15.692. Now we apply our local search method based on insertions to improve this trial solution, and we observe that the data structure with the largest contribution is data structure 6, allocated to the external memory (with index 4) at time period t = 3. Figure 2 shows a representation of the allocation of the data structures in memory banks at this time period. Data structure 6 has a contribution value of h(6, 3, 4) = 2.384, and the local search computes its alternative assignments at time period 3: h(6, 3, 1) = 533, h(6, 3, 2) = 622, and h(6, 3, 3) = 545, which are significantly lower than the value of its current assignment. Since there is room in memory bank 1 for data structure 6, we perform the move, insert (6, 3, 1) and obtain a new solution with value 15.692 − 2.384 + 533 = 13.841. We now resort to the next data structure in the ordered list according to their contribution. It is data structure 4 allocated to the external memory (with index 4) at t = 3 and a contribution to the solution value of h(4, 3, 4) = 1.424. We would move this data structure to memory bank 1 considering that its associated contribution is h(4, 3, 1) = 793; however, there is no room in memory bank 1 for this data structure (it has a remaining capacity of 34 units and this data structure has a size of 88). As a matter of fact, we cannot move this data structure to any other memory bank due to the associated evaluation or the size constraints. We therefore resort to the next data structure in the list and continue in this fashion. The previous example illustrates that some insertions cannot be performed because there is no room in the destination memory bank. This suggests that we could consider to make room there by moving one of its data structures elsewhere, implementing what is known in local search as a compound move or ejection chain. Glover and Laguna [5] introduced compound moves, often called variable depth methods, constructed from a series of simpler components. As is well-known, one of the pioneering contributions to this kind of moves was Lin and Kernighan [7]. Within the class of variable depth procedures, a special subclass called ejection chain procedures has recently been proved useful. An ejection chain EC is an embedded neighborhood construction that compounds the neighborhoods of simple moves to create more complex and powerful moves. It is initiated by selecting a set of data structures to undergo a change of state (e.g. to occupy new positions or receive new values). The result of this change leads to identifying a collection of other sets, with the property that the data structures of at least one must be “ejected from” their current states. State-change steps and ejection steps typically alternate, and the options for each depends on the cumulative effect of previous steps (it is usually impacted by the latest step). In some cases, 8 270 a cascading sequence of operations may be triggered, representing a domino effect. A successful application of this strategy on the max-cut problem can be found in [8]. Algorithm 3: Ejection Chain 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 t←1 while t ≤ T do improved ←false Dt ← SortElementsInConflicts(t) forall the i ∈ C do d←1 ieject ← i impEC ←false while (d ≤ dplimit) and impEC =false do j ⋆ ← arg minj∈MB h′ (ieject , t, j) j ←CurrentMemoryBank(ieject ) if j = j ⋆ then S ←EjectedElements(ieject , t, j ⋆ ) if S = ∅ then impEC ←true improved ←true else d ←d+1 ieject ← arg max h′ (k, t, j ⋆ ) k∈S 20 21 22 23 275 280 285 290 295 if improved = true and t = 1 then t←t−1 else t←t+1 In the memory allocation problem, when data structure i in memory bank j at time period t has a relatively large contribution to the objective function, the local search selects it to evaluate its insertion in a different memory bank, say j ′ , in order to reduce this contribution. In some cases however, this move is not feasible because j ′ does not have enough capacity for i (i.e. because the difference between its capacity and the sum of the sizes of the data structures in j ′ is lower than the size of this data structure). The EC local search then considers to move one of the data structures in j ′ , say i′ , to another memory bank on time period t, say j ′′ , to make room in j ′ for i. We may say that the insertion of i in j ′ caused i′ to be ejected to j ′′ , or, in other words, that we apply the ejection chain move(i, t, j ′ ) + move(i′ , t, j ′′ ) of depth 2. Clearly, the benefit of moving a data structure in j ′′ to another memory bank, say j ′′′ , could also be evaluated if one would like to consider chains of depth three. Longer chains are possible by applying the same logic. In EC, we define chain(i, dplimit) as the ejection chain that starts from moving vertex i and performs a maximum of dplimit consecutive insertion moves. Once a data structure i with a relatively large contribution at time period t is identified, EC starts by scanning alternative memory banks, in a random order, to allocate it. The chain then starts by making chain(i, dplimit) = {move(i, t, j ′ )} where j ′ is the first alternative memory bank considered. If this depth-1 move is improving and feasible (there is room in j ′ for i), it is executed and the chain stops. Otherwise, we search for move(i′ , t, j ′′ ) associated with a data structure i′ in j ′ . If the compound move of depth-2 is an improving and feasible move (there is room in j ′ for i and in j ′′ for i′ ), the move is executed and the chain stops; otherwise the chain continues until the compound move becomes improving and feasible or the depth of the chain reaches the pre-specified limit dplimit. If none of the compound moves from depth-1 to dplimit examined is an improving and feasible move, alternative memory banks (values of j and j ′ ) and data structures (values for i′ and associated trial data structures) are considered in a recursive exploration. If none of them is improving and feasible, no move is performed and the exploration continues with the next i data structure in the candidate list. Algorithm 3 shows the pseudo-code of the EC method. It starts by setting t = 1 at line 1. Then, at line 4, it orders data structures i in Dt according to their contribution. Line 6 sets the depth parameter d to 1, and defines at line 7 an auxiliary variable, ieject , with the element to be moved (initially equal to i). The while loop at line 9 9 300 305 allows the method to perform ejection chain steps as long as it improves, or the maximum depth limit, dplimit is reached. The best memory bank j∗ to move ieject , including those banks with no room for it, is identified in line 10. The move move(ieject , t, j∗) is performed at line 13 and the method computes the set S with all the elements in memory bank j∗ that create enough room to allocate ieject when removing them from j∗. The variables are then updated, including the ieject , which now is the best element in S in terms of its contribution (line 19). Lines 20 to 23 apply the same logic to scan the time periods described in the LS method. EC is a local optimizer and hence it performs only improving chains, although it is worth mentioning that these chains are compound of several insertion moves, and all of them are improving moves. Although the general design of the compound moves permits the implementation of non-improving single moves, for the sake of reducing the CPU time, we restrict ourselves to improving moves. 5 310 315 320 325 Computational results In this section, we first perform some preliminary experiments to set the appropriate search parameters and to compare our different methods. Then, we compare our best variant with the iterative approaches and ILP formulation in Soto et al. [13]. All algorithms have been implemented in Java SE 6 and run on an Intel Core i7 2600 CPU at 3.4 GHz with 3 GByte RAM. We have tested our metaheuristics using 45 real and artificial instances previously reported in Soto et al. [13]. Real instances originate from electronic design problems addressed in the Lab-STICC laboratory. Artificial instances originate from DIMACS [9] and they have been enriched by randomly generating conflict costs, number and capacity of memory banks, sizes and number of access to data structures. Artificially large instances allow us to assess our metaheuristics for the practical use for forthcoming needs, as technology tends to integrate more and more functionalities in embedded systems. In line with previous studies, the problem parameters are set as in the real electronic applications. The time q spent by the processor to access data structures to memory banks is set to 1 ms, the factor p to access data structures to external memory is set to 16, as with TI C6201. The cost v for moving a data structure from the external memory to memory banks and vice versa is set to 4 ms/kB and cost for moving data structures between memory banks is equal to 1 ms/kB. We perform our preliminary experimentation with 8 representative instances with different sizes and characteristics. They are: fpsol2i2dy, mpeg2enc2dy, mug100-25dy, myciel7dy, queen5-5dy, r125.1cdy, treillisdy, and zeroin-i1dy. In the first experiment we compare the two constructive methods described in Section 3.1, SEQ and CPA. For each method and instance, Table 2 reports the value of the best solution found across 100 constructions, Value, the running time in seconds, CPU, and the average percent deviation from the best solution in this experiment, Dev. Additionally, this table reports in column Best a 1 or a 0 indicating whether the method is able or not to obtain the best solution. The last column summarizes the information, reporting the average Value, CPU and Dev., and the sum of the Best values (i.e., the number of instances in which the method obtains the best solution). Table 2: Constructive methods Instances Name 330 335 SEQ CPA Value CPU Dev. Best Value CPU Dev. Best fpsol2i2dy mpeg2enc2dy mug100-25dy myciel7dy queen5-5dy r125.1cdy treillisdy zeroin-i1dy 3577023.00 14548.81 57462.00 986793.00 57595.00 3538925.00 4138.81 1942869.00 35.0 0.0 0.0 1.0 0.0 71.0 0.0 43.0 2.49% 0.00% 0.00% 1.08% 11.41% 3.42% 0.00% 6.24% 0 1 1 0 0 0 1 0 3489953.00 14548.80 57650.00 976216.00 51698.00 3421905.00 4138.81 1828682.00 37.0 0.0 0.0 1.0 0.0 73.0 0.0 44.0 0.00% 0.00% 0.33% 0.00% 0,00% 0,00% 0.00% 0.00% 1 1 0 1 1 1 1 1 Summary 1272419.32 18.7 3.08% 3 1230598.95 19.4 0.04% 7 Table 2 shows that constructive method CPA outperforms the sequential method, SEQ. Specifically, CPA presents an average deviation of 0.04% obtained in 19.4 seconds, which compares favorably with the average deviation of 3.08% obtained with SEQ in 18.7 seconds. Moreover, CPA is able to obtain 7 best solutions in this experiment while SEQ obtains 3 out of the 8 considered instances. In our second experiment, we compare the two complete GRASPs formed by the constructive methods coupled with the local search. We denote them as CPA+LS and SEQ+LS. Table 3 shows for each method and each of the 8 instances considered, the value of the best solution found across 10 constructions with local search, Value, as well as the other three statistics described above: CPU, Dev., and Best. 10 Table 3: GRASP methods Instances Name fpsol2i2dy mpeg2enc2dy mug100-25dy myciel7dy queen5-5dy r125.1cdy treillisdy zeroin-i1dy Summary 340 345 SEQ+LS CPA+LS Value CPU Dev. Best Value CPU Dev. Best 2814803.00 10808.34 32673.00 631631.00 35210.00 3130709.00 3847,81 871604.00 86.0 0.0 0.0 2.0 0.0 81.0 0.0 50.0 0.00% 0.01% 0.12% 32.67% 28.03% 0.00% 60.11% 48.53% 1 0 0 0 0 1 0 0 2816210.00 10807.80 32633.00 476107.00 27501.00 4282700.00 2403.30 586823.00 66.0 0.0 0.0 1.0 0.0 14.0 0.0 8.0 0.05% 0.00% 0.00% 0.00% 0.00% 36.80% 0.00% 0.00% 0 1 1 1 1 0 1 1 941410.77 27.4 21.18% 2 1029398.10 11.1 4.61% 6 Table 3 shows that the CPA+LS method obtains better results than the SEQ+LS in shorter running times. In particular CPA+LS presents an average percent deviation of 4.61% obtained in 11.1 seconds, while SEQ+LS exhibits an average of 21.18% obtained in 21.18 seconds. Additionally, CPA+LS matches 6 best solutions in this experiment while SEQ+LS obtains 2 out of the 8 instances considered. Therefore, in the following experiments we considered the CPA+LS as the GRASP method. In our final preliminary experiment, we compare the contribution of the ejection chain post-processing (EC) and the influence of the depth limit parameter, dplimit, in this method. Table 4 reports the average results of Value, CPU, Dev., and the number of best solutions found with the GRASP (CPA+LS) runs for 100 iterations and the same GRASP method run for 10 iterations in which we apply the EC(dplimit) post-processing, with a given value of the depth parameter, after the application of the LS. We have tested the values 2, 3, 4, and 5 for the depth limit parameter. Table 4: GRASP with Ejection Chains Method GRASP(10)+EC(2) GRASP(10)+EC(3) GRASP(10)+EC(4) GRASP(10)+EC(5) GRASP(100) 350 355 360 365 370 Value CPU Dev. Best 655395.44 655009.06 654848.31 654848.31 868135.70 90.5 100.25 95.625 93.375 219.75 8.47% 8.44% 8.44% 8.44% 27.88% 3 4 5 5 2 Results in Table 4 indicate that the ejection chain post-processing significantly improves the GRASP method. Specifically, the last line in this table shows that the GRASP runs for 100 iterations (construction plus local search) obtains an average percent deviation of 27.88% in 219.75. All the ejection chain variants tested, applied on a GRASP run for 10 iterations, are able to improve the GRASP in lower CPU time. In particular, GRASP(10)+EC(4) exhibits a remarkable 8.44% average deviation achieved on 95.625 seconds. In our final experiment, we compare the GRASP(10) and the GRASP(10)+EC(4) with the Iterative Metaheuristic, IM, proposed in Soto et al. [13], and considered the best published method. Table 5 shows in the first column the name of the instance, in the second column the best known value, which appears in bold when our new methods are able to improve it in this experiment w.r.t the best previously identified. The next column presents the solution value reached by the ILP formulation in Soto et al. [13] solved with Xpress-MP, that is used as a heuristic when the time limit of one hour is reached: the best solution found so far is then returned by the solver. Note that in some large instances, this method is not able to provide a solution within the 3,600 seconds of time limit considered. The rest of the columns appear in groups of three for each of the three methods under comparison. They respectively report the deviation value with respect to the best known value (shown in column 2), the Best value indicating whether it matches or not the best known, and the CPU time in seconds. The last row in this table summarizes the results. Results in Table 5 clearly indicate the superiority of the new approaches with respect to the previous one. In particular, GRASP(10) presents an average percentage deviation of 27.26% and 4 best solutions achieved on 27.3 seconds on average, GRASP(10)+EC(4) 6,56% and 20 best solutions in 130.5 seconds, while the previous IM method presents an average percentage deviation of 61.59% and 16 best solutions achieved on 710.9 seconds on average. We applied the non-parametric Friedman test for multiple correlated samples to the best solutions obtained by each of the 3 methods. This test computes, for each instance, the rank value of each method according to solution quality (where rank 1 is assigned to the best method and rank 3 to the worst one). Then, it calculates the average 11 Table 5: Final comparsion Instance adpcmdy.dat alidydy.dat cjpegdy.dat compressdy.dat fpsol2i2dy.dat fpsol2i3dy.dat gsm newdy.dat gsmdy.dat gsmdycorrdy.dat inithx i1dy.dat lmsbdy.dat lmsbv01dy.dat lmsbvdy.dat lmsbvdyexpdy.dat lpcdy.dat mpeg2enc2dy.dat mpegdy.dat mug100 1dy.col mug100 25dy.col mug88 1dy.col mug88 25dy.col mulsol i1dy.dat mulsol i2dy.dat mulsol i4dy.dat mulsol i5dy.dat myciel3dy.col myciel4dy.col myciel5dy.col myciel6dy.col myciel7dy.col queen5 5dy.col queen6 6dy.col queen7 7dy.col queen8 8dy.col r125.1cdy.col r125.1dy.col r125.5dy.col spectraldy.dat treillisdy.dat turbocodedy.dat volterrady.dat zeroin i1dy.dat zeroin i2dy.dat zeroin i3dy.dat Best Known ILP Obj. Func. Dev. IM Best CPU(s) 44192 108699 4466800 342592 2794787 2762059 7808 1355390 494118 6280430 7409669 4350640 4323294 4367024 26888 9812 10613.625 28890 30499 25527 24310 518278 654533 570529 574723 6379 18455 41938 108077 447000 27395 47174 81102 154499 1225115 61537 741388 15472 1805.5625 3195 178 576320 557295 620385 44192 108699 4466800 342592 * * 7808 1355390 494118 * 7409669 4350640 4323294 4367024 26888 9886.81162 10613.625 * * * * * 764693 * 748781 6379 18455 41938 108077 486449 * * * * * 61537 * 15472 1805.5625 3195 178 * * 750128 0.00% 927.33% 0.00% 0.00% 52.29% 49.81% 0.00% 0.00% 0.00% 63.69% 0.00% 0.00% 0.00% 0.00% 0.00% 0.00% 0.15% 0.00% 0.00% 0.00% 0.00% 146.34% 94.33% 106.05% 121.00% 89.14% 44.88% 31.20% 66.31% 79.11% 34.16% 64.55% 130.07% 150.35% 90.93% 83.24% 105.27% 0.03% 0.02% 1.60% 0.00% 49.26% 67.91% 60.81% 1 0 1 1 0 0 1 0 1 0 1 1 1 1 1 1 0 1 1 1 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0.0 160.5 0.0 0.0 3463.4 1062.4 0.0 0.0 0.0 13449.3 0.3 0.0 0.0 0.0 0.0 0.8 0.1 14.7 11.9 11.4 7.8 1396.1 1286.7 1657.4 1480.8 1.2 6.1 28.9 95.0 377.1 4.8 283.7 42.8 82.6 950.5 33.4 1028.9 0.0 0.0 0.1 0.0 1691.2 1186.3 1463.7 0.00% 162.54% 0.00% 2.67% 0.74% 1.18% 0.00% 0.13% 0.35% 0.11% 0.33% 1.13% 0.00% 2.63% 22.02% 9.99% 4.73% 25.65% 6.10% 9.23% 12.41% 70.08% 24.09% 49.03% 15.13% 8.95% 26.10% 38.66% 52.35% 30.75% 8.98% 9.78% 43.12% 17.41% 136.09% 15.87% 92.65% 6.72% 113.11% 33.49% 7.87% 60.75% 39.35% 37.03% 1 0 1 0 0 0 1 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0.0 3.0 0.0 0.0 91.0 87.0 0.0 0.0 0.0 702.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 40.0 24.0 26.0 25.0 0.0 0.0 0.0 0.0 2.0 0.0 0.0 0.0 0.0 84.0 0.0 27.0 0.0 0.0 0.0 0.0 49.0 21.0 20.0 0.00% 48.75% 0.00% 0.00% 0.00% 0.00% 0.00% 0.13% 0.36% 0.21% 0.14% 1.88% 1.14% 1.88% 26.19% 10.14% 26.54% 21.47% 7.00% 12.74% 11.40% 0.00% 0.00% 0.00% 0.00% 11.26% 10.21% 8.55% 15.27% 0.00% 0.05% 0.00% 0.00% 0.00% 0.00% 12.26% 0.00% 0.00% 33.10% 20.09% 7.87% 0.00% 0.00% 0.00% 1 0 1 1 1 1 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 1 1 1 0 0 0 0 1 0 1 1 1 1 0 1 1 0 0 0 1 1 1 0.0 85.0 0.0 0.0 1000.0 1000.0 0.0 0.0 0.0 1000.0 0.0 1000.0 0.0 1000.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 66.0 71.0 56.0 59.0 0.0 0.0 0.0 1.0 18.0 0.0 0.0 0.0 2.0 120.0 0.0 26.0 0.0 0.0 0.0 0.0 79.0 103.0 58.0 61.59% 16 710.9 27.26% 4 27.3 6.56% 20 130.5 12 GRASP(10) Dev. Best CPU(s) GRASP(10)+EC(4) Dev. Best CPU(s) 375 380 rank values of each method across all the instances solved. If the averages differ greatly, the associated p-value or significance will be small. The resulting p-value of 0.026 obtained in this experiment clearly indicates that there are statistically significant differences among the methods tested. Specifically, the rank values produced by this test are 1.69 (GRASP(10)+EC(4)), 2.11 (IM), and 2.20 (GRASP(10)). We finally compare the best two methods, according to the ranking above, with the well-known Wilcoxon test for pairwise comparisons, which answers the question: Do the two samples (solutions obtained with GRASP(10)+EC(4) and IM in our case) represent two different populations? The resulting p-value of 0.001 indicates that the values compared come from different methods (using the typical significance level of α = 0.05 as the threshold between rejecting or not rejecting the null hypothesis). Summarizing the experimentation above, we can therefore conclude that our new proposal, hybridizing GRASP with ejection chains, outperforms the state-of-the-art method for the dynamic memory allocation problem. 6 385 390 In this paper we propose several heuristics based on GRASP and ejection chains for the dynamic memory allocation problem. The proposed GRASP heuristics consist of two randomized greedy construction procedures and a local search procedure. An ejection chain intensification algorithm was also proposed and tested as a post-processing of the GRASP. We performed a computational comparison of our proposals and a previous method. It clearly shows that our GRASP with ejection chains is able to improve the previous method for the problem considered. The performance of our method is definitely enhanced by the context-specific strategies described in Sections 3 and 4 that we developed for this problem. However, we hope other researchers might find effective and GRASP with ejection chains could become a standard hybrid method in future implementations. 7 395 Conclusion Acknowledgment This research was partially supported by the grant-invited -Professors-UBS-2012 of France, and by the the Ministerio de Economı́a y Competitividad of Spain (TIN2009-07516 and TIN2012-35632-C02). References [1] A. Chimientia, L. Fanucci, R. Locatellic, and S. Saponarac. VLSI architecture for a low-power video codec system. Microelectronics Journal, 33(5):417–427, 2002. 400 [2] P. Coussy, E. Casseau, P. Bomel, A. Baganne, and E. Martin. A formal method for hardware IP design and integration under I/O and timing constraints. ACM Transactions on Embedded Computing System, 5(1):29–53, 2006. [3] T.A. Feo and M.G.C. Resende. A probabilistic heuristic for a computationally difficult set covering problem. Operations Research Letters, 8:67–71, 1989. 405 [4] T.A. Feo and M.G.C. Resende. Greedy randomized adaptive search procedures. Journal of Global Optimization, 6:109–133, 1995. [5] F. Glover and M. Laguna. Tabu search. Kluwer Academic Publishers, 1997. [6] N. Julien, J. Laurent, E. Senn, and E. Martin. Power consumption modeling and characterization of the TI C6201. IEEE Micro, 23(5):40–49, 2003. 410 [7] S. Lin and B. Kernighan. An effective heuristic algorithm for the traveling salesman problem. Operations Research, 21:498–516, 1973. [8] R. Martı́, A. Duarte, and M. Laguna. Advanced scatter search for the max-cut problem. INFORMS Journal on Computing, 21 (1):26–38, 2009. [9] D. Porumbel. DIMACS graphs: Benchmark instances and best upper bound, 2009. 13 415 420 [10] M.G.C. Resende and C.C. Ribeiro. Greedy randomized adaptive search procedures. In J.Y. Potvin and M. Gendrau, editors, Handbook of Metaheuristics - 2nd edition, pages 283–320. Kluwer Academic Publishers, 2010. [11] M. Soto, A. Rossi, and M. Sevaux. Métaheuristiques pour l’allocation de mémoire dans les systèmes embarqués. In Proc. ROADEF 11e congrès de la société Française de Recherche Opérationelle est d’Aide à la Décision, pages 35–43, Toulouse, France, 2010. [12] M. Soto, A. Rossi, and M. Sevaux. A mathematical model and a metaheuristic approach for a memory allocation problem. Journal of Heuristics, 18(1):149–167, mar 2011. 425 [13] M. Soto, A. Rossi, and M. Sevaux. Two iterative metaheuristic approaches to dynamic memory allocation for embedded systems. In P. Merz and J.K. Hao, editors, Evolutionary Computation in Combinatorial Optimization - 11th European Conference, EvoCOP 2011, Torino, Italy, April 27-29, 2011. Proceedings, volume 6622 of Lecture Notes in Computer Science, pages 250–261. Springer, 2011. [14] S. Wuytack, F. Catthoor, L. Nachtergaele, and H. De Man. Power exploration for data dominated video application. In Proc. IEEE International Symposium on Low Power Electronics and Design, pages 359–364, Monterey, CA, USA, 1996. 14