F Pacheco-Torgal

S Jalali

J C Morel

J E Aubert

Y Millogo

E Hamard

A Fabbri

Some observations about the paper "Earth construction: Lessons from the past for future eco-efficient construction" by

As the starting point of this discussion, we would like to congratulate the authors for this interesting review [START_REF] Pacheco-Torgal | Earth construction: Lessons from the past for future ecoefficient construction[END_REF], which defends the use of earth as a building material. Indeed, while this is one of the oldest building materials in the world, it is also one of the less studied by the scientific community, and thus, one of the less understood. However, as stated by the two authors of this review, the number of scientific studies on this subject has increased dramatically in recent years. There searches on earth as a building material are mainly motivated by the growing demand of masons and construction companies for scientific data and evidence to evaluate and improve the wealth, the hygrothermal comfort and the seismic resistance of earth construction. First of all, we share the approach proposed by the author that consists of connecting the past and present (and even the future). This point is well illustrated by the first paragraph of the paper and its attractive title. Indeed, we think that the comparisons between the characteristics of modern earthen material sand existing ones, which have proven their effectiveness over the decades, is a major key to improve our understanding of this multi-scale composite material. The authors wish here to compare their views with those of Pacheco-Torgal and Jalali and highlight the following three main points of disagreement that justify this discussion.

The present and the future of unstabilised earth constructions

Throughout the article, the authors seem to postulate that the stabilisation technique (e.g., addition of hydraulic binders) is a compulsory step for earth construction. This leads to quite surprising conclusions about the cost and environmental impacts and their assumed direct link with the nature and amount of the binder used. These conclusions become even stranger if we consider cement stabilisation, which could be irrelevant from environmental, economic and technical perspectives. Indeed, if this stabilisation is efficient in the case of kaolinic clay materials containing appreciable amount of sand [START_REF] Millogo | Microstructural characterization and mechanical properties of cement stabilised adobes[END_REF], the same is not necessarily the case for raw clay materials rich in montmorillonite [START_REF] Molard | Study of the extrusion and stabilization with cement of monomineralogic clay[END_REF][START_REF] Amor | Cold stabilization of montmorillonitebased materials using Portland cement[END_REF][START_REF] Temimi | Making building products by extrusion and cement stabilization: limits of the process with montmorillonite clay[END_REF]. From this partial point of view on the stabilisation, we can strongly question the consistency displayed by the authors to link traditional earth constructions to the modern use of soil as a building material. Indeed, this former is mostly constituted by structures made of unstabilised earth, even for areas subject to heavy rains (Northern Europe). As a consequence, while it is true that in some countries, the temptation to accelerate the strengthening of the material by the addition of hydraulic binders can be justified for industrial production rates [START_REF] Ciancio | Experimental investigation on the compressive strength of cored and molded cement-stabilized rammed earth samples[END_REF] or for maintenance purposes [START_REF] Millogo | Microstructural characterization and mechanical properties of cement stabilised adobes[END_REF][START_REF] Reddy | Cement stabilised rammed earth. Part B: Compressive strength and stress-strain characteristics[END_REF][START_REF] Reddy | Structural behavior of story-high cementstabilized rammed-earth walls under compression[END_REF], an understanding review should not overshadow the research that is ongoing on un-stabilised earth constructions. An illustration of the significant importance of taking into consideration both stabilised and unstabilised materials is given in Germany, which is regularly used as a reference by the authors in their review. Indeed, after updating their professional rules, the Dachverband Lehm wrote a draft standard on earth-based bricks considering only un-stabilised bricks (except plant fibres that can be considered as a stabiliser in some cases). Based on this premise that un-stabilised earth constructions were only useful in the past, the majority of this review loses its relevance and contradicts the title that suggests that we can build the future using knowledge from the past. This contradiction becomes particularly annoying during the discussions on economic and environmental impacts. The unstabilised earth is solely able to be returned to its initial state (as a soil) without any "waste" of energy, by simply wetting. Moreover, it is possible to reuse the material with the same embodied energy to build again. This is the only material with drystone masonry to be able to do that. Using cement or lime stabilisation increases the embodied energy of the material. The authors are not at all against the stabilisation, particularly if it is done with the real three dimensions of sustainable building, when for example it enables to use local materials and develop local skills and employment but they are just aware that using earth is not sufficient to be sustainable.

Material properties

The presentation of the material properties of the soil used for earth construction is interesting but definitely lacks a discussion on the compressive strength. This feature has been extensively studied by various researchers since the 1980s, see for examples . Indeed, this characteristic is currently a feature required by all parties involved in construction as a proof of durability. However, there is a paradox between this parameter and the observation of existing earth constructions that have long shown sufficient durability. Thus, despite years of research, there is still no consensus on how to measure this characteristic [START_REF] Morel | Compressive strength testing of compressed earth blocks[END_REF]. As an example, similarly to what it is observed for other building materials, such as concrete, Anglo-Saxon culture advocates the measurement of the "confined" resistance, whereas in French culture, we continue to be attached to the "unconfined" measurements. Many discussions about the extent and relevance of this feature continue to animate the scientific debate within the community working on this subject. Moreover, as is rightly stated by the authors, the compressive strength will depend on the sample shape (and this is where the main problem with the compression test lies). However, to echo the previous discussion, it is important to underline here that the stabilisation will also significantly affect the fracture behaviour of the test sample. Actually, stabilisation created by rigidifying the material will induce a commonly observed behaviour in brittle materials as concrete or stone. In contrast, theun-stabilised material is likely to be closer to conventional behaviour of soils. In this case, the soil behaviour elastoplastic models are a priori better suited to earthen materials [START_REF] Nowamooz | Finite element modelling of a rammed earth wall[END_REF][START_REF] Jaquin | The strength of unstabilised rammed earth materials[END_REF].

Thus, any comparison between the compressive strengths of stabilised and unstabilised earth samples should be made with care.

Hygrothermal properties

Finally, a similar discussion can be undertaken on the hygrothermal properties of earthen materials and their impact on comfort and indoor air quality. One of the main assets that is used to promote earth constructions is their role in controlling moisture and indoor air quality. To our knowledge, there are also few studies that demonstrate what the influence of stabilisation on the hygroscopic behaviour might be. It is well known since [START_REF] Olivier | Le matériau terre: Essai de compactage statique pour la fabrication de briques de terres compressées[END_REF] that, for materials of the same soils manufactured at the optimum water content, stabilisation increases the volume fraction porosity of the material. The consequence is that the sorptivity of the cement stabilised samples is higher than the unstabilised sample [START_REF] Hall | Moisture Ingress in Rammed Earth: Part 3 -The Sorptivity and the Surface Inflow Velocity[END_REF]. But recent studies in the moisture buffering in buildings, clearly stated that the vapour transfer were reduced by the stabilisation with lime or cement [START_REF] Mcgregor | The effect of stabilisation on humidity buffering of earth walls[END_REF][START_REF] Eckermann | Auswirkung von Lehmbaustoffen auf die Raumluftfeuchte[END_REF]. However, the prediction of this phenomenon through the integration of the measured physical properties of moisture and the heat transfer coupled models is extremely rare [START_REF] Allinson | Hygrothermal analysis of a stabilised rammed earth test building in the UK[END_REF][START_REF] Hall | Chapter 2: Hygrothermal behaviour and thermal comfort in modern earth buildings[END_REF][START_REF] Hall | Analysis of the Hygrothermal Functional Properties of Stabilised Rammed Earth Materials[END_REF] and should also be completed in further studies.

Conclusions

We believe that it is necessary to continue discussions among scientists on the use of this material in modern "green buildings". Moreover, it is quite relevant, as suggested by Pacheco-Torgal and Jalali, to study existing earth constructionsfor, at least, the transmission of cultural know-how. However, the existence of these structures is, by itself, evidence of the durability of these types of constructions, which have remained intact for decades. It will be necessary to increase our knowledge of this material to renovate it properly (including from the energy point of view, for example, in the countries of Northern Europe). Finally, the question remains open on stabilisation. While it is entirely appropriate for some applications (low-cost buildings in India subjected to the monsoon to avoid having to rebuild every year for example), its routine use in industrialised countries can be questioned. Some local soils are known to exhibit sufficient mechanical characteristics without amendment.


CONTACT :

EXTRACTION BY SPARK GENERATED SHOCKWAVES Contact: Jean-Maxime Roux | jean-maxime.roux@cea.fr Authors : H. Lamotte 1 , J-M. Roux 1 , J. Lupette 2 , E. Marechal 2 , J-L. Achard 3 1 CEA LETI MINATEC Campus, Univ. Grenoble Alpes, F-38054 Grenoble, France 2 Laboratoire Physiologie Cellulaire & Végétale (CEA, CNRS, INRA, Univ. Grenoble Alpes), Grenoble, France 3 Laboratoire des Écoulements Géophysiques et Industriels (GrenobleINP, Univ. Grenoble Alpes, CNRS), Grenoble, France

The production of lipids using oleaginous microorganisms is widely studied to develop the next generation of renewable fuels. Now, the extraction of intracellular lipids has been identified as one of the crucial elements that have the largest impact on the cost of microalgal biorefinery process. In this context, a new electric field based technique is studied to disrupt cell membranes and to extract their content. High voltage electrical pulses are used without any transducer to create underwater spark discharges that produce a high-pressure plasma/vapor bubble whose expansion, collapse and rebounds generate shockwaves. The high induced variations of pressure produce a cloud cavitation above the electrode; bubbles collapses are known to destroy mechanically cells membranes. Moreover, the pressure rise induced by the process can be used to renew the solution containing destroyed cells at each pulse.

Underwater spark discharges can extract chlorophyll and lipids from Phaeodactylum tricornutum and Nannochloropsis gaditana and also DNA from bacteria such as Bacillus subtilis. The present communication presents results of a parametric study of the process. It is shown that efficiencies depends on the microorganisms' concentration and the water height above the electrodes. Perspective : recover the same amount as chlorophyll

Cloud cavitation

The pressure rise and the bubble growth can expel water from the treatment unit. Picture of the cavitation bubbles taken 150 µs after the electric discharge.

Shockwaves induce pressure changes that lead to the formation of cloud cavitation.

Phaeodactylum tricornutum

% extraction % extraction

Underwater discharges produce heat and free radicals that combine to create very reactive molecules such a hydrogen peroxyde. But Phaeodactylum tricornutum does not release pigments when heated up to 90°C. Also 1 mM of hydrogen peroxyde does not seem to make the algae release pigment. Release of intracellular molecules seem to be therefore due to the mechanical effect of cloud cavitation.

• About 25-35% of chlorophyll are released by 200 electric pulses • A water height of about 13,5mm above the electrodes seems to be optimal • Dilution seems to improve the treatment efficiency

Phaeodactylum tricornutum

% extraction

Following

  Extraction of about 6%


Oleksandr Zinenko

Stéphane Huot

Cédric Bastoul

Keywords: CCS Concepts:, Human-centered computing → Human computer interaction (HCI), •So ware and its engineering → Compilers, Polyhedral model, direct manipulation ACM Reference format:

Parallelism is one of the key performance sources in modern computer systems. When heuristics-based automatic parallelization fails to improve performance, a cumbersome and error-prone manual transformation is o en required. As a solution, we propose an interactive visual approach building on the polyhedral model that visualizes exact dependences and parallelism; decomposes and replays a complex automatically-computed transformation step by step; and allows for directly manipulating the visual representation as a means of transforming the program with immediate feedback. User studies suggest that our visualization is understood by experts and non-experts alike, and that it may favor an exploratory approach.

Visual Program Manipulation in the Polyhedral Model

OLEKSANDR ZINENKO, Inria and University Paris-Saclay ST ÉPHANE HUOT, Inria C ÉDRIC BASTOUL, University of Strasbourg and Inria

INTRODUCTION

Large-scale adoption of heterogeneous parallel architectures requires e cient solutions to exploit the available parallelism from applications. Despite signi cant e ort in simplifying parallel programming through new languages, high-level language extensions, frameworks and libraries, manual parallelization may still be required although o en ruled out as time consuming and errorprone. us, programmers mostly rely on automatic optimization tools, such as those based on the polyhedral model, to improve program performance. e polyhedral model [START_REF] Feautrier | Polyhedron Model[END_REF] has been the cornerstone of loop-level program transformation in the last two decades [START_REF] Bastoul | Code Generation in the Polyhedral Model Is Easier an You ink[END_REF][START_REF] Bondhugula | e Pluto+ Algorithm: A Practical Approach for Parallelization and Locality Optimization of A ne Loop Nests[END_REF][START_REF] Feautrier | Some E cient Solutions to the A ne Scheduling Problem. Part II. Multidimensional Time[END_REF]. It features exact iteration-wise dependence analysis and optimization for both parallelism and locality. However, automatic polyhedral compilation is based on imprecise heuristics [START_REF] Bondhugula | e Pluto+ Algorithm: A Practical Approach for Parallelization and Locality Optimization of A ne Loop Nests[END_REF][START_REF] Bondhugula | A Practical Automatic Polyhedral Parallelizer and Locality Optimizer[END_REF]. Polyhedral compilers give user some (limited) control over the optimization process, which requires understanding their internal operation anyway. Furthermore, they are applicable globally and do not allow for nergrain control, e.g., a ecting only one loop nest. Visual interfaces for con guring the polyhedral compiler [START_REF] Papenhausen | PUMA-V: An Interactive Visual Tool for Code Optimization and Parallelization Based on the Polyhedral Model[END_REF] partially mitigate these issues by making polyhedral compiler blocks discoverable, but still require a deep understanding of internal operation of a compiler.

Semi-automatic approaches provide the user with a set of prede ned program transformations, typically exposed as compiler directives [START_REF] Girbal | Semi-Automatic Composition of Loop Transformations for Deep Parallelism and Memory Hierarchies[END_REF][START_REF] Kelly | A Unifying Framework for Iteration Reordering Transformations[END_REF][START_REF] Yuki | Alphaz: A System for Design Space Exploration in the Polyhedral Model[END_REF]. ey shi the expertise requirements from heuristics to loop-level code transformations.

ey also require program transformation to be performed from scratch (as polyhedrally-transformed code is barely readable) while o ering li le for (i = 0; i < N ; i ++) for (j = 0; j < N ; j ++) S :

z[i+j] += x[i ] * y [ j ];

(a) Original #pragma omp parallel for private ( t2 ) for ( t1 = 0; t1 <= 2* N -2; t1 ++) for ( t2 = max (0 , t1 -N +1); t2 <= min ( t1 , N -1); t2 ++) S :

z where arr corresponds to the name of accessed array and a 1 corresponds to its only dimension.

Program Transformation and Schedules.

Changing the relative execution order of statement instances transforms the program. We can de ne a scheduling relation to map iteration domain points to logical execution dates. If these dates are multidimensional, statement instances are executed following the lexicographical order of their dates. Scheduling relations are expressive enough to encode a complex composition of program transformations including, e.g., loop interchange, fusion, ssion, skewing, tiling, index-set-spli ing, etc. [START_REF] Girbal | Semi-Automatic Composition of Loop Transformations for Deep Parallelism and Memory Hierarchies[END_REF].

For example, loop tiling [START_REF] Irigoin | Supernode Partitioning[END_REF] for the polynomial multiply can be expressed by the schedule θ S (N ) = {(i, j) T → (t 1 , t 2 , t 3 , t 4 ) T | (32t

1 ≤ t 3 ≤ 32t 1 +31) ∧ (32t 2 ≤ t 4 ≤ 32t 2 +31) ∧ t 3 = i ∧ t 4 = j},
where 32 is the tile size. Note that t 3 and t 4 are de ned explicitly by equalities while t 1 and t 2 are de ned implicitly by bounding inequalities, which correspond to integer division.

Schedule relations can be constructed manually or using high-level frameworks [START_REF] Bagnères | Opening Polyhedral Compiler's Black Box[END_REF][START_REF] Girbal | Semi-Automatic Composition of Loop Transformations for Deep Parallelism and Memory Hierarchies[END_REF][START_REF] Kelly | A Unifying Framework for Iteration Reordering Transformations[END_REF]. Automatic optimizers directly construct a scheduling relation with certain properties, including minimal reuse distances, tilability and inner/outer parallelism [START_REF] Bondhugula | e Pluto+ Algorithm: A Practical Approach for Parallelization and Locality Optimization of A ne Loop Nests[END_REF][START_REF] Bondhugula | Automatic Transformations for Communication-Minimized Parallelization and Locality Optimization in the Polyhedral Model[END_REF]. However, they may fail to improve performance when achieving di erent properties requires contradictory transformations, for example exploiting spatial locality may be detrimental for parallelism [START_REF] Shirako | Oil and Water Can Mix: An Integration of Polyhedral and AST-Based Transformations[END_REF].

2.1.3 Encoding Lexical Order. roughout this paper, we use the so called (2d + 1) structure of scheduling relations. It introduces (d + 1) auxiliary dimensions to the scheduling relation [START_REF] Kelly | A Unifying Framework for Iteration Reordering Transformations[END_REF] to represent lexical order. ey are referred to as β-dimensions [START_REF] Girbal | Semi-Automatic Composition of Loop Transformations for Deep Parallelism and Memory Hierarchies[END_REF], as opposed to α dimensions that represent the execution order of the d loops. Zero-based contiguous constant values of β i enforce the relative order between di erent objects (loops or statements) at depth i. ey express code motion transformations such as loop fusion and ssion. For example, the (2d + 1) form of the identity scheduling relation for polynomial multiply is

θ S (N ) = {(i, j) T → (β 1 , α 1 , β 2 , α 2 , β 3 ) T | β 1 = 0 ∧ α 1 = i ∧ β 2 = 0 ∧ α 2 = j ∧ β 3 = 0}.
Given that β-dimensions are constant, they can be concisely rewri en as a vector ì β = (0, 0, 0) T . β-vectors uniquely identify statements since no two statements can have the same lexical position. Pre xes of β-vectors (β-pre xes) uniquely identify loops, with their length corresponding to the nesting depth. Statements that share d loops, have identical β-pre xes of length d.

2.1.4

Program Analysis and Parallelism. ey key power of the polyhedral model is its ability to compute exact instance-wise dependences [START_REF] Feautrier | Data ow Analysis of Array and Scalar References[END_REF]. Two statement instances are dependent if they access the same array element and at least one of them writes to it. For a program transformation to preserve original program semantics, it is su cient that pairs of dependent instances are executed in the same order as before the transformation [START_REF] Kennedy | Optimizing Compilers for Modern Architectures: A Dependence-Based Approach[END_REF]. A dependence relation maps statement instances (dependence sources) to the instances that must be executed a er them (dependence sinks). If a transformation inverses the execution order of dependent instances or assigns them the same logical execution time, the dependence becomes violated and the transformation is illegal. e polyhedral model provides means to verify the legality of a scheduling relation [START_REF] Bastoul | Mapping Deviation: A Technique to Adapt or to Guard Loop Transformation Intuitions for Legality[END_REF][START_REF] Feautrier | Data ow Analysis of Array and Scalar References[END_REF][START_REF] Pugh | e Omega Test: A Fast and Practical Integer Programming Algorithm for Dependence Analysis[END_REF][START_REF] Vasilache | Violated Dependence Analysis[END_REF].

Groups of instances, including loops, that do not transitively depend on each other may be executed in an arbitrary order, including in parallel. Loop-level parallelism is expressed by a aching a "parallel" mark to an α dimension, which requires code generator to issue a parallel loop.

Code Generation.

A er a scheduling relation is de ned, code generation is a ma er of building a program that scans the iteration domain with respect to the schedule [START_REF] Ancourt | Scanning Polyhedra with DO Loops[END_REF]. Modern code generators rely on generalized change of basis that combines the iteration domain and the scheduling relation and puts scheduling dimensions in the foremost positions before creating loops from all dimensions. Several e cient algorithms and tools exist for that purpose including CLooG [START_REF] Bastoul | Code Generation in the Polyhedral Model Is Easier an You ink[END_REF], CodeGen+ [START_REF] Chen | Polyhedra Scanning Revisited[END_REF] and ppcg [START_REF] Grosser | Polyhedral AST Generation Is More an Scanning Polyhedra[END_REF]. For example, given the schedule T S = {(i, j) T → (t1, t2) T | t1 = i + j ∧ t2 = j} that implements loop skewing for the polynomial multiply kernel and a parallel mark for dimension t1, CLooG may generate the code in Fig. 1b.

Transformation Directives

Even though polyhedral and syntactic approaches can be combined in an automatic tool [START_REF] Shirako | Oil and Water Can Mix: An Integration of Polyhedral and AST-Based Transformations[END_REF], the polyhedral optimizer does not operate in syntactic terms and provides only li le control over its parameters through compiler ags. Recently, Bagnères et.al. proposed the Clay transformation set that expresses a large number of syntactic loop transformations as structured changes to scheduling relations and rely on β-pre xes to identify targets [START_REF] Bagnères | Opening Polyhedral Compiler's Black Box[END_REF]. ey also proposed the Chlore algorithm that identi es a sequence of Clay primitives that would transform any given scheduling relation into another scheduling relation.

For example, the aforementioned loop skewing transformation is expressed as a dimension substitution: S ( ì ρ, i, k):

∀θ S : ì β S,1.. dim ì ρ = ì ρ, α dim ì ρ → α dim ì ρ + k • α i . Any occurrence of the output dimension α dim ì
ρ is replaced by a linear combination of itself with another output dimension α i . us, the schedule T S from the previous section is obtained from the identity schedule by S ((β 1 ) T = (0) T , i = 2, k = 1) where β 1 identi es the outer i loop. Loop R is similar to S except that it uses a linear combination of the input rather than output dimensions. Transformations of the lexical order are encoded as modi cations of β-vectors. For example, fusing two subsequent loops is expressed as F N ( ì ρ):

∀θ S : ì β S,1.. dim ì ρ-1 = ì ρ 1.. dim ì ρ-1 ∧ ì β S,dim ì ρ = ì ρ dim ì ρ + 1, ì β S,1.. dim ì ρ-1 ← ì ρ S,1.. dim ì ρ , ì β S,dim ì ρ ← ì β S,dim ì ρ + max T : ì β T = ì ρ ì β T ,dim ì ρ
, where dim ρ encodes fusion depth. is transformations assigns equal β values up to given depth, which corresponds to fusion, and updates the remaining ones to maintain uniqueness and contiguity.

Clay transformations are applicable to unions of scheduling relations such that the entire union (but not necessarily individual relations) is le -total and injective. Internally, Clay operates on a matrix representation of systems of linear inequalities and supports arbitrarily complex transformations as long as the properties of an union are preserved. Chlore algorithm builds on matrix decompositions to identify sequences of Clay primitives that transform one set of matrices into another set. More information and full speci cation of transformations is available in [START_REF] Bagnères | Opening Polyhedral Compiler's Black Box[END_REF].

Although Clay and Chlore enable interaction with a polyhedral engine using syntactic terms, they face several challenges in application. (1) Target selection-β-pre xes are required for each transformation, yet they are not easily accessible in the source code. (2) Target consistency-the generated code may have a di erent structure than the original code, for example due to loop separation [START_REF] Bastoul | Code Generation in the Polyhedral Model Is Easier an You ink[END_REF], resulting in a mismatch between β-vectors and loop nesting. (3) E ect separationeven if Chlore produces a sequence of primitive transformations, it is di cult to evaluate (potentially negative) e ects of individual transformation by reading the polyhedrally transformed code.

We address these challenges with Clint, a new interactive tool based on a graphical representation of SCoPs which: simpli es target selection to directly choosing a visualization of a transformation target; maintains target consistency by matching the visualization to the original (o en simpler) code; and replays primitive "steps" of transformation to separate their e ects, supporting further interactive modi cation.

DIRECTLY MANIPULATING POLYHEDRAL VISUALIZATIONS

To reduce the burden of code editing and transformation primitive application, we propose Clint, an interactive loop-level transformation assistant based on the polyhedral model. It leverages the geometric nature of the model by presenting SCoPs in a directly manipulable [START_REF] Shneiderman | Direct Manipulation: A Step Beyond Programming Languages[END_REF] visualization that combines sca er plots of iteration domains and node-link diagrams of instance-wise dependences.

is approach is similar to the one commonly used in the polyhedral compilation community to illustrate iteration domains. Clint goes beyond these static views by allowing program transformation to be initiated directly from the visualization, and provides an animation-based visual explanation of an automatically computed program transformation. Animated transitions correspond to program transformations that, when applied, would change the program to obtain the nal visualization. e user can replicate the action by directly manipulating the visualization similarly to the transition or in a more elaborate way. e set of interactive manipulations builds on the geometry-related vocabulary of classical loop transformations, such as skewing or shi ing, which is expected to give the user supplementary intuition on the transformation e ects and to support exploration and learning.

e design of Clint is motivated by the need for (1) a single and consistent visual interface to bridge the gap between dependence analysis and subsequent program transformation; (2) an e cient way to explore multiple alternative loop transformations without rewriting the code; (3) explaining the code modi cations yielded by an automatic optimization. Although built around the complete Clay transformation set [START_REF] Bagnères | Opening Polyhedral Compiler's Black Box[END_REF], it can be extended to support di erent transformations as long as e ects of any transformation can be undone by (a sequence of) other transformations. Clint seamlessly combines loop transformations to support reasoning about execution order and dependences rather than loop bounds and branch conditions. e interactive visual approach reduces parallelism extraction to visual pa ern recognition [START_REF] Ware | Information Visualization: Perception for Design[END_REF] and code transformation to geometrical manipulations, giving even non-expert programmers a way to manage the complexity of the underlying model [START_REF] Norman | Living with Complexity[END_REF]. Finally, it brings insight into the code-level e ects of the polyhedral optimization by decomposing a complex program transformation into primitive steps and providing a step-by-step visual replay, independent of how an automatic optimizer operates internally.

Structure of the Visualization

Clint visualizes scheduled iteration domains, e.g., statement instances mapped by the scheduling relation to the new coordinates in logical time space, see Fig. 2, for an example of a simple code and its corresponding visualization. e main graphical elements are as follows.

Points and Polygons. Our visualization consists of polygons containing points on the integer la ice. Each point represents a statement instance, positioned using values of α dimensions. Points are linked together by arrows that depict instance-wise data ow between them. e polygon delimits the loop bounds in the iteration space and is computed as a convex hull of the points it includes. e space itself is displayed as a coordinate system where axes correspond to loop iteration variables.

Color Coding. Statements are color coded to ensure matching between code and visual representations. A transformation, such as peeling or index-set-spli ing, may result in sets of instances of the same statement being executed in di erent loop nests. We refer to this case as multiple occurrences of the statement. Di erent occurrences of the statement share the same color coding. for (i = 0; i < 2*N-1; ++i) for (j = max(0,i-N-1); j < min(i+1,N); ++j) z[i] += x[i-j] * y[j]; Coordinate Systems. Each coordinate system is at most two-dimensional. e horizontal axis represents the outer loop, and the vertical axis represents the inner loop. Statement occurrences enclosed in both loops are displayed in the same coordinate system, with optional slight displacement to discern them (see Fig. 4). Statement occurrences that share only the outer loop are placed into di erent coordinate systems, vertically aligned so that they visually share the horizontal axis. We refer to this structure as pile (see Fig. 8b). Finally, statement occurrences not sharing loops are displayed as a sequence of piles (see Fig. 8a), arranged to follow the lexical order.

We use β-vectors internally to arrange polygons and coordinate systems. Statements with identical β-pre xes of length d share a coordinate system if d is the depth of the inner loop, and a pile if d is the depth of the outer loop. Consequently, coordinate systems and piles are uniquely identi ed by a β-pre x.

Execution Order. Statement instances are executed bo om to top, then le to right, crossing the bounds of coordinate systems in both cases. Multiple instances sharing a loop iteration are executed in the order of increasing displacement. Arrows point at the instance executed second.

Tiling. Tiled domains are displayed as polygons with wide lines inside to delimit tile shapes. All dimensions that are implicitly de ned (see Section 2.1.2) are considered as tile loops and serve to build the tile shapes creating sca erplots with nested axes [START_REF] Rey Heer | A Tour rough the Visualization Zoo[END_REF]. Tiling makes execution order two-level: entire tiles are executed following the previously described order; instances inside each tile are executed bo om to top, then le to right without crossing tile boundaries.

Multiple Projections. e overall visualization is a set of two-dimensional projections, where loops that are not matched to the axes are ignored. As the goal of Clint is program transformation, we only display projections on the schedule α-dimensions, which coincide with iteration domain dimensions before transformation. For a single statement occurrence, they may be ordered in a sca erplot matrix as in Fig. 5a. e points are displayed with di erent intensity of shade depending on how many multidimensional instances were projected on this point. We motivate the choice of 2D projections vs 3D visualization by easier direct manipulation with a standard 2D input device (e.g., mouse) [START_REF] Beaudouin-Lafon | Designing Interaction, Not Interfaces[END_REF][START_REF] Cockburn | 3D or Not 3D?: Evaluating the E ect of the ird Dimension in a Document Management System[END_REF] and consistency of the visualization for even higher dimensionality.

Dependences and Parallelism. Dependences between points in the same coordinate system are shown as arrows pointing from source to sink. By default, only direct (i.e., non transitively-covered) dependences are shown. When hovering a point, all its dependences are visualized. Dependences between vertically or horizontally adjacent coordinate systems are aggregated into large dots (Fig. 7b). Finally, dependences between points in distant coordinate systems are only visualized when either their source or sink is being manipulated to avoid visual clu ering. Arrows and dots turn red if the dependence is violated. Transformation legality check is performed parametrically. If legality violation exists for values of parameters other than currently selected, the polygon contour turns red instead of arrows.

Generally, parallel dependence arrows imply some parallelism is present in the loops -e.g., if they are orthogonal to an axis, the loop corresponding to an axis features D A parallelism. Clint highlights "parallel" axes in green to simplify parallelism identi cation (see Fig. 2).

Parametric Domains. Domains whose bounds involve parametric expressions are visualized for a xed value of the parameters. By default, all parameters are assigned identical values computed as follows. Clint computes the dependence distance sets from dependence relations by subtracting the relation's range from its domain. It then takes the maximum non-parametric absolute value across all dimensions. Finally, it takes a minimum of this value and a prede ned constant. We selected this constant as 6 from our preliminary studies, observing that it is su cient to represent the majority of dependence pa erns in our test suite. e user can dynamically modify values of individual parameters and the visualization will be automatically updated.

Directly Manipulable Visual Objects

Since program transformations in the polyhedral model correspond to changes of the statement instance order, they can be performed on the visual representation of that order. In Clint, the execution dates are mapped to point positions. erefore, moving points corresponds to program transformations. Visual marks such as points and polygons a ord direct manipulation, i.e., they can be dragged and dropped directly to the desired position.

Because many of the visual elements are mapped from the underlying SCoP properties, manipulation should be structured so as to maintain those properties. For example, point coordinates should remain integer to properly map to counted for loops. Furthermore, the polyhedral model represents parametric iteration domains-having constant yet unknown sizes-making it technically impossible to schedule each instance separately. erefore, we only enable structured point manipulation that can be mapped to similarly structured program transformations as expressed in, e.g., Clay framework. Visually, we use polygons and coordinate systems as manipulation substrates [START_REF] Klokmose | Webstrates: Shareable Dynamic Media[END_REF] that mediate interaction with groups of points while ensuring structure preservation.

We refer to polygons and coordinate system as point containers. ey can be seen as persistent selection of the points manipulable together and sharing a common property: representing instances of the same statement or being enclosed in the same loops. Polygons and coordinate systems also allow to reify the conventional target selection and make it a rst-class interactive object [START_REF] Beaudouin-Lafon | Rei cation, Polymorphism and Reuse: ree Principles for Designing Visual Interfaces[END_REF]. e user no longer needs an explicit (and sometimes cumbersome) selection step, by either clicking or lassoing the objects with cursor, before starting the manipulation.

Mapping Interactions to Loop Transformations

As motivated above, we center the manipulation around polygons. We augment the polygon with handles at its corners and borders, similarly to a conventional graphical editor. ey appear when the polygon is hovered and support many transformations without using any instruments or modes.

We rely on structured scheduling relation modi cations of Clay framework, most of which were inspired by well-known "classical" loop transformations [START_REF] Joseph | High Performance Compilers for Parallel Computing[END_REF]. Some of them map directly to Clint visualization (e.g., S

), while others do not (e.g., I ) or, even worse, can be mapped in a misleading way (S ). erefore, instead of trying to map Clay transformations, we rather follow an interaction-centered approach by mapping the possible graphical actions to sequences of Clay transformations. Fig. 3 lists the graphical actions and the corresponding program transformations. e action parameters correspond to the a ributes of the object being manipulated or properties of the manipulation.

Drag polygon between CS ì β, x, , ì ρ 1. R (β 1.. , put last), β ← max S β S -1 2. D (β 1.. ), β -1.. = (β -1 + 1, 0) T 3. repeat 1,2 until dimension x 4. R (β 1..x , put a er ρ x ), β x ← ρ x + 1 5. F N (β 1..x ), β x ..x +1 ← (β x -1, max S β S x +1 +1) 6. repeat 4,5 until dimension 7. R (β 1.. put last) Drag corners from center ì β, x, , dx, d , sx, s 1. R ( ì β, , x, dx/s ) 2. R ( ì β, x, , d /sx ) use skew when possible Drag corners towards center ì β, x, dx, sx ( axis used if d > dx) 1. I ( ì β, x, ) if dx/sx mod 2 = 1 2. R (β 1..x ) if 1 ≤ dx/sx mod 4 ≤ 2 3. R (β 1.. ) if dx/sx mod 4 ≥ 2 Drag border x, dx, sx 1. D ( ì β) 2. R ( ì β) if dx < 0 3. G ( ì β, dx/sx ) Click on rect- angular selec- tion of points ì β, x, , tx, t 1. I (β 1.. +2 , , +1) if implicitly de ned 2. L (β 1.. +1 ) if + 1 implicitly de ned 3. L (β 1..x ) if x implicitly de ned 4. S M (β 1..x , tx) 5. S M (β 1.. +1 , t ) 6. I (β 1.. 2 , , + 1)
Select points and move

ì β, ì ρ, selection shape { f i (x, ) ≥ 0} 1. ∀i, I S S ( ì β, f i ) if ì ρ = ∅ C ( ì ρ) otherwise.
Fig. 3. Mapping between interactive polygon manipulations and Clay transformations. ì β identifies the statement occurrence corresponding to the polygon; ì ρ identifies the β-prefix of the coordinate system; x and are loop depths corresponding to the horizontal and vertical axes, respectively; dx and d are cursor o sets from its position when the manipulation started; sx and s are sizes of the polygon; tx and t are sizes of the selection. O sets and sizes are expressed in coordinate system units, i.e., iterations.

For example, dragging a polygon along one of the axes directly corresponds to the S transformation. However, dragging it to a di erent coordinate system corresponds to a complex sequence of Clay directives that perform code motion (see "Drag polygon between CS" in Fig. 3). Transformations that result in an identical schedule are omi ed, for example, no R is applied before D if the statement occurrence is already the last in the loop.

Polymorphic Actions. e coordinate system can be automatically extended to t the polygon being dragged. We leverage the equivalence property of transformation to stop automatic extension.

Shi ing past the largest bound does not change the relative execution order. In such cases, the polygon goes outside the coordinate system, which is shrunk to t only the remaining polygons.

Parametric Transformations. Transforming a parametrically-bounded domain may result in parametric transformations. In particular, we look for a parametric bound closest to the mouse cursor at the end of manipulation. For example, the amount of S is computed with respect to the closest bound of the polygon other than the one being shi ed. Alternatively, the conditions for I S S are ( rst) computed as a ne expressions of the closest bound. If there is no such expression, they are computed without using parameters.

Skew and Reshape. By default, the graphical action of skewing corresponds to the R transformation, and not the S transformation. e la er transforms the loop with respect to the current expression for the other loop rather than to the original iterator. is makes S transformation combine badly: if the x loop is skewed by to become (x + ), it becomes impossible to skew by x as it does not appear independently of anymore. e graphical intuition behind loop skewing does not hold for combinations of skews. However, when a R is identical to S , Clint will perform a S since it is one of the well-known classical transformations 1 .

Targeting Individual Statements. Many Clay transformations operate on β-pre xes, that is loops rather than statements. We circumvent this by distributing away the target statement, applying the desired transformation to a loop nest with only this statement, and then fusing everything back.

Manipulating Multiple Statements. If multiple polygons are selected within a coordinate system, transformations are applied to all of them in inverse lexicographical order of their respective β-vectors. Inversion prevents transformations from modifying β-vectors used to target subsequent transformations. If a user manipulates a pile (or a coordinate system), the action is propagated to all the polygons it contains, making the pile an implicit selector for the polygons it contains.

Manipulating Groups of Points. Individual points or groups thereof can be manipulated by turning them into a polygon rst. Selecting a group of points and dragging it away from existing polygon separates it into two parts, mapping to the I S S transformation. It creates a new statement occurrence that can be manipulated separately. Dropping this polygon on top of another polygon that represents a di erent occurrence of the same statement is mapped to the C transformation. In cases of selections that are not adjacent to borders and/or not convex, multiple I S S transformations are performed. Each of the two resulting parts may correspond to multiple occurrences of the statement, but is visualized and manipulated as a whole.

Cross-Projection Selections. When multiple projections are used, the selection of statement instance points is combined from di erent projections. e overall multidimensional selection is an intersection of constraints imposed by each separate two-dimensional selection. Empty selection in a projection is thus equivalent to selecting everything.

Decoupling Visualization from Code. In Clint, we keep the visualization consistent with the original program structure unless the user manually modi es the code. is allows for manipulating multiple statement occurrences together, for example in case of shi ing one statement with respect to another inside the loop, which may result in loop separation as in Fig. 4. Fig. 4. Manipulation for Transformation: the darker polygon is dragged right so that dependence arrows become vertical without spanning between di erent iterations on i. The visualization is then decoupled from the code structure, and both statements can still be manipulated as if they were not split between two loops.

Transformation Legality Feed-Forward. Clint graphical interactions are structured so that it is possible to identify the transformation before it is completed. For example, dragging a corner of a polygon away from its center corresponds to a R , the dragging direction and distance de ne transformation parameters. Since they are typically expressed in units of iteration steps through division, we can use ceil instead of normal rounding to obtain the parameters earlier.

Hence Clint can perform a transformation before the end of corresponding user interaction. is allows to provide feed-forward about the transformation, i.e., its e ects (in particular dependence violation) are visualized during the interaction, guiding the user in their choice. In addition, this approach allows Clint to hint the user about the state of the visualization if they nish manipulation immediately using a grayed-out preview shape (see Fig. 8).

Mapping Loop Transformations to Animated Transitions

Clint visualization enables the illustration of step-by-step execution of a Clay transformation script, either constructed manually or translated from a compiler-computed schedule using Chlore [START_REF] Bagnères | Opening Polyhedral Compiler's Black Box[END_REF]. Instead of providing a one-to-one mapping between individual transformations and animated transitions, we take a generalized approach based on the structure of transformations. ey can be divided based on the scheduling relation dimensions they a ect: (1) only α, (2) only β or (3) both α and β. e rst group contains all transformations except F N , D and R , which belong to the second group, and S M , L , I S S and C , which belong to the third group. is classi cation allows us to limit the animation scope. Transformations that do not modify β-dimensions may only a ect points inside one container while points cannot be moved between containers. Furthermore, only the projections on iterators involved in the transformation should be updated. Transformations that only modify β-dimensions a ect entire containers without modifying the point positioning inside them.

Within-Container Transformations. Transformations of the rst group are animated by simultaneously moving individual points to their new positions. During the transition, polygonal shapes are updated to match the convex hull of the respective points. us S transformation moves all points simultaneously in one direction and corresponds to visual displacement, while R transformation moves rows (or columns) of points at di erent lengths and results in shape skewing.

Multiple Projections. Several transformations operate on two dimensions, for example R and I

. For these cases, we consider the projection on both of these dimensions as the main one, and the projections on one of the dimensions as auxiliary ones. In the main projection, the one-to-one point transition remains applicable. On the other hand, in the auxiliary ones, points may be created or deleted. For example, an auxiliary projection retains the rectangular shape a er a R but becomes larger as some points are projected onto new coordinates (see Fig. 5). Clint handles this by introducing a temporary third axis, orthogonal to the screen plane.

is axis corresponds to the dimension present in the transformation, but not in the projection. Points and arrows are then re-projected on three dimensions. Extra objects become visible only during the animated transition and create a pseudo-3D e ect. A er the transition, the third axis is deleted while the projected points remain in place (see Fig. 5b). is technique is analogous to Sca erDice [START_REF] Elmqvist | Rolling the Dice: Multidimensional Visual Exploration Using Sca erplot Matrix Navigation[END_REF], but without axis switching.

Between-Container Transformations. As transformations of the second group a ect entire polygons only, we can translate them into motion of polygons. If all polygons of a container are moved, the entire container is moved instead. Target containers are identi ed using β-pre xes.

Container Creation and Deletion. Transformations of the third group may result in containers being created or deleted. However, without points, a polygon would correspond to statement occurrence that has no instances and thus is never executed. erefore, it must be impossible to create empty containers. e only way to create a container in Clint is by spli ing an existing container into multiple parts. is exactly corresponds to the I S S transformation if the container is a polygon. It also maps to the D transformation when the container is a coordinate system or a pile. Conversely, C and F N transformations correspond to visually joining two containers.

Clint Interface

Clint combines three editable and synchronized representations (see Fig. 5a): (1) the interactive visualization; (2) a navigable and editable transformation history view based on Clay scripts; and (3) the source code editor. A consistent color scheme is used between the views to match code statements to the visualization. Transformation directives corresponding to graphical actions are immediately appended to the history view. e user can then navigate through the history by selecting an entry, which will update the visualization to the corresponding previous state, or edit it directly using Clay syntax. As the target code tends to become complex and unreadable a er several manipulations, the user has the option to keep the original code visible instead of the transformed one. Finally, when the code is edited, the visualization is updated, thus making Clint a dynamic visualizer for polyhedral code.

USE SCENARIOS

Clint can be used as a stand-alone program transformation tool or in conjunction with an automatic optimizer. In the rst case, the user must decide on the transformation to perform. In the second case, Clint proposes a sequence of primitive transformations equivalent to the automatically computed one, le ing the user complement or modify it independently from the optimizer. In both cases, the user may reason in terms of an instance-wise dependence graph rather than in terms of loop transformations or parameters of the optimization algorithm.

Our approach does not impose a particular transformation heuristic. Instead, we suggest to build intuition by visualizing (optimized) programs that perform well and identifying visual pa erns. For an optimization expert, these pa erns may eventually lead to a novel heuristic. We provide two end-to-end illustrative examples, in which we a empt to make dependence arrows short to improve reuse and orthogonal to axes to exploit parallelism.

Assisted Semi-Automatic Transformation

Clint can be used as a tool for applying loop-level transformations that provides instant legality feedback and generates transformed code automatically. Let us continue with the polynomial multiplication kernel example, see Fig. 1a, to demonstrate how a long sequence of transformations can be applied. Default representation of the kernel, with parameters set to 4, is shown in Fig. 6a. e loop j features parallelism and is marked accordingly. Inner parallelism is o en less desirable as it would incur barrier synchronization cost on every iteration of the outer loops. erefore, observing that dependence arrows are diagonal, the user may decide to make them orthogonal to the i loop to make it parallel. ey can do so by dragging the top right handle of the polygon right, Fig. 6a. However, such transformation is illegal as indicated by the red arrows that point in the direction opposite to the j access. is dependence violation can be removed by switching the direction of arrows, which is achieved by dragging the top right handle le to rotate the polygon around its center, Fig. 6b.

e combined transformation sequence is now legal yet potentially ine cient: di erent iterations of parallel loop i execute di erent numbers of statement instances. Observing the symmetry of the polygon, the user selects a triangular-shaped group of points on the right, Fig. 6c, and drags it to the empty space on the le , Fig. 6d, until the balanced, rectangular shape is reconstructed, Fig. 6e. e nal transformation corresponds to loop skewing, followed by two loop reversals and shi s, then by index-set spli ing, and nally by shi ing. However, at no time during transformation, the user must be aware of particular loop transformations, their legality or the transformed code. ey can operate on an instantiation of the instance-wise dependence graph as opposed to directive-based approaches where, even with visualization, they would have to nd the transformation directive that would result in a desired visual shape.

Understanding, Improving and Rectifying Automatic Transformation

Manual program transformation, even with e cient support tools, may require su cient e ort from the programmer. Fully automated program optimizers are designed to yield decent performance in most cases. However, they are based on imprecise heuristics, which may fail to improve performance or even degrade it. Polyhedral optimizers are essentially source-to-source black boxes o ering li le control over the optimization process. Clint relies on Chlore [START_REF] Bagnères | Opening Polyhedral Compiler's Black Box[END_REF] to nd a sequence of primitive directives equivalent to the automatically computed optimization and let the user replay and modify it, independently of the optimization algorithm. e user does not have to know or understand the internal operation of the optimizer and its con guration.

Consider the Multi-Resolution Analysis Kernel code, available in doitgen benchmark of the PolyBench/C 4.2 suite [START_REF] Pouchet | PolyBench/C 4.2. Polyhedral Benchmark Suite[END_REF] and presented in Fig. 7a. A sequential version of this kernel runs in 0.83s on our test machine. 2 We applied Pluto3 polyhedral compiler [START_REF] Bondhugula | A Practical Automatic Polyhedral Parallelizer and Locality Optimizer[END_REF] to extract parallelism from this code. We also requested Pluto to tile the transformed code, which is likely to improve performance thanks to data locality and expose wavefront parallelism. A simpli ed version of the resulting code is presented in Fig. 7c. It indeed contains tiled and parallelized loops. Yet this code executes in 0.91s, a 10% slowdown compared to the sequential version (untiled parallel version executes in 50.1s, a 62× slowdown). Without any further suggestion from Pluto, the user may either stick with a non-transformed sequential version or with a non-e cient parallel one. e code was transformed so aggressively that the user is unlikely to a empt code modi cations or even understanding the transformation that was applied.

Comparing Clint visualizations before, Fig. 7b, and a er, Fig. 8a, transformation suggests loop ssion took place, which can also be inferred from the generated code. Step-by-step replay con rms this and also demonstrates loop tiling followed by skewing. It also shows that inner loops were parallelized, which is known to result in large barrier synchronization overheads. A fat dot between coordinate systems indicates there is some reuse between loops, but it is unclear whether Pluto performed ssion to ensure legality of skewing and tiling or because of its fusion heuristic. To discover that, the user may undo the ssion by fusing the loops back together, Fig. 8a. While they drag the polygon, legality feedforward appears in a shape of gray arrows that indicate that transformation would be legal and would preserve parallelism. Motivated by the success and observing the remaining reuse, the user may decide to fuse the remaining loop as well. is transformation would be illegal as indicated by red arrows appearing as the polygon is being dragged. e users can still nish the manipulation, and then use a conventional "undo" command.

Particular use cases of the previous section illustrate well the potential bene ts of the tool in speci c cases, but they do not help evaluating and understanding its overall usability in more general cases and with di erent users. erefore, as it is commonly done in Human-Computer Interaction, we conducted a series of user studies considering more abstract tasks that assess the usability of Clint.

Understanding the Visualization

Although similar visualizations have been already used for descriptive or pedagogical purposes, there is no empirical evidence of their appropriateness for conveying program structures. We designed an experiment to assess the suitability of our visual representation. In particular, we test whether both experts in the polyhedral model and non-expert programmers can establish a bidirectional mapping between Clint visualization and code. Participants. We recruited 16 participants (aged 18-53) from our organizations. All of them had experience in programming using imperative languages with C-like syntax and basic understanding of the polyhedral model and its limitations. Six participants reported to have manually constructed similar visualizations from scratch and were therefore considered Experts. Because participants were asked to construct visualizations following given rules, previous exposure to these rules is a more relevant criterion of expertise than familiarity with the polyhedral model.

Procedure. Our experiment is a [3 × 2] mixed design having two factors:

• T : mapping direction (between participants) -Visualization to Code (VC) -writing a code snippet corresponding to a given visualization using a C-like language featuring loops and branches with a ne conditions; -Code to Visualization (CV ) -drawing an iteration domain visualization given the corresponding code. • D : problems may be (within participants) -Simple -two-dimensional with constant bounds; -Medium -multi-dimensional with constant bounds; -Hard -two-dimensional with mutually-dependent bounds and branches.

We divided participants in two groups with equal number of experts. Group 1 performed the VC task, group 2 performed the CV task. is between participant factor allowed us to present the same problems to all participants while avoiding learning e ect. Both tasks were performed on paper with squared graph support for the CV task. Participants were instructed about visualization and performed two practice tasks before the session. ey were asked to work as accurately as possible without time limit and were allowed to withdraw from a task. Expected solutions were shown at the end of the experiment. Each session lasted about 20 minutes. Data Collection. For each trial, we measured Completion Time, Error and Abandon rates. e errors were split in two categories: Parameter Errors, when the shape of the resulting polyhedron was drawn correctly, but linear sizes or position were wrong; Shape Errors, when the shape of the polyhedron was incorrect. Codes describing the same iteration domain were considered equivalent (e.g., i <= 4 and i < 5). Upon completion, participants lled out a demographics questionnaire.

Data Processing and Analysis. We performed log-transformation of the Completion Time to compensate for the positive skew of its distribution, resulting in asymmetric con dence intervals. Due to concerns over the limits of null hypothesis signi cance testing in various research elds [START_REF] Cumming | e New Statistics Why and How[END_REF][START_REF] Dragicevic | Fair Statistical Communication in HCI[END_REF], our analyses are based on estimation [START_REF] Cumming | Inference by Eye: Con dence Intervals and How to Read Pictures of Data[END_REF]. We report symmetric e ect sizes on means -es = 2(m 1 -m 2 )/(m 1 + m 2 ) where m 1 , m 2 are means-and 95% con dence intervals (CIs).

Results

. We did not observe signi cant order e ect on the Error Rate or Completion Time, meaning that there were neither learning nor fatigue e ect along the experiment.

Completion Time. We discarded 7 trials in which participants produced erroneous code. T did not strongly a ect the Completion Time: VC took 182s (95%CI = [127s, 262s]) on average while CV took 215s (95%CI = [156s, 296s]) on average, resulting in an e ect size of 16.3% (95%CI = [-39.2, 50.9]). Despite Experts being familiar with similar representations, we observed no interaction between expertise and T . Experts performed 56.7% (95%CI = [26.8, 98.8]) faster than Non-Experts for Hard tasks. Both performed similarly on Easy and Medium tasks. In general, Completion Time is more consistent across Non-Expert participants than across Expert participants (Fig. 9a). ese results suggest that our representation is suitable for both Experts and Non-Experts if the complexity of the task remains limited. ey also con rm our assessment of task di culty.

Errors and Abandons. Participants performed the tasks with very low error rates, 8.3% (95%CI = [-3.6%, 20.3%]) for VC tasks and 4.2% (95%CI = [-4.5%, 12.8%]) for CV. Non-Experts proposed wrong code for Hard VC tasks, equally split between Parameter and Shape Errors. Experts made Parameter Errors for some Medium tasks. We observed only two withdrawals during a trial, both from nonexperts on a Hard task, one in VC and CV, and a er more than 500s (Fig. 9b). Overall, such low error rates make it di cult to conclude on the causes of the errors, but suggest that both experts and non-experts users can reliably map Clint visual representation to the code and vice versa.

Interactive Manipulation

A er assessing the visualization approach, we focused on interactive program transformation with Clint. We conducted a preliminary usability study with users already familiar with the visualization. In order to separate the e ect of direct manipulation from individual di erences in expertise, participants were not allowed to use any automatic parallelizing compiler that would help experts to achieve be er performance. We also decided not to use Clay syntax directly as it is li le-known and was designed as an intermediate representation for graphical manipulation. Noone a empted to use other diretive-based tools.

Protocol.

Participants. We recruited 8 participants (aged 23-47) by direct email to the participants of the previous study. Since they all were familiar with Clint, our expertise criterion does not apply.

Apparatus. e study was conducted with a prototype of Clint running on a 15" MacBook Pro. Participants were interacting with the laptop keyboard and a standard Apple mouse.

Procedure. e task consisted in transforming a program part so that the maximum number of loops becomes parallelizable. Participants had to transform the program, but not to include parallelism-speci c constructs, e.g., OpenMP pragmas, in order to avoid bias from individual expertise di erences. e experiment has a [3 × 3] within-subject design with two factors:

• T used in the trial: Code -writing code in an editor of user's choice, no visualization available; Viz -direct manipulation, no code visible; Choice -full interface, with direct manipulation and source code editing.

• D of the task: Easy -two-dimensional case with at most two transformations; Medium -two-or three-dimensional case with rectangular bounds and at most three transformations; Hard -two-or three-dimensional case with mutually-dependent bounds and at least two transformations. Trials were grouped in three blocks by T . e Code and Viz blocks were presented rst. eir order was counterbalanced across participants. Choice was always presented last in order to assess participants' preference in using code editing or direct manipulation a er having used both. In each block, participants were presented with one task of each di culty level in random order. Tasks were randomly picked into di erent blocks across participants. ey were drawn from real-world program examples and polyhedral benchmarks. Trials were not limited in time and participants were asked to explicitly end the trial by pushing an on-screen bu on. Prior to the experiment, participants were instructed about source code transformations and the corresponding direct manipulation techniques. ey also practiced 4 trials of medium di culty for each technique before the experiment and were allowed to perform two "recall" practice trials before each T block. Each session lasted about 60 minutes. e study was completed by a demographics questionnaire. Data Collection. For each trial, we measured:

• the overall trial Completion Time;

• First Change Time, the amount of time from the start to the rst change in the program structure (code edited or visualization manipulated); • Success Rate, the ratio between the number of loops made parallel by transformation and the total number of possibly parallel loops. We recorded both the nal state and all intermediary transformations to the program. During the analysis, we performed a log-transform of the Completion Time and First Change Time.

Results and Discussion

. Because this experiment was conducted with a small sample, we mostly report results graphically in order to illustrate general trends. We did not observe any ordering e ect of T or D on Completion Time and Success Rate.

Accuracy and E ciency. Fig. 10a suggests, despite large variability, that participants were in general more successful in transforming the program with direct manipulation than with code editing. E ect sizes reach 40% and 44% for Easy and Medium tasks. However, for Hard tasks, the success rates are identical. is suggests that nding a multi-step transformation is a key di culty.

Fig 10b suggests that, for successful trials, participants performed the transformation consistently faster in Viz condition. e di erence in variability between Code and Viz suggests that direct manipulation compensates for individual expertise di erences. Similar Completion Times for failed trials can be explained, a er analyzing the transformations, by participants "abandoning" the trial if their rst a empt did not expose parallelism and submi ing a non-parallelizable version.

Strategy and Exploration. Participants at least tried to perform a transformation in 76% cases with Code and 94% with Viz, suggesting that visualization engages participants by changing the perception of task di culty. We computed the ratio First Change Time/Completion Time as a measure of "engagement" (Fig. 10c). It increases with di culty for Code, but drastically decreases for Viz, suggesting that participants were more likely to adopt an exploratory trial-and-error strategy supported by the interactive visualization as opposed to code. In Choice condition, the ratio remains stable, as participants spent time choosing which representation to use.

Choice between Code Editing and Direct Manipulation. In the Choice condition, only 3 participants interacted with the code. ey made edits during the rst 30s and then switched to the visualization. A er the experiment, they explained to have modi ed the code for the sake of analysis, e.g., to see whether a dependence was triggered by a particular access they temporarily removed.

We observed that most participants were examining the code, but not selecting it. is observation suggests that, although they see the limitations of code representation, participants may need it to relate to the conventional program editing that be er corresponds to their expertise.

Preference for Code or Visualization

Our last experiment investigates the use of textual and visual representations for SCoPs. We relied on eye tracking technology in order to precisely measure visual a ention between code and visualization when both were available. We expect that, given su cient training, users will prefer visualization to code analysis if there is a meaningful task-relevant mapping between the two. is experiment required a pair of small program analysis tasks such that either code or visualization support each of them be er, but never both. Participants had to answer a binary question, with positive or negative formulation to avoid bias. e study was structured as the previous one.

Protocol.

Participants. We recruited 12 participants (aged 21-34, mean=27) through mailing lists. ey did not participate in previous studies and had a self-reported experience in programming of 5 to 15 years. All had normal uncorrected vision.

Apparatus. e experimental setup consisted of a 15" MacBook Pro with 2880 × 1800 screen at 220 ppi connected to the SMI-ETG v1 eye-tracking system 4 . e participant was seated 70 cm away from the screen, which resulted in gaze position accuracy of 27.7px in screen space. e tracking system outputs a 30 FPS video stream from its frontal camera. We placed bright-colored tokens on the screen corners to locate it in the video and compensate for perspective distortion. ese tokens were tracked by a custom OpenCV-based script that generated gaze position in screen coordinates through linear interpolation with perspective correction.

We ensured that the sizes of both representations are identical across conditions, with the content centered in each of them. Unused space was lled with neutral gray to avoid distraction. When visible, multiple representations were 60 px away (2× resolution) to identify gaze into one of them.

Procedure. e study is a [3 × 3 × 2] within-participants experiment with 4 repetitions per participant and the following factors:

• R used in the trial, one of visual representation (Viz), source code (Code) or both simultaneously (Choice); • D of the question, one of Easy, a loop nest with constant conditions, Medium, a loop nest with at least 3 non-constant conditions, or Hard, a loop nest with a branch inside and at least 5 non-constant conditions;

• a binary asked to the user, either concerns the textual form of loop bounds (Bounds) or a statement instance being executed or not inside a loop (Execution). Bounds questions were targeted at Code, where the answer is immediately visible, while Execution questions were targeted at Viz. We refer to these conditions as matching questions, and to other conditions as mismatching questions. In total, we collected data for 12

• 3 • 3 • 2 • 4 = 864 trials.
Trials were rst blocked by R and then by repetition. R blocks are ordered identically to the previous study. Each of them comprises 4 repetition blocks, each of which has 6 trials with di erent and D in a randomized order. R blocks were preceded by a practice session with 4 trials of Medium di culty. A er each trial in Choice condition, participants were asked about their preferred representation for this question.

Blocks featuring only Code or Viz were conducted without eye tracking. Participants were wearing the eye-tracking glasses for the third block, a er we performed a 3-point calibration with 30px tokens and checked if the glasses did not a ect their vision by performing a read-aloud test.

Participants started the trial by clicking the "start" bu on and ended it by clicking the answer bu on. ey could abandon the trial a er at least 15s to avoid immediate abandons for Hard tasks with mismatching questions. So ware provided the correct answer a er each trial. One session lasted 50 minutes on average and was complemented by a demographic questionnaire. Data Collection and Processing. We collected the following data:

• Completion Time of the trial;

• Correctness of the answer;

• Preference between R for the last block; • Gaze from the eye-tracking glasses for the last block.

Given gaze position in screen coordinates, we identi ed the widget in the focus of a ention as one out of three: Code Widget, Viz Widget or estion Widget. Outside any of the widget areas, the gaze was considered O Screen. We randomly sampled 10 frames from each video and veri ed manually that the script provides exact classi cation.

Completion Time was log-transformed to compensate the positive skew of its distribution.

Results and Discussion

.

Ordering e ects. We observed a slight decrease in Completion Time between rst blocks, e ect size -13.6% (95%CI = [-37.7, 6.1]), but large variability does not allow to conclude on the presence of a learning e ect. Correctness did not vary substantially between blocks.

Completion Time. Mismatching questions required substantially more time to complete the trial than matching questions, except for Easy tasks as shown in Fig. 11a . ese results suggest that, given two representations, participants are likely to chose the matching one. Although they do not spend more time on average, the variability is larger for Choice condition. It suggests that participants only e ectively use one representation, but consider both. We illustrate this later with eye tracking data.

Correctness. e participants succeeded to answer the majority of the questions with 93% (95%CI = [90, 95]) of correct results on average as shown in Fig. 11b. Abandoned trials were considered as incorrect answers. Overall trends are similar to Completion Time.

Given Choice, participants had a high success rate overall, except Easy Execution questions with mean Success Rate 89.5% (95%CI = [79%, 100%]). is may be explained by choosing the mismatching Code representation due to visible task simplicity. Due to low error rates, we did not perform any further analyses. Only 4 trials were abandoned, all featuring mismatching questions, 3 of which with Code. Abandons took place a er 91s on average whereas the mean trial duration is 13.7s. Representation Choice. Our analyses are built on the following metrics, de ned prior to the study. Visual Preference, VP -total duration of gaze on the Viz Widget divided by the total duration of gaze on Viz or Code Widget. Values close to 1 indicate participant looking more at the visualization.

Representation Uncertainty, RU -the measure of a ention distribution computed as RU = 2 • abs(VP -0.5). High values mean a ention was distributed evenly between representations, low values -that only one representation was used.

We expect Completion Time to increase with Representation Uncertainty as the participant uses two representations where one would su ce. At the same time, it may increase even more for lower values of Representation Uncertainty and high Visual Preference for the unadapted representation.

Fig. 12a shows the Visual Preference for di erent conditions, the center line corresponding to the equal distribution of visual a ention. For Medium and Hard tasks, participants spent more time on matching representations, e ect sizes reach 66.6% (95%CI = [4.8, 128.5]) and 81.2% (95%CI = [16.7, 145.7]), respectively. For Easy tasks they relied on the Code independent of . e reported Preference, depicted on Fig. 12b, shows the same tendency. e preference for Code drops from 56% in Easy Execution tasks to 6% in Medium and Hard Execution tasks. Since we asked which representation they found "most useful", the di erence between reported Preference and Visual Preference suggests that participants tend to look at both representations even though they do not nd one of them useful. Nevertheless, we observed a positive correlation between reported Preference and Visual Preference, r =0.41 (95%CI = [0.20, 0.57]), suggesting that participants tend to use more the representation they nd useful. Overall, we observed a correlation between Representation Uncertainty rate and Completion Time, r =0.41 (95%CI = [0.19, 0.58]) as well as a negative correlation between Representation Uncertainty rate and Correctness, r =-0.27 (95%CI = [-0.47, -0.04]): the more participants' a ention was distributed between representations, the less correct answers they gave. Although the correlation does not imply causality, the connection between the simultaneous use of di erent representations and the total trial duration suggests that one matching representation should be preferred to two.

RELATED WORK

Interactive Program Parallelization. Program editors supporting interactive program parallelization date back to wide adoption of parallelism for scienti c programming. We review those speci cally targeting loop-level optimizations. e ParaScope editor [START_REF] Kennedy | Interactive Parallel Programming Using the ParaScope Editor[END_REF] provided dependence analysis and interactive loop transformation for High-Performance F (HPF). It reported the dependence analysis results and allowed the user to perform various loop transformations, including parallelization.

e D Editor interacted with an distributed HPF compiler to report optimization choices regarding data distribution and parallelization [START_REF] Hiranandani | e D Editor: A New Interactive Parallel Programming Tool[END_REF]. SUIF Explorer took a di erent approach, collecting dynamic execution and dependence data to suggest loops (or parts thereof thanks to program slicing [START_REF] Weiser | Program Slicing[END_REF]) for parallelization [START_REF] Liao | SUIF Explorer: An Interactive and Interprocedural Parallelizer[END_REF]. Similarly, DECO records traces of the memory accesses along with cache hit information and uses pa ern recognition algorithms to suggest memory optimizations [START_REF] Tao | An Interactive Graphical Environment for Code Optimization[END_REF]. NaraView provides a navigable 3D visualization of loop-level access pa erns [START_REF] Sasakura | NaraView: An Interactive 3D Visualization System for Parallelization of Programs[END_REF]. Contrary to these tools, Clint uses the polyhedral model with its instancewise dependence analysis and static guarantees of loop transformation legality. It also allows for transforming the program using its visualization. Chlore-based transformation replay is not tied to particular compiler transformations.

Semi-Automatic Polyhedral Transformations. User-assisting tools based on the polyhedral model emerged as a means to express "classical" loop transformations [START_REF] Joseph | High Performance Compilers for Parallel Computing[END_REF] in the model, the Uni ed Transformation Framework (UTF) stemming from the rst approach [START_REF] Kelly | A Unifying Framework for Iteration Reordering Transformations[END_REF]. URUK was proposed to improve loop transformation composability and enable automated traversal of a transformation search space [START_REF] Girbal | Semi-Automatic Composition of Loop Transformations for Deep Parallelism and Memory Hierarchies[END_REF], delaying the legality analysis until code generation. Loop Transformation Recipes combine loop transformations, mapping to accelerators and code generation directives from CHiLL [START_REF] Chen | CHiLL: A for Composing High-Level Loop Transformation[END_REF] with the POET [START_REF] Yi | POET: Parameterized Optimizations for Empirical Tuning[END_REF] language for auto-tuning speci cation. AlphaZ focuses on equational programming and enables complex memory mapping and management [START_REF] Yuki | Alphaz: A System for Design Space Exploration in the Polyhedral Model[END_REF]. Clay is arguably the rst complete set of directives for polyhedral program transformations [START_REF] Bagnères | Opening Polyhedral Compiler's Black Box[END_REF]. Clint uses visualization and direct manipulation to address the challenges of directive-based approaches, such as identifying a promising transformation, targeting it at a program entity or evaluating its e ects.

Visualizations for the Polyhedral Model. e literature on the polyhedral model heavily relies on sca erplot-like visualizations of iteration domains. Polyhedral libraries include components for visualization, including VisualPolylib [START_REF] Loechner | PolyLib: A library for manipulating parameterized polyhedra[END_REF] for Polylib and islplot [START_REF] Grosser | islplot: Library to Plot Sets and Maps[END_REF] for isl [START_REF] Verdoolaege | Isl: An Integer Set Library for the Polyhedral Model[END_REF]. LooPo was arguably the rst tool to visualize the polyhedral dependence analysis information during program transformation [START_REF] Griebl | e Loop Parallelizer LooPo-Announcement[END_REF]. Tulipse integrates polyhedral visualization into Eclipse IDE [START_REF] Wong | Tulipse: A Visualization Framework for User-Guided Parallelization[END_REF]. Clint goes beyond static visualization by enabling direct manipulation to transform the program.

3D iteration space visualizer lets the user interactively request loop parallelization through a visual representation [START_REF] Yu | Loop Parallelization Using the 3D Iteration Space Visualizer[END_REF]. Polyhedral Playground [START_REF] Grosser | PollyLabs Polyhedral Playground[END_REF] augments a web-based polyhedral calculator with domain and dependence visualizations. PUMA-V provides a set of visualizations that expose internal operation of the R-Stream compiler [START_REF] Papenhausen | PUMA-V: An Interactive Visual Tool for Code Optimization and Parallelization Based on the Polyhedral Model[END_REF][START_REF] Papenhausen | Polyhedral User Mapping and Assistant Visualizer Tool for the R-Stream Auto-Parallelizing Compiler[END_REF]. It allows the user to control the optimizationrelated compiler options from the visualization. Clint builds on Clay as intermediate abstraction and does not require the user to control or even understand the operation of a compiler.

CONCLUSION

Clint addresses the issues of directive-based approaches in the polyhedral model: target identication is made direct without exposing polyhedral-speci c concepts; transformation legality and e ects are visible immediately during manipulation; reading polyhedrally-transformed code is no longer necessary. It makes loop optimization accessible, interactive and independent of a particular algorithm. Our approach enables human-machine partnership where an automatic framework performs heuristic-driven transformation and provides feedback on demand while a user brings in domain knowledge to tweak the transformation without modifying the heuristics. Such domain knowledge may be unavailable to framework designers and di er between use cases.

Experiments suggest that visualizations lower the expertise necessary to perform aggressive program restructuring and decrease the time necessary for program analysis. Semi-automatic transformation decreases the time of program transformation. In our studies, visual semi-automatic approach to program transformation doubled the success rate and decreased the required time by a factor of 5 for some program structures. We also contribute to the discussion on visualization acceptance, suggesting its perceived utility increases with the relative complexity of the task.

Limitations. As Clint was designed using a set of polyhedral test cases with small number of statements nested in shallow loops, it may be subject to clu ering for larger program parts. Long blocks of interdependent statements may result in a profusion of dependence arrows. Visual replay may become distracting when multiple projections are rendered for deep loops. However, program parts amenable to the polyhedral model are typically small yet require aggressive transformation.

Future Work. Drawing from the eye-tracking study conclusions and existing limitations, the visual approach seems promising yet restricted for di cult cases. We plan to address those by interleaving visual representations and code fragments and by proposing a zoomable interface with di erent levels of detail. At the same time, the visualization may be bene cial for learning, which can be supported with a smooth transition between code and visual representation.

Visual clu ering can be addressed by only displaying salient parts. ey can be identi ed directly by the users, or inferred from their behavior. On the other hand, a polyhedral compiler may provide additional feedback on, e.g., dependences that prevent parallel execution. Finally, Clint visualizations may be used conjointly with performance models and runtime evaluators, and integrated into a larger development environment in order to account for program parallelization all along the development process.

Fig. 1 .

 1 Fig. 1. Polynomial Multiply computation kernel.

  = 0; i < N; ++i) for (j = 0; j < N; ++j) z[i+j] += x[i] * y[j];

Fig. 2 .

 2 Fig. 2. Performing a skew transformation to parallelize polynomial multiplication loop by deforming the polygon. The code is automatically transformed from its original form (le ) to the skewed one (right).

  for (i = 0; i < N; ++i) for (j = 0; j < N; ++j) { A[i+1][j+1] += 0.5 * A[i+1][j]; B[i+1][j+1] += A[i][j]; } for (j = 0; j < N; ++j) B[1][j+1] += A[0][j]; #pragma omp parallel for private(j) for (i = 0; i < N; ++i) for (j = 0; j < N; ++j) { A[i+1][j+1] += 0.5 * A[i+1][j]; B[i+1][j+1] += A[i][j]; } for (j = 0; j < N; ++j) A[N][j+1] += 0.5 * A[N][j];

  (a) Clint interface includes: (1) interactive visualization with multiple projections, (2) editable history view of transformations, and (3) source code editor; all coordinated with each other. (b) When main projection is manipulated, auxiliary projections are updated simultaneously.

Fig. 5 .

 5 Fig. 5. Clint displays multiple projections for deep loop nests.

Fig. 6 .

 6 Fig. 6. Users can directly manipulate the visual representation of SCoPs and have the transformed program generated automatically. Dragging the corner from the center performs loop skewing, to the center-reversal; selecting the points and dragging them performs index-set spli ing followed by loop shi ing. Dependence arrows orthogonal to axes enable parallel execution.

Fig. 8 .

 8 Fig. 8. Using visual representation to re-adjust automatically computed transformation with immediate feed-forward on semantics preservation. Dependences violated by the intended transformation turn red, within shapes depict tiles. Shaded shapes are positions before manipulation.

Fig. 9 .

 9 Fig. 9. (a) Completion Times increase with task di iculty but less so for Experts. Results are similar between Experts and Non-Experts. Error bars are 95% confidence intervals. (b) overall Error Rate is low. Experts are more successful but fail at simpler tasks; Non-Experts may abandon.

Fig. 10 .

 10 Fig. 10. (a) Success Rate is higher with Viz, except for Hard tasks. (b) Completion Time is lower with Viz, especially in successful trials. (c) Ratio First Change Time / Completion Time; the change in trend between Code and Viz may be due to users adopting an exploratory strategy. Error bars are 95% CIs.

Fig. 11 .

 11 Fig. 11. (a) mismatching questions required up to 4× more time. (b) Medium and Hard questions with mismatching representation result in more incorrect answers. Completion Times and Correctness Ratios for C are close to those for matching representation. Dots are means, error bars are 95% CIs, vertical density plots show underlying distributions.

  . With Code, participants spent 14% (95%CI = [-22, 40]) more time on Easy Execution questions, and respectively 132% (95%CI = [108, 146]) and 134% (95%CI = [111, 147]) more time on Medium and Hard Execution questions than on the Bounds questions of the same di culty. Similarly, with Viz representation, they answered Execution questions 9% (95%CI = [-20, 49]), 40% (95%CI = [1, 102]) , and 57% (95%CI = [10, 129]) faster for increasing D . is result supports the de nition of mismatching question suggesting that a representation not adapted for the question slows participants down. e smaller increase of Completion Time with Viz compared to Code suggests that Viz representations allows to reason about mismatching questions easier than Code. Choice condition shows Completion Times close to those for matching representation. For Bounds questions, it took on average 6% (95%CI = [-27, 56]), -3% (95%CI = [-40, 56]), and 7% (95%CI = [-33, 70]) more time compared to Code for increasing D . For Execution questions, it took 5% (95%CI = [-27, 53]), -14% (95%CI = [-54, 54]) and -21% (95%CI = [-63, 58]) more time than Viz for increasing D

Fig. 12 .

 12 Fig. 12. (a) matching representations are more used for Medium and Hard tasks, but Code for Easy tasks. (b) reported preference demonstrates similar trend. Dots are means, error bars are 95% CIs.

ACM Transactions on Architecture and Code Optimization, Vol. 15, No. 1, Article 16. Publication date: March 2018.

In fact, we created R transformation in Clay to address the skew combination problem. It was the last missing transformation that enabled completeness of the set. ACM Transactions on Architecture and Code Optimization, Vol. 15, No. 1, Article 16. Publication date: March

4× Intel Xeon E5-2630 (Sandy Bridge, 6 cores, 15MB L3 cache), 64 GB RAM, running CentOS Linux 7.2.1511, compiled with GCC 4.9.3 with -O3 -march=native ags, benchmark size LARGE, NQ= 140, NR= 150, NP= 160. Average of 12 runs is reported, kernel execution time only, using high-resolution CPU timers.

Pluto 0.11.4 with --parallel --tile, as available on h ps://github.com/bondhugula/pluto/releases/tag/0.11.4 ACM Transactions on Architecture and Code Optimization, Vol. 15, No. 1, Article 16. Publication date: March 2018.

h p://www.eyetracking-glasses.com/ ACM Transactions on Architecture and Code Optimization, Vol. 15, No. 1, Article 16. Publication date: March 2018.

for (r = 0; r < NR ; r ++) for (q = 0; q < NQ ; q ++) { for (p = 0; p < NP p ++) { sum [p] = 0.0; for (s = 0; s < NP ; s ++) sum e nal manually retouched version runs in 0.67s with a (modest) 25% speedup. Without step-by-step replay and direct manipulation, it would be hard to experiment with di erent fusion structures using a general trial-and-error strategy.

Although loop fusion is o en implemented as a separate optimization problem in polyhedral optimizers, it is no easier to control externally. Clint allows users to understand and directly modify the fusion/ ssion structure, instead of reasoning about how a particular heuristic would behave.