PaperlayerView exact revision on arXiv

Source-linked AI summary

A Transprecision Floating-Point Platform for Ultra-Low Power Computing

Giuseppe Tagliavini, Stefan Mach, Davide Rossi, Andrea Marongiu, Luca Benini

arXiv:1711.10374v1cs.AR

TL;DR

Embedded FP workloads consume energy through both computation and operand movement, while reduced-precision formats require tuning against application requirements. This paper combines a tunable FP type system, precision-analysis workflow, and hardware support; its benchmarks report lower energy, execution time, and memory accesses.

  • Problem

    FP operations and operand transfers consume substantial energy in embedded computing, while software flows lack a methodology to evaluate reduced-precision variables against application requirements.

    Source: §I · p. 1

  • Method

    The paper proposes an extended FP type system with new formats, a library and workflow for tuning precision and dynamic range, and hardware support for transprecision operations.

    Source: §I · p. 1

  • Results

    Energy consumption falls 18% on average and up to 30% for specific applications, while execution time falls 12% and memory accesses fall 27%.

    Source: §VI · p. 6

  • Takeaways & Limitations

    Up to 90% of FP operations can be safely scaled to 8-bit or 16-bit formats, and vector operations on smaller formats reduce pressure on data memory.

    Source: §I · p. 1

    The current GCC version lacks instructions for binary16, binary16alt, and binary8, so the evaluation derives their execution-time contribution analytically.

    Source: A. Evaluation Methodology · p. 4

Abstract

from arXiv · show

In modern low-power embedded platforms, floating-point (FP) operations emerge as a major contributor to the energy consumption of compute-intensive applications with large dynamic range. Experimental evidence shows that 50% of the energy consumed by a core and its data memory is related to FP computations. The adoption of FP formats requiring a lower number of bits is an interesting opportunity to reduce energy consumption, since it allows to simplify the arithmetic circuitry and to reduce the memory bandwidth between memory and registers by enabling vectorization. From a theoretical point of view, the adoption of multiple FP types perfectly fits with the principle of transprecision computing, allowing fine-grained control of approximation while meeting specified constraints on the precision of final results. In this paper we propose an extended FP type system with complete hardware support to enable transprecision computing on low-power embedded processors, including two standard formats (binary32 and binary16) and two new formats (binary8 and binary16alt). First, we introduce a software library that enables exploration of FP types by tuning both precision and dynamic range of program variables. Then, we present a methodology to integrate our library with an external tool for precision tuning, and experimental results that highlight the clear benefits of introducing the new formats. Finally, we present the design of a transprecision FP unit capable of handling 8-bit and 16-bit operations in addition to standard 32-bit operations. Experimental results on FP-intensive benchmarks show that up to 90% of FP operations can be safely scaled down to 8-bit or 16-bit formats. Thanks to precision tuning and vectorization, execution time is decreased by 12% and memory accesses are reduced by 27% on average, leading to a reduction of energy consumption up to 30%.

I. INTRODUCTION

Floating-point computation and operand movement consume substantial energy in embedded workloads, while conventional development flows lack a way to assess reduced-precision variables against application requirements. The paper proposes an extended FP type system, exploration and tuning methods, and hardware support, reporting reduced execution time, memory accesses, and energy consumption.

I. INTRODUCTION

  • Energy use is substantial: FP operations account for 30% of core energy and moving FP operands accounts for another 20%.The measurements were taken on FP-intensive applications running on PULPino.Source: §I · p. 1
  • The proposed type system adds binary8 and binary16alt alongside standard formats, with binary8 offering low precision and binary16alt a wider dynamic range.The formats are intended to support fine-grained precision choices while meeting final-result precision constraints.Source: §I · p. 1
  • A C++ library explores variable precision and dynamic range, and a methodology integrates it with an external precision-analysis tool.The applications use emulated FP types during the precision analysis.Source: §I · p. 1
  • A dedicated transprecision FP unit supports smaller-format vector operations, increasing energy efficiency and performance while reducing pressure on data memory.The proposed hardware supports 8-bit and 16-bit operations in addition to standard 32-bit operations.Source: §I · p. 1
  • Up to 90% of FP operations can be safely scaled to 8-bit or 16-bit formats; execution time falls 12%, memory accesses fall 27% on average, and energy consumption falls up to 30%.The reported energy reduction is up to 30%, while the execution-time and memory-access reductions are average results.Source: §I · p. 1

II. RELATED WORK

Existing approaches offer arbitrary-precision arithmetic, software emulation, precision tuning, or energy-efficient hardware, but each has limitations for exploring reduced FP formats or evaluating whole-program effects. The paper positions its approach against these constraints.

II. RELATED WORK

  • ARPREC and MPFR support arbitrary-precision arithmetic but are unsuitable for exploring sub-32-bit formats because their exponents use a full machine word.This prevents tuning the dynamic range of simulated formats.Source: §II · pp. 1–2
  • SoftFloat emulates IEEE formats bit-accurately and can be extended, but runs extremely slowly and requires manual changes across source files for new formats.The discussed solutions can require full source-code refactoring or additional software layers.Source: §II · p. 2
  • DistributedSearch heuristically tunes variable precision for a fixed input set and refines bindings across input sets, but does not analyze dynamic range.Other tools either restrict the search to standard FP types or analyze only functional expressions.Source: §II · p. 2
  • Prior hardware approaches include variable-precision units with tracking overhead, digit-serial multipliers that slow single-precision operations, and domain-specific LNS units.Reported trade-offs include memory overhead for precision tracking and unconsidered memory effects; LNS cannot implement all FP operations.Source: §II · p. 2

A. Exploration of floating-point formats

The section develops a library and wrapper for exploring FP formats, then examines format choices that trade precision against dynamic range. Preliminary tuning results show that binary8 can be useful in some cases and that adding binary16alt can reduce the need for 32-bit variables.

A. Exploration of floating-point formats

  • FP formats trade dynamic range, determined by exponent bits, against precision, determined by significand bits.The section describes IEEE formats as a sign bit, exponent field, and significand field.Source: A. Exploration of floating-point formats · p. 2
  • FlexFloat provides a generic C++ FP type whose exponent and mantissa widths are template parameters, enabling arbitrary-format exploration without changing other program code.It sanitizes native-type arithmetic results to reproduce the original format at bit level; type mismatches require explicit casts.Source: A. Exploration of floating-point formats · p. 2
  • The FlexFloat wrapper reads required variable precision and a precision-to-range mapping, then compiles the program with those values as template parameters.This connects external precision-tuning output to exploration of FP formats.Source: A. Exploration of floating-point formats · p. 3
  • The selected formats assign binary8 a 5-bit exponent and binary16alt an 8-bit exponent, while standard binary16 uses a 5-bit exponent.Binary16alt retains binary32's dynamic range with coarser granularity; binary8 was chosen to match binary16's dynamic range and permit cheaper operations.Source: A. Exploration of floating-point formats · p. 3
  • Among benchmarks constrained to precision 10^-1, binary8 accounts for 17% of variables in the best case; adding binary16alt to binary8, binary16, and binary32 reduces 32-bit variables versus one 16-bit format.Source: A. Exploration of floating-point formats · p. 3
  • Binary16 can saturate when converting large-magnitude binary32 values, whereas binary16alt preserves the full range but may provide insufficient precision for some applications.The results motivate retaining both 16-bit formats because some applications need range and others need greater precision.Source: A. Exploration of floating-point formats · p. 3

B. Transprecision programming flow

The programming flow replaces standard FP types with tunable FlexFloat instances, explores their parameters, and maps variables to supported types. It then gathers operation statistics and can specialize simulated operations to native ones.

B. Transprecision programming flow

  • Application sources first replace standard FP types with FlexFloat instances whose exponent and mantissa parameters can vary by variable.The flow then invokes precision tuning to explore parameter values through the FlexFloat wrapper.Source: B. Transprecision programming flow · p. 3
  • After tuning, variables are mapped to supported FP types, and FlexFloat reports operation and cast counts for each instantiated type.Source: B. Transprecision programming flow · p. 3
  • A specialized FlexFloat version replaces simulated operations with native ones, provided the target compiler supports all mapped FP types.Source: B. Transprecision programming flow · p. 3

IV. TRANSPRECISION FLOATING POINT UNIT

The transprecision FP unit supports operations across 8-, 16-, and 32-bit slices, with narrower slices replicated for subword parallelism. It also provides format conversions and uses operand silencing to save power.

IV. TRANSPRECISION FLOATING POINT UNIT

  • Two 16-bit or four 8-bit FP operations can execute simultaneously through replicated narrower slices.The unit runs scalar operations with one active slice and vectorial operations when all slices of a precision are active.Source: §IV · p. 3
  • The unit supports 32-, 16-, and 8-bit slices for matching FP formats, arithmetic, and conversions.Supported arithmetic operations are addition, subtraction, and multiplication; conversions include integer casts and casts among FP formats.Source: §IV · p. 3
  • Figure 3 is a simplified datapath diagram that omits control logic and data to and from duplicated slices.Table I is captioned as classifying variables by type using V1 and V2 type systems.Source: Table I · p. 3, Figure 3 · p. 4
  • Operand silencing forces zero into unused operations and formats, while binary8 arithmetic and conversions have one-cycle latency.Binary32 and both 16-bit formats are pipelined with one stage, yielding one operation per cycle and two-cycle latency; area optimization and core integration remain future work.Source: §IV · p. 4

V. EXPERIMENTAL RESULTS

The evaluation uses six embedded-computing and machine-learning applications, with precision tuning and execution measurements on PULPino. Hardware energy is estimated from post-place-and-route simulations under specified worst-case conditions.

A. Evaluation Methodology

  • Six applications cover near-sensor computing and embedded machine learning, including JACOBI, KNN, PCA, DWT, SVM, and CONV.Precision tuning used fpPrecisionTuning on an x86 workstation, while binaries ran on the cycle-accurate PULPino virtual platform.Source: A. Evaluation Methodology · p. 4
  • Current GCC lacks instructions for binary16, binary16alt, and binary8, so binary32 instruction cycles were used to measure binary16 latency.Binary8 and cast contributions were accumulated analytically at one cycle each; cycle estimates depend on compiler scheduling and application behavior.Source: A. Evaluation Methodology · p. 4
  • The transprecision unit was evaluated in UMC 65 nm worst-case conditions using post-place-and-route power simulations at 350 MHz.Simulations excluded NaNs, infinities, cancellation, and conversions that over- or underflow; PULPino integration was not yet complete, so register-transfer and pipeline-stall costs were included in energy measures.Source: A. Evaluation Methodology · p. 4

B. Precision Tuning

Precision tuning across three SQNR requirements shows that format suitability depends on both precision and dynamic range. Binary8 suits some application domains, while binary16 and binary16alt serve distinct needs.

B. Precision Tuning

  • KNN and SVM make wide use of binary8, while binary16 is a candidate for wider use across applications.The table reports memory locations requiring each precision-bit count for SQNR = 10^-3, 10^-2, and 10^-1.Source: B. Precision Tuning · p. 5
  • Values in the 9–11 precision-bit interval concentrate at 9 bits because they need binary16's precision beyond binary16alt.The passage says both 16-bit types are useful in different contexts.Source: B. Precision Tuning · p. 5
  • Variables at 4 precision bits outnumber those at 5 because they do not require binary8's wider dynamic range.Variables requiring high precision usually need more than 12 precision bits and concentrate in the final table column.Source: B. Precision Tuning · p. 5

C. Execution time and memory accesses

The runtime breakdown reveals that reduced-precision benefits vary by application: vectorization drives gains in many benchmarks, but JACOBI and PCA retain important obstacles. Across applications, execution time falls by 12% and memory accesses by 27% on average.

C. Execution time and memory accesses

  • JACOBI and PCA have a major contribution of 32-bit operations, and JACOBI also lacks vectorial operations.The evaluated applications were off-the-shelf versions; advanced coding techniques such as manual vectorization were not considered.Source: C. Execution time and memory accesses · p. 5
  • 12% lower execution time and 27% fewer memory accesses on average; excluding JACOBI and PCA, reductions are 17% and 36%.SVM has the largest memory-access reduction, 48%, with 60% of FP operations vectorizable for every precision requirement.Source: C. Execution time and memory accesses · p. 5
  • JACOBI performs no vector operations, and its cycles match baseline when it uses only a limited number of binary16alt variables.Cast overhead can make cycles exceed baseline; PCA casts exceed 10% at SQNR = 10^-1 and 20% at SQNR = 10^-2 and 10^-3.Source: C. Execution time and memory accesses · p. 5

D. Energy consumption

Energy use varies with the application and its use of smaller formats and vectorization. Manual vectorization lowers PCA energy, while cast costs remain a target for further savings.

D. Energy consumption

  • Around 18% energy savings are measured on average for the other applications, with KNN reaching 30%; JACOBI averages 97%, while PCA exceeds baseline by 7% and 8% for two precision requirements.Energy values are normalized to the binary32 baseline.Source: D. Energy consumption · p. 5, Figure 7 · p. 6
  • Vectorization can benefit applications with a relevant share of tuned operations below 32 bits.Source: D. Energy consumption · p. 5
  • Manual vectorization lowers PCA energy to 101%, 96%, and 85%; further savings require reducing cast contributions with smarter precision-tuning tools.Source: D. Energy consumption · p. 6

VI. CONCLUSION

The paper concludes that its extended FP type system and vectorization reduce energy and other resource demands on ULP embedded platforms. It identifies precision tuning, hardware, and compiler/vectorization improvements as future work.

VI. CONCLUSION

  • Energy use falls by 18% on average and up to 30%, while execution time decreases by 12% and memory accesses by 27%.Source: §VI · p. 6
  • The extended FP type system has complete hardware support and leverages vectorization to reduce energy consumption.Source: §VI · p. 6
  • Future work targets cast-aware multiobjective precision tuning, more efficient transprecision hardware, and compiler/vectorization techniques that better exploit opportunities at compile time.Source: §VI · p. 6
Loading 1711.10374v1…