Fix the code. Don't tweak the hardware

Jimborean, Alexandra; Koukos, Konstantinos; Spiliopoulos, Vasileios; Black-Schaffer, David

doi:10.1145/2544137.2544161

Cited by 13 publications

(12 citation statements)

References 31 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…State-of-the-art compilers [33,69] have shown that it is possible to identify critical loads using static heuristics, to find sufficient independent instructions to hide memory latency, to break chains of dependent long-latency instructions that may stall the processor, to reuse already computed values, and to load data earlier in order to avoid branch re-execution and recomputations (e.g., in complex versions of software pipelining). While these techniques build on standard compiler methods like VLIW [22], PlayDoh, and Cydrom [59], they provide support for applications previously not amenable to global instruction scheduling and pipelining due to the complex control-flow and entangled dependencies.…”

Section: Motivation and Backgroundmentioning

confidence: 99%

“…The SWOOP compiler decouples critical loops in Access and Execute phases, following a technique that melds program slicing [75], software decoupled access-execute [33] and lookahead compile-time scheduling [69]. Access phases are allowed to execute out-of-program-order (eagerly, before their designated time in the original program order), while Execute phases are kept in program order, as illustrated in Figure 2.…”

Section: Swoop Compilermentioning

confidence: 99%

“…Access is built by hoisting loads, address computation, and the required control flow, following the use-def chain of instructions [33,75]. The delinquent loads and their requirements (i.e., instructions required to compute the addresses and to maintain the control flow) are hoisted to an Access phase.…”

Section: Swoop Compilermentioning

confidence: 99%

“…SWOOP relies on a compiler that builds upon classical optimization techniques for limited hardware: global scheduling, modulo scheduling [2,48], software pipelining [43,58], decoupled access-execute [33,42,69], etc., but uses clever techniques to extend the applicability of these proposals to general-purpose applications featuring complex control Figure 1. Conventional compilation stalls an in-order processor when using the results of a long latency memory access.…”

Section: Introductionmentioning

confidence: 99%

“…The SWOOP core is an inorder based hardware-software co-designed processor that benefits from software knowledge to enable the hardware to execute non-speculatively past the conventional dynamic instruction stream. The SWOOP compiler generates Access-Execute phases, akin to look-ahead compile-time instruction scheduling (Clairvoyance) [69] and the software decoupled accessexecute (DAE) [33] model in which the target code region is transformed into i) a heavily memory-bound phase (i.e., the Access-phase for data prefetch), followed by ii) a heavily compute-bound phase (the Execute-phase that performs the actual computation). Unlike DAE, SWOOP operates on a much finer granularity and reorders instructions to load data in Access, instead of duplicating instructions for prefetching.…”

Section: Introductionmentioning

confidence: 99%

See 4 more Smart Citations

SWOOP: software-hardware co-design for non-speculative, execute-ahead, in-order cores

et al. 2018

Self Cite

View full text Add to dashboard Cite

Increasing demands for energy efficiency constrain emerging hardware. These new hardware trends challenge the established assumptions in code generation and force us to rethink existing software optimization techniques. We propose a cross-layer redesign of the way compilers and the underlying microarchitecture are built and interact, to achieve both performance and high energy efficiency.In this paper, we address one of the main performance bottlenecks-last-level cache misses-through a softwarehardware co-design. Our approach is able to hide memory latency and attain increased memory and instruction level parallelism by orchestrating a non-speculative, execute-ahead paradigm in software (SWOOP). While out-of-order (OoO) architectures attempt to hide memory latency by dynamically reordering instructions, they do so through expensive, power-hungry, speculative mechanisms. We aim to shift this complexity into software, and we build upon compilation techniques inherited from VLIW, software pipelining, modulo scheduling, decoupled access-execution, and software prefetching. In contrast to previous approaches we do not rely on either software or hardware speculation that can be detrimental to efficiency. Our SWOOP compiler is enhanced with lightweight architectural support, thus being able to transform applications that include highly complex control-flow and indirect memory accesses.The effectiveness of our software-hardware co-design is proven on the most limited but energy-efficient microarchitectures, non-speculative, in-order execution (InO) cores, which rely entirely on compile-time instruction scheduling.

show abstract

Section: Motivation and Backgroundmentioning

confidence: 99%

Section: Swoop Compilermentioning

confidence: 99%

Section: Swoop Compilermentioning

confidence: 99%

Section: Introductionmentioning

confidence: 99%

Section: Introductionmentioning

confidence: 99%

See 3 more Smart Citations

SWOOP: software-hardware co-design for non-speculative, execute-ahead, in-order cores

et al. 2018

Self Cite

View full text Add to dashboard Cite

show abstract

Efficiency analysis of modern vector architectures: vector ALU sizes, core counts and clock frequencies

et al. 2019

View full text Add to dashboard Cite

Moore's Law predicted that the number of transistors on a chip would double approximately every two years. However, this trend is arriving at an impasse. Optimizing the usage of the available transistors within the thermal dissipation capabilities of the packaging is a pending topic.Multi-core processors exploit coarse-grain parallelism to improve energy efficiency. Vectorization allows developers to exploit data-level parallelism, operating on several elements per instruction and thus, reducing the pressure to the fetch and decode pipeline stages.In this paper we perform an analysis of different resource optimization strategies for vector architectures. In particular we expose the need to break down voltage and frequency domains for LLC, ALUs and vector ALUs if we aim to optimize the energy efficiency and performance of our system. We also show the need for a dynamic reconfiguration strategy that adapts vector register length at runtime.

show abstract