In Search of the Optimal WHT Algorithm J. R. Johnson Drexel University Markus Püschel CMU

Abstract This presentation describes an approach to implementing and optimizing fast signal transforms. Algorithms for computing signal transforms are expressed by symbolic expressions, which can be automatically generated and translated into programs. Optimizing an implementation involves searching for the fastest program obtained from one of the possible expressions. We apply this methodology to the implementation of the Walsh-Hadamard transform. An environment, accessible from MATLAB, is provided for generating and timing WHT algorithms. These tools are used to search for the fastest WHT algorithm. The fastest algorithm found is substantially faster than standard approaches to implementing the WHT. The work reported in this paper is part of the SPIRAL project (see an ongoing project whose goal is to automate the implementation and optimization of signal processing algorithms.

The Walsh-Hadamard Transform n-fold “iterative” “recursive” Why WHT? Easy Structure Contains important constructor Close to 2-power FFT

Influence of Cache Sizes (Walsh-Hadamard Transform) Runtime L1L2 |signal| <= |L1|: iterative faster (less overhead) |signal| > |L1|: recursive faster (less cache misses) -Cache Quotients L1L2 Pentium II, LINUX

Increased Locality (Grid Algorithm) + Local access pattern + Can be generalized to arbitrary tensor products - Conflict cache misses due to 2-power stride (if cache is not fully associative) is computed

Runtime/L1-DCache Misses RuntimeL1 DCache Misses recursive iterative mixed grid 4-step grid 4-step vs. grid scrambling (dynamic data redistribution)

Effect of Unrolling Runtime L1 ICache Misses L2 Cache Misses iterative: loops vs. unrolled Compose small, unrolled building blocks Pentium II, LINUX

Class of WHT Algorithms Let N = N 1    N t, N i = 2 n i R = N; S = 1; for i = 1,…,t R = R/N i ; for j = 0,…,R-1 for k = 0,…,S-1 x(jN i S+k;S;jN i S+k+(N i -1)S) = WHT N i x(jN i S+k;S;jN i S+k+(N i -1)S); S = S*N i ;

Partition Trees Each WHT algorithm can be represented by a tree, where a node labeled by n corresponds to WHT 2 n iterative mixed recursive

Search Space Optimization of the WHT becomes a search, over the space of partition trees, for the fastest algorithm. The number of trees:

Size of Search Space Let T(z) be the generating function for T n T n =  (  n /n 3/2 ), where  =4+  8  Restricting to binary trees T n =  (5 n /n 3/2 )

WHT Package Uses a simple grammar for describing different WHT algorithms (allows for unrolled code and direct computation for verification) WHT expressions are parsed and a data structure representing the algorithm (partition tree with control information) is created Evaluator computes WHT using tree to control the algorithm MATLAB interface allows experimentation

WHT Package WHT(n) ::= direct[n] | small[n] | split[WHT(n 1 ),…,WHT(n t )] # n 1 + … + n t = n Iterative split[small[1],small[1],small[1],small[1]] Recursive split[small[1], split[small[1],split[small[1],small[1]]]] Grid 4-step split[small[2],split[small[2],W(n-4)]]

Code Generation Strategies Recursive vs. Iterative data flow (improve register allocation) Additional temps to prevent dependencies (aid C compiler)

Dynamic Programming Assume optimal WHT only depends on size and not stride parameters and state such as cache. Then dynamic programming can be used in search for the optimal WHT. Consider all possible splits of size n and assume previously determined optimal algorithm is used for recursive evaluations There are 2 n-1 possible splits for W(n) and n-1 possible binary splits

Generating Splits Bijection between splits of W(n) and (n-1)-bit numbers 000  1111 = [4] 001  111|1 = [3,1] 010  11|11 = [2,2] 011  11|1|1 = [2,1,1] 100  1|111 = [1,3] 101  1|11|1 = [1,2,1] 110  1|1|11 = [1,1,2] 111  1|1|1|1 = [1,1,1,1]

Sun Distribution 400 MHz UltraSPARC II

Pentium Distribution 233 MHz Pentium II (linux)

Optimal Formulas Pentium [1], [2], [3], [4], [5], [6] [7] [[4],[4]] [[5],[4]] [[5],[5]] [[5],[6]] [[2],[[5],[5]]] [[2],[[5],[6]]] [[2],[[2],[[5],[5]]]] [[2],[[2],[[5],[6]]]] [[2],[[2],[[2],[[5],[5]]]]] [[2],[[2],[[2],[[5],[6]]]]] [[2],[[2],[[2],[[2],[[5],[5]]]]]] [[2],[[2],[[2],[[2],[[5],[6]]]]]] [[2],[[2],[[2],[[2],[[2],[[5],[5]]]]]]] UltraSPARC [1], [2], [3], [4], [5], [6] [[3],[4]] [[4],[4]] [[4],[5]] [[5],[5]] [[5],[6]] [[4],[[4],[4]]] [[[4],[5]],[4]] [[4],[[5],[5]]] [[[5],[5]],[5]] [[[5],[5]],[6]] [[4],[[[4],[5]],[4]]] [[4],[[4],[[5],[5]]]] [[4],[[[5],[5]],[5]]] [[5],[[[5],[5]],[5]]]

Different Strides Dynamic programming assumption is not true. Execution time depends on stride.