To: J3                                                     J3/20-118
From: Rich Bleikamp
Subject: BFLOAT16
Date: 2020-February-26

Reference: 19-221r1, 19-139r1

History:

  BFLOAT16 discussed at meeting 220: see 19-221r1.
  Results of Straw vote at m220:
    bfloat strawvote: Should we proceed?
    Y - N - U
    5 - 6 - 3

  Also see 19-139r1
  (REAL16 named constant added to iso_fortran_env module).

Discussion:
  IEEE 754-2019 describes a 16 bit floating point INTERCHANGE
  format that is not BFLOAT16.  And not a computation format.
  Note that some processors (DSP chips) do support 16 bit f.p.
  computations.

  We added REAL16 to ISO_FORTRAN_ENV, and it seems appropriate
  to reserve this named constant for IEEE 16 bit f.p.
  (larger mantissa and smaller exponent than BFLOAT16).
  Reserve may be too strong a word.

  BFLOAT16 is a "de-facto industry standard", more or less,
  that uses the 1st 16 bits of a 32 bit IEEE floating point
  type (loses the least significant 16 bits of the mantissa,
  so it has an 8 bit exponent, and 8 bits of precision).
  Vendors supporting BFLOAT16 in some language on some hardware
  include Intel, Nvidia, AMD, ARM, and Google.
  Most of these support  BFLOAT16 as a data format with limited
  support for computations (limited trig functions?  , ...).

  BFLOAT16 is of interest to some HPC applications where
  high performance is more important than a large mantissa.
  Machine Learning applications are often mentioned as a
  likely user of BFLOAT16.

Specs and Syntax:
  Add a new named constant to the ISO_FORTRAN_ENV module, named
  "BFLOAT16".  Similar to REAL32, REAL64, ..., its value is the kind
  type parameter of the 16 bit floating point data format that has an
  8 bit exponent, if any such thing exists for this processor.

Notes:
  The description of this new named constant would be added to
  16.10.2.25, where REAL16, REAL32, REAL64, and REAL128 are described.

  A description of BFLOAT16 could be added that gives some context.
  However, vendors probably don't need such guidance, and users don't
  read the Fortran standard.  No such context is provided for
  REAL32/64/...  Straw vote below.

  SELECTED_REAL_KIND could be used to determine the kind type parameter
  of a BFLOAT16 data type, but the intrinsic would return a different
  kind type parameter if BFLOAT16 is not available (probably a 32 bit
  f.p.  kind type parameter).

Alternatives to adding a new named constant (BFLOAT16).
  Use selected_real_kind:
  SELECTED_REAL_KIND(3,4) gives you REAL16 (IEEE 1754) data type, while
  SELECTED_REAL_KIND(2,37) gives you BFLOAT16.
  ASSUMING that those types exist, otherwise you likely get the kind
  type parameter for a 32 bit f.p. type.

  We could extend selected_real_kind with a new optional
  argument (size=) that would cause selected_real_kind to fail
  rather than return a larger data type kind type value.

Recommendation:
  JOR recommends that J3 does not proceed with adding any explicit
  support for BFLOAT16.

-----
If J3 plenary votes to proceed, then the following straw votes will
give direction to JOR.

Straw Votes:
  1) Should we proceed with BFLOAT16?
     a) Yes, as a named constant
     b) Yes, but not as a named constant
       (add size to selected_real_kind?)
     c) No
     d) Undecided

  2) should we describe how BFLOAT16 differs from REAL16, when both exist
     for a given processor?
     a) Yes
     b) No
     c) Undecided

  3) If straw vote (2) favors Yes, should we
     a) just describe it as a 16 bit f.p. format with an 8 bit exponent
     b) just describe it as applicable where a reduced precision/larger
        dynamic range 16 bit f.p. datatype is desired,  possibly
        mentioning Machine Learning or other applications
     c) undecided

  4) If straw vote (2) favors Yes, should the description of BFLOAT16 be
     a) in normative text
     b) in a NOTE
     c) undecided