[RFC] More flexible floating-point type specification

Aperta
  • Qualcosa non va?
#185 7 commenti 0 reazioni 0 assegnatari Vedi su GitHub

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
35/100
Tipo di issue
Funzionalità
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
c, cpp
Ambito
backend-api-design

Direzione di ricerca

Inizia con l’enum kDLDataTypeCode e la definizione di DLDataType in include/dlpack/dlpack.h, poi leggi la discussione MLIR collegata e il commento all’issue #184 per il contesto sulla compatibilità. Le questioni aperte, in particolare float8_e4m3b11fnuz e i vincoli ABI, devono essere risolte prima che un’implementazione possa essere considerata completa.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

Motivation

There are a large number of floating-point types in DLPack, especially 4-bit and 8-bit variants. The structure to define new FP types for DLPack exchange currently requires modifications to DLPack itself, and this RFC aims to relax that limitation.

MLIR moved to a more flexible system in the beginning of last year (discussion, PR), and I feel we should follow in their footsteps.

@seberg commented in a different issue that a way forward without ABI breakage would be a requirement to do this short-term, and I agree.

Proposal

This RFC proposes a few things, that when taken together, allow one to specify many¹ floating point types.

  1. The introduction of two new enum values in the kDLDataTypeCode enum: kDLFlexibleFloat and kDLFlexibleComplex.
  2. That the DLDataType struct be turned into a (C-style) union. The existing layout would become the first variant of the struct, and the second variant is specified below.
typedef struct {
  /*!
   * \brief Type code of base types.
   * We keep it uint8_t instead of DLDataTypeCode for minimal memory
   * footprint, but the value should be one of DLDataTypeCode enum values.
   * */
  uint8_t code;
  /*!
   * \brief Number of bits minus one, common choices are 2, 4, 8, 16, 32, 64.
   * For complex, specify the number of bits for the components rather than the whole.
   */
  uint8_t bitsm1;
  /*!
   * \brief Number of mantissa bits.
   * Implies number of exponent bits are bits - 1 - mantissa in the common case.
   * mantissa = 0 specifies an exponent-only format (one example is float8_e8m0fnu)
   */
  uint8_t mantissa;
  /*!
   * \brief The flags associated with this FP type.
   * Beginning with the LSB:
   * Bit 0: Finite bit, often specified by f
   * Bit 1: NaN bit, often specified by n
   * Bit 2: (Signed) zero bit, often specified by z
   * Bit 3: Unsigned zero bit, often specified by uz
   * Bits 5-7: Reserved.
   */
  uint8_t flags;
  /*! \brief Specifies the number of lanes in the type, used for vector types.
   * The value should be raised to a power of two, i.e., a value of 5 means 32 lanes.
   */
  uint8_t p2lanes;
} DLDataTypeFloatingSpec;

This variant of the struct is only activated by the two enum values above. The existing enum and equivalents here would be considered aliases to each other, but implementations are not required to support the latter if they already support the former.

Open Questions

The float8_e4m3b11fnuz type is not covered by this proposal in its current form. I'm currently debating how best to address that. Options are:

  1. Leave it as out of scope/requiring its own enum value.
  2. Split p2lanes into two 4-bit fields, one for p2lanes and the other for bias.
  3. Use the reserved bits for bias instead.
  4. Use a combination to increase the bits available to bias.

¹ I would consider non IEEE-style types such as POSIT and TAKUM to be explicitly excluded from the scope of this proposal, perhaps to be addressed by future flags.

cc @seberg and @hpkfft as they showed interest.

Lingua principale
C++
Stelle
1.3k
Fork
168
Merge medio
1m
PR unite (30g)
2

Preparare l'ambiente

Questo progetto non fornisce container di sviluppo, Dockerfile né guida per i contributori, quindi l'ambiente è a tuo carico: parti dal suo README e consulta la nostra guida al primo contributo per i passaggi generali.

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di dmlc/dlpack

Tutte le issue di dmlc/dlpack

Issue simili

Altre issue su C++

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.