Block Packing: From Puzzle-Solving to Chip Design Igor Markov, Advanced Computer Architecture Lab

Students Hayward Chan: optimal block-packing undergraduate student Saurabh Adya: industrial-strength placement will be getting his Ph.D. in May

Overview The rectangle packing problem Packing representations Optimal block-packer Slicing packings: an approximation Optimal slicing block-packer Large-scale block-packing

Rectangle Packing Problem Given rectangles (blocks) R1,…,Rn, assign orientation (rotated 90°?) and location to (the lower-left corner of) each of them s.t. no blocks overlap the bounding box of all rectangles is as small as possible The decision version is NP-complete

Example Bad Better

Packing Representations Locations of blocks? R1 at (0,3), R2 at (2,1) etc… Pros: simple, no effort to realize the packing Cons: hard to detect overlaps infinitely many possible assignments, most of which are redundant

Redundant Packings Not compacted packings are redundant left-compact -no block can move left fixing other blocks bottom-compact -no blk can move down fixing other blks Only have to consider left-bottom-compact packings

R. Korf’s Ongoing Work An optimal block packer for fixed-size blocks Location-based Assumes that block dimensions are small integers Uses new pruning techniques: wasted-space bounds, dominance-based pruning, etc Cannot process soft blocks

Combinatorial Representations Implicit representations, e.g., topological the implied block locations cause no overlaps optimal packing can be captured only a finitely variety (the smaller the better) the overhead to figure out block locations is small Facilitate faster algorithms Simulated annealing Branch-and-bound

Sequence Pair Represents a packing of n blocks by two permutations of order n [Murata et.al ’96], e.g. <1234, 4132> for 4 blocks Encodes a relative constraint for each pair of blocks Namely, for blocks a and b, <…a…b…, …a…b…> = a is on the left of b <…a…b…, …b…a…> = a is above b

Sequence Pair --- example Consider <1234, 4132>, <..1..3.., ..1..3..>, so R1 is left of R3 <..2..3.., ..3..2..>, so R2 is above R3

Properties of Sequence Pairs optimal solution can be encoded (n!)2 sequence pairs for n blocks can compute block locations in O(n2) time O(n log n) and even O(n log log n) algos exists However, many represented packings are not compacted several sequence-pairs represent same packing

O-Tree Represent a packing by a rooted-ordered tree [Guo et.al ’99], where: Root = left boundary of the bounding box Each node (≠ root) represents a block x-coord(child) = x-coord(parent) + width(parent)

Encoding an O-Tree (1) A rooted-ordered tree can be encoded as a bit-vector, that records its pre-order traversal Start with the root, 0 records “down” 1 records “up” Encoding: 0010001111001101

Encoding an O-Tree (2) Notation: <T,p,d> denotes an O-Tree where T is a bit-vector describing the tree (2n bits) p is a permutation, recording sequence of block visited in pre-order traversal (perm. of order n) d is a bit-vector, same length as p, recording orientations of the blocks (n bits) d(i) = 0 means block p(i) is not rotated d(i) = 1 means block p(i) is rotated by 90°

Example of an O-Tree Tree T Permutation P Orientation d 0010001111001101 Permutation P 5 3 8 2 4 6 7 1 Orientation d 0 0 1 0 1 0 0 0

Properties of O-Trees Encode only bottom-compact solutions, including optimal ones Solution space is O(n! 25n-3 / n1.5) (smallest known for FP representations) O(n) time to compute block locations We chose O-Trees for our optimal packer because of small solution space

Optimal Block-Packer Branch-and-bound Searches in the space of partial O-Trees Successor function appends: 2 bits to T (partial tree) 1 blocks to p (partial permutation) 1 bit to d (partial orientation bit-vector) Depth-first traversal Blocks are indexed from 1 to n

Optimal Block-Packer At any time, we have a partial packing Example: suppose T, p, d are incomplete T = 0010001111 p = 5 3 8 2 4 d = 00000

Optimal Block-Packer Not all bit-vectors of length 2n specify a tree For example (n = 3): 001110 (too many up-edges) 000001 (too many down-edges) A bit-vector of length 2n specifies a tree for n blocks iff, for every prefix, # 0’s ≥ # 1’s # 0’s ≤ n Every time when we append 2 bits to T, we check if the result satisfies the criteria (if not, backtrack)

Area Lower Bounds Given a partial packing, we can estimate the dead-space of all extended solutions minimum bounding rectangle all unplaced block will be packed above the partial packing, hence its bounding rectangle gives an area lower bound

Area Lower Bounds permanent dead-space: dead-space below a block in the partial packing

Area Lower Bounds extended dead-space if the “valley” above a block is narrower than any unplaced block, then the dead-space is permanent

Area Lower Bounds trial-block estimation any unplaced block A locates above the partial packing for an unplaced block A, estimate the area of extended packings by putting A in several spots

Area Lower Bounds minimum min-edge estimation min-edge of a block: its shorter edge minimum square: a square whose side is the minimum of the min-edges among all unplaced blocks if T has more 0’s than 1’s, then place the minimum squares according to T

Non Left-compact Packings O-Tree specifies left-compact packings not necessarily bottom-compact require every block to touch its parent

Dominance a packing can be flipped/rotated to 7 other orientations can to consider only one orientation require the lower-left blocks to have smallest index among the “corner blocks”

Identical Blocks Identical blocks come up very frequently can be interchanged regardless where they are require the one with lower index proceeds the other in p size of solution space shrinks by (k!) if k blocks are identical

Empirical Results Runtime depends on: presence of identical blocks ``quality’’ of the optimal solution optimal solution has a lot of dead-space usually means the lower bounds are loose deadspace is often large when blocks have extreme aspect ratios and/or areas

Empirical Results Can pack up to 9 blocks in 12 mins w/o identical blocks (12 blocks with only 2 types of blocks) Dead-space % decreases with # blocks Dead-space % decreases when the blocks are similar (in terms of aspect ratios,area)

Slicing Packings General packings are hard to analyze (lack of structure) Slicing packings: the bounding box can be recursively cut horizontally/vertically into rooms each room has exactly one block

Slicing Packings --- example For example: Slicing Floorplan Slicing Packing

Slicing Packings Slicing packings are easier to deal with since they are hierarchical a slicing packing is made of 2 smaller ones easier to make incremental changes to a block simple representation: binary tree

Slicing Tree A slicing (binary) tree represents a slicing packing where: the leaves represents a block (n of them) each internal node denotes a horizontal or a vertical merger of its children + for vertical merger * for horizontal merger

Slicing Tree --- example

Polish expression Encode a slicing tree using its post-order traversal The Polish expression: 1 2 * 3 * 4 5 6 + * +

Optimal Slicing Block-Packer branch-and-bound looks for the optimal slicing packing searches in the space of partial Polish expressions successor function appends: either a block or a + or * if possible

Empirical Results pack 12 distinct blocks in 10 min (16 blocks if there are only 2 types) gap between optimal slicing and non-slicing packing is less than 1.5% on average

Large-scale Block-Packing Solve large instances hierarchically: group blocks into clusters pack each cluster optimally treat each cluster as a block, and pack them into higher-level clusters

Hierarchical Block-Packing

Hierarchical Block-Packing Other tricks: store multiple shapes for each cluster, hopefully can pack tighter at a higher-level avoid clusters with extreme aspect ratios by imposing constraint during search stop at packings that are slightly suboptimal (e.g. 2%): large speed up

Empirical Results Robust performance on sets of 10, 100, 1K, 10K blocks consistent solution quality runtime grows near-linearly improves the best published results (both runtime and solution quality)

Sample Packing ami49_40: 1960 blocks, 3.25% dead-space, obtained in 185s on a 1.2GHz Athlon.

Summary Optimal rectangle-packing is NP-hard and also hard in practice Location-based vs topological packing representations Slicing packings are surprisingly good Our optimal block-packers BloBB & Compass are available Extensions to large-scale block-packing