oprecomp / flexfloat Goto Github PK

C library for the emulation of reduced-precision floating point types

License: Apache License 2.0

CMake 6.11% C 68.66% C++ 25.24%

flexfloat's Introduction

OPRECOMP

This is the Open Transprecision Computing project, a joint venture between IBM, ETH, CEA, UNIPG, UNIBO, CINECA, UJI, QUB, GWT, and TUKL.

OPRECOMP is a 4-year research project funded under the EU Framework Horizon 2020 – Re Program Future and Emerging Technologies (FET) Proactive Initiative: emerging themes and communities.

This is the main repository of the OPRECOMP project. Individual deliverables and development is performed in separate repositories, as follows:

oprecomp/micro-benchmarks: A collection of benchmarks used throughout the project to assess the impact of transprecision techniques on a broad range of application fields.
oprecomp/FloatX: Header-only C++ library for low precision floating point type emulation.
oprecomp/flexfloat and oprecomp/flexfloat-benchmarks: C library for the emulation of reduced-precision floating point types
oprecomp/HLS_BLSTM: The community version of HLS_BLSTM (A BLSTM FPGA accelerator of an OCR appilcation, using CAPI/SNAP)
oprecomp/DRAMSpec: A DRAM Current and Timing Generator
oprecomp/RRAMSpec: An RRAM Area, Energy and Timing Generator
oprecomp/fp-soft: Floating point implementation of multiplication and addition for processor with variable mantissa adaptation.
oprecomp/StaticFPTuner: A python module for statically tuning the precision of floating point variables.
oprecomp/kwpilot-doc: Documentation and tutorials for OPRECOMP kwpilot demonstrator.
oprecomp/oc-accel-tp: OpenCAPI Acceleration Framework: develop an accelerator with OpenCAPI technology.
oprecomp/DDR4_controller: A DDR4 memory controller.
pulp-platform/fpnew: Configurable Floating-Point Unit with Transprecision Capabilities
DRAMSys 4.0: a flexible DRAM subsystem design space exploration framework based on SystemC TLM-2.0
DynIR: Header-only C++ library and source code for iterative refinement using dynamic precision out of single, double and double-double precision.

Abstract

Guaranteed numerical precision of each elementary step in a complex computation has been the mainstay of traditional computing systems for many years. This era, fueled by Moore's law and the constant exponential improvement in computing efficiency, is at its twilight: from tiny nodes of the Internet-of-Things, to large HPC computing centers, sub-picoJoule/operation energy efficiency is essential for practical realizations. To overcome the “power wall”, a shift from traditional computing paradigms is now mandatory.

OPRECOMP aims at demolishing the ultra-conservative “precise” computing abstraction and replacing it with a more flexible and efficient one, namely transprecision computing. OPRECOMP will investigate the theoretical and practical understanding of the energy efficiency boost obtainable when accuracy requirements on data being processed, stored and communicated can be lifted for intermediate calculations. While approximate computing approaches have been used before, in OPRECOMP for the first time ever, a complete framework for transprecision computing, covering devices, circuits, software tools, and algorithms, along with the mathematical theory and physical foundations of the ideas will be developed that not only will provide error bounds with respect to full precision results, but also will enable major energy efficiency improvements even when there is no freedom to relax end-to-end application quality-of-results.

The mission of OPRECOMP is to demonstrate using physical demonstrators that this idea holds in a huge range of application scenarios in the domains of IoT, Big Data Analytics, Deep Learning, and HPC simulations: from the sub-milliWatt to the MegaWatt range, spanning nine orders of magnitude. In view of industrial exploitation, we will prove the quality and reliability and demonstrate that transprecision computing is the way to think about future systems.

Contact

Project Management Office

Cristiano Malossi
IBM Research - Zurich
Research Staff Member
[email protected]
+41(0)44 724 8616

Sara Pittaluga
IBM Research – Zurich
Business Development & Relations
European Projects Specialist
[email protected]
+41(0)44 724 8567

Repository and Software Management

Fabian Schuiki
ETH Zurich
[email protected]

Florian Scheidegger
IBM Research - Zurich
[email protected]

License

The source code in this repository is licensed under the terms of the Apache License (Version 2.0), unless otherwise specified. See LICENSE for details.

flexfloat's People

Contributors

Stargazers

Watchers

Forkers

stmach akfk powderluv srcarroll victorkliu yufeng98 nazavode gentlebreezeblow brsf11 lucabertaccini baoyoubing marcellomello2 viv-eth

flexfloat's Issues

The test value_representation_half fails

/usr/ports/math/flexfloat/work/flexfloat-6db869087a12d763a94d53e9b0a9d52def270865/test/value_representation_half.cpp:66: Failure
Expected equality of these values:
  out
    Which is: 9221120237041090560
  out_number
    Which is: 18446686899104907264
[  FAILED  ] TestWithParameters_BF_004/MyTest.TestFormula/0, where GetParam() = (18446690030136066048, 18446686899104907264) (0 ms)
[ RUN      ] TestWithParameters_BF_004/MyTest.TestFormula/1
/usr/ports/math/flexfloat/work/flexfloat-6db869087a12d763a94d53e9b0a9d52def270865/test/value_representation_half.cpp:66: Failure
Expected equality of these values:
  out
    Which is: 9221120237041090560
  out_number
    Which is: 18446686899104907264
[  FAILED  ] TestWithParameters_BF_004/MyTest.TestFormula/1, where GetParam() = (18446690030672936960, 18446686899104907264) (0 ms)
[ RUN      ] TestWithParameters_BF_004/MyTest.TestFormula/2
/usr/ports/math/flexfloat/work/flexfloat-6db869087a12d763a94d53e9b0a9d52def270865/test/value_representation_half.cpp:66: Failure
Expected equality of these values:
  out
    Which is: 9221120237041090560
  out_number
    Which is: 18446686899104907264
[  FAILED  ] TestWithParameters_BF_004/MyTest.TestFormula/2, where GetParam() = (18446690031209807872, 18446686899104907264) (0 ms)

OS: FreeBSD 12.1
Compiler: gcc-9

flexfloat_get_bits() gives wrong results

flexfloat_get_bits() gives wrong results when the bit representation is a power of 2 and the flexfloat is denormalized (exp <= 0).

For example

flexfloat_t test;

ff_init(&test, {5, 10});
flexfloat_set_bits(&test, 8);
std::cout << flexfloat_get_bits(&test) << std::endl;

gives the output 18446744073709545472.

This is most likely due to the line else if(exp <= 0 && frac != 0) in

uint_t flexfloat_get_bits(flexfloat_t *a)
{
    int_fast16_t exp = flexfloat_exp(a);
    uint_t frac = flexfloat_frac(a);

    if(exp == INF_EXP) exp = flexfloat_inf_exp(a->desc);
    else if(exp <= 0 && frac != 0) {
        frac = flexfloat_denorm_frac(a, exp);
        exp = 0;
    }

    return ((uint_t)flexfloat_sign(a) << (a->desc.exp_bits + a->desc.frac_bits))
           + ((uint_t)exp << a->desc.frac_bits)
           + frac;
}

What is the && frac != 0 for? Without it, it seems to work (at least for my example).

compressed nan/inf representations used for new fp8? e4m3 e5m2

via https://dblalock.substack.com/p/2022-9-18-arxiv-roundup-reliable

FP8 Formats for Deep Learning
A group of NVIDIA, ARM, and Intel researchers got fp8 training working reliably, with only a tiny accuracy loss compared to fp16.

8-bit floating point (FP8) binary interchange format consisting of two encodings - E4M3 (4-bit exponent and 3-bit mantissa) and E5M2 (5-bit exponent and 2-bit mantissa). While E5M2 follows IEEE 754 conventions for representatio of special values, E4M3's dynamic range is extended by not representing infinities and having only one mantissa bit-pattern for NaNs. We demonstrate the efficacy of the FP8 format on a variety of image and language tasks, effectively matching the result quality achieved by 16-bit training sessions.

reducing the number of NaN/Inf encodings in fp1-4-3 down to just one bitstring

how much accuracy loss does this approach cause? They find that, across a huge array of models and tasks, the consistent answer is: not much—around 0-.3% accuracy/BLEU/perplexity:

NaN handling in tests makes too many assumptions

The tests partially assume that NaN bit-patterns emitted by FlexFloat are the same as on the host machine, although this property is implementation-defined.
Namely, one assumption made is expecting a qNaN with negative sign as the output of 0.0/0.0. While true on x86 hardware using SSE, this doesn't have to hold for other implementations and also doesn't hold for FlexFloat outputs.
FlexFloat currently outputs qNaN with positive sign and all payload bits cleared (e.g. 0x7fc00000 for binary32). Most hardware usually produces NaNs with cleared payload bits, but that is implementation defined, too.
#6 aligns the tests with the +qNaN behavior and removes some tests that make explicit assumptions about bit patterns generated by the host machine. However, many tests in test_value_representation_half still rely on exact bit patterns as NaN payloads.

It should be decided if NaN payloads are worth supporting or whether (the current) approach with a single canonical output NaN should be kept.

Project doesn't install anything

No sqrt, fabs?

Hi there,

I'm using FlexFloat with some numerical kernels that come from finite element calculations.

Mostly I can just replace double with flexfloat<11, 16> or whatever, and compile... this is great! I have a couple of annoyances, though. Firstly, sqrt and fabs don't seem to be supported by the flexfloat type. I.e. I have to manually add a cast to e.g. sqrt(a*b + c) to become sqrt(double(a*b + c)), and similarly with fabs. Am I doing something wrong, or are these operations not supported yet?

Secondly, a statement of the form double = double + flexfloat doesn't seem to work... I have to again add a manual cast double = double + double(flexfloat). Is this expected?