Discussion :

[dourouc05]

L'entraînement de réseaux neuronaux et leur utilisation pour de l'inférence requiert d'énormes quantités de calculs en nombres à virgule flottante. Cependant, les formats actuels pour stocker ces nombres se focalisent sur la précision : pour des réseaux neuronaux, cette précision n'est pas aussi nécessaire que pour la simulation de l'écoulement de l'air autour d'une aile d'avion, par exemple. C'est pourquoi Google a proposé le format bfloat16 (brain floating point) en remplacement de la norme IEEE 754 (la plus utilisée) pour ces applications spécifiques, avec une première implémentation dans ses TPU de troisième génération.

Depuis lors, une bonne partie de l'industrie des semi-conducteurs se lance à la suite de Google : Intel ajoutera une implémentation de bloat16 dans ses Xeon Cooper Lake et dans ses processeurs orientés réseaux neuronaux Nervana Spring Crest ; WAVE Computing fait de même dans ses DPU et Flex-Logix dans ses codes pour FPGA.

Techniquement, bfloat16 utilise seize bits pour représenter un nombre à virgule flottante, autant qu'un nombre en demi-précision selon la norme IEEE 754 (float16). Tous ces formats utilisent une forme de notation scientifique pour encoder les nombres : un bit pour le signe, quelques bits pour l'exposant (pour stocker un ordre de grandeur), le reste pour la mantisse (pour les détails sur le nombre), de telle sorte que le nombre puisse s'écrire "signe x mantisse x (2 ^ exposant). Cependant, alors qu'un float16 utilise une mantisse de dix bits (donc à peine cinq pour l'exposant), bfloat16 lui alloue à peine sept bits, ce qui laisse huit bits pour l'exposant. Par conséquent, avec un float16, on peut stocker des nombres jusque 65 504 : pour un blofat16, on peut monter jusque 3 x 10^38, à peu près autant qu'un float32. L'énorme différence est le manque de précision pour un bfloat16, ce qui pose très peu de problèmes pour un réseau neuronal, mais l'avantage est de traiter moins de bits (ce qui permet d'accroître la performance).

ARM proposera très bientôt une implémentation de ce format dans son architecture ARM-V8-A (qui inclut les extensions vectorielles SVE et les architectures trente-deux bits AArch32 Neon et soixante-quatre bits AArch64 Neon). Celle-ci se basera sur quatre instructions : BFDOT pour le produit scalaire entre deux vecteurs de deux bfloat16 chacun, BFMMLA pour un produit de deux matrices (2x4 et 4x2) en bfloat16, BFMLAL pour un produit entre deux bfloat16, BFCVT pour la conversion avec float32. Ces instructions sont vraiment prévues pour des réseaux neuronaux, pas pour des calculs plus génériques, même si des scientifiques les envisagent pour accélérer certaines parties de leurs codes, les moins sensibles au manque de précision.

Le format bfloat16 pose cependant un certain nombre de questions. La norme IEEE 754 a pu s'imposer grâce à sa définition rigoureuse du résultat de toutes les opérations : tous les processeurs ne donnent pas forcément les mêmes résultats pour les mêmes opérations (puisque leur ordre est laissé libre au concepteur du processeur), mais les différences sont bornées par la norme (on parle de "bruit d'arrondi"). Au contraire, pour bfloat16, rien n'est vraiment normalisé : on n'a aucune certitude que le résultat d'un même calcul sur deux processeurs différents sera identique ou même proche.

Image : WikiChip.
Source : The Next Platform.

[macos]

ayant par le passé déjà travailler avec du flottant, je me pose la question de la pertinence du float16 ou bfloat16, j explique:
-quelques soit l'architecture, les erreurs d'arrondies lors de calcul s'amplifient et s'additionnent
-une limitation, c'est qu'il est possible de réaliser des calcules, mais les algorithmes et l'ensemble ne doivent pas remonter une erreur et imprécision du au calcul.

certes bflot16, en utilisant des données représenter en probabilité est sans doute bien supérieur lors de calcule proche de la valeur unitaire (voir représentation de 1.0 et 1.0001 en flottant)

c'est pratique pour de petit algo, par contre des algorithmes compliquées ou nécessitant des données ( et matrices associées) vont entrainer d'important calcul répétitifs ou différents et risque de limiter le résultat en considérant l'ensemble des calcul

un exemple, si 5 algorithmes ramène une erreur de plus de 1E-4, les datas, les valeurs ne seront pas précisent et sont entaché d'erreur: algo peut diverger dans certains cas, voir désagréger la data, et implicitement le modèle

clairement float32 est pour moi le minimum. généralement, l erreur remonte, mais pas un niveau de la data, la dynamique est suffisante

[ijk-ref]

Tu loupes complètement l'essentiel de l'article. Ce format n'est PAS fait pour tes calculs dans tes algorithmes "classiques" mais pour des réseaux de neurones.

Tu penses que tous algorithmes se résument à une chaine de nombres. Si l'un des nombres est imparfait (trop entaché d'erreur) la chaine se rompt.

Dans un algo de réseau de neurones, il faut plutôt voir cela comme des nombres se soutenant et se corrigeant mutuellement.

Il serait donc plus juste que tu vois un réseau de 1024 neurones en float16 comme un algo travaillant en float16384

[macos]

non je ne loupe pas du tout l'article: le format est dédié aux réseau neuronique

C'est un problème récurrent quelque soit l'implémentation hardware:
algo vierge si la précision remonte, tu n 'ais jamais travailler avec des flottant

Peux tu alors me dire son ton modèle est cohérent, et comment se comporte t il ?
indépendamment de ton écart type, ton modèle dérive......


?????
Dans un algo de réseau de neurones, il faut plutôt voir cela comme des nombres se soutenant et se corrigeant mutuellement.

il s'agit d'assurer au global une erreur maitrise et pas propager. dans le cas contraire ton modèle ne vaut rien du tout:
il diverge car tu réintroduit des erreurs, rien ne vient se soutenir et se corriger mutuellement.

tu n as jamais travailler sur les flottants,

J’indiquait que si les algorithmes étaient compliqué , le risque sur les erreurs se cumulant, cela limite l'algorithme au sens générale

je peux meme te préciser que dans certain cas, la maitrise de l'erreur et sa gestion à un impact direct sur ton système.....

tu n'as jamais mis au point des algorithmes flottant !!!!!