Design: Proposition : indicateurs de niveau de conformité Fp IEEE pour Wasm (FP-Fast-Math pour Wasm Scalar & SIMD)
Les compilateurs natifs comme gcc, clang, msvc permettent aux développeurs de définir les niveaux de conformité fp IEEE via des pragmas ou des indicateurs de compilation comme /fp(strict-fast), ffast-math, -ffp-contract, etc. Ces indicateurs sont bénéfiques pour un large gamme d'applications (par exemple ML-convolutions, DSP, moteurs graphiques/physiques de faible précision..) où les développeurs préfèrent le compromis de la précision portable en faveur des performances.
Les gains de performances peuvent être importants en fonction des paramètres spécifiques et des compilateurs utilisés. Ces conseils/préférences de développeur permettent aux compilateurs d'effectuer en toute sécurité plus d'optimisations mathématiques Fp, une meilleure sélection d'instructions (fusion/fma), des restrictions de plage de valeurs et des validations assouplies.
Actuellement, ces indicateurs, lorsqu'ils sont spécifiés par les développeurs pour Wasm, sont consommés par la chaîne d'outils de développement et ils peuvent en honorer quelques-uns en fonction de l'outil spécifique utilisé (par exemple https://github.com/WebAssembly/binaryen/pull/3155). Ces informations de préférences seront supprimées et ne sont pas disponibles/visibles pour les environnements d'exécution s'ils souhaitent les utiliser.
Les environnements d'exécution Wasm peuvent bénéficier des moyens d'accéder à ces indicateurs/indices de développeur pour prendre leurs propres décisions sur l'optimisation et la sélection d'instructions lorsque cela est sûr. Cela sera particulièrement utile pour effectuer des optimisations d'exécution supplémentaires, en particulier dans les compilateurs wasm AOT. Cela permet également de résoudre quelques-uns des problèmes de performances connus dans le codegen FP Wasm SIMD comme l'arrondi, min/max, etc. Un niveau élevé, cela permettra aux runtimes de ne pas dépendre des outils de développement pour certaines optimisations FP et supprime un bloqueur pour Wasm pour suivre de plus près les performances natives.
Il existe un précédent de JVM 1.2 assoupissant la conformité IEEE comme mode par défaut et introduisant le modificateur 'strictfp' pour assurer la portabilité dans une granularité classe/interface/méthode. Il est possible d'explorer une approche plus rétrocompatible pour Wasm.
Je voudrais proposer un mécanisme pour coder les drapeaux de conformité fp IEEE dans le binaire Wasm à consommer par les moteurs d'exécution. Comme c'est le cas dans les langues natives, les drapeaux eux-mêmes peuvent être traités comme facultatifs et leur utilisation peut être un choix des runtimes. L'impact se manifestera par des performances améliorées, une sémantique cohérente sur une plate-forme donnée et une portabilité moindre de la plate-forme. Le mécanisme proposé permettra de marquer sans ambiguïté des sections de code dans un binaire Wasm avec ces préférences/indices à la granularité d'un bloc d'instructions.
La conception peut être aplanie en détail au fur et à mesure que nous procédons. Une option consiste à introduire une nouvelle section personnalisée avec des entrées marquant les préférences et les décalages de segments de code et une autre option consiste à introduire une nouvelle instruction pour marquer les segments de code avec ces préférences de développeur comme dans JVM. Les indicateurs spécifiques à prendre en charge peuvent être discutés et incorporés au fur et à mesure (par exemple -fp-finate-math-only, -fp-no-signed-zeros..)
Ce mécanisme complétera les discussions pour ajouter des instructions d'approximation Scalar / Vector FMA et FP aux spécifications Wasm et/ou SIMD.
Ce problème est de suivre l'intérêt pour ce sujet et d'en discuter dans la synchronisation CG.
arunetm
Tous les 7 commentaires
Étant donné que la rigueur des opérations fp affecte la sémantique d'un programme, je m'attendrais à ce que le meilleur moyen de rendre une sémantique plus permissive possible soit d'introduire de nouvelles instructions plutôt qu'une section personnalisée ou une construction de bloc. Nous avons déjà les mécanismes de spécification nécessaires pour gérer le non-déterminisme flottant en raison de nos règles de propagation NaN, donc je pense qu'il serait simple d'introduire de nouvelles instructions à virgule flottante qui permettent plus de résultats possibles.
tlively
le 12 janv. 2021
Comme contexte supplémentaire, la JVM, pour sa part, envisage de supprimer strictfp et de ne supporter que la sémantique stricte.
sunfishcode
le 12 janv. 2021
le meilleur moyen de rendre possible une sémantique plus permissive serait d'introduire de nouvelles instructions plutôt qu'une section personnalisée ou une construction de bloc.
L'introduction de nouvelles instructions est utile, mais elle ne s'adaptera pas trop bien et ne supprimera pas complètement la dépendance à la chaîne d'outils. Les instructions avec un bon support de plate-forme comme fma, réciproque, etc. sont de bons candidats pour l'ajout de nouvelles instructions. Il existe une variété considérable
-fassociative-math
-ffast-math
-fno-honor-nans
-ffinate-math-only
-fdenormal-fp-math
-fno-strict-float-cast-overflow
-fno-math-errno
-fno-trapping-math
...
La plupart d'entre eux sont des astuces pour permettre des optimisations fp plus agressives, levant les restrictions sur les transformations algébriques, les nan, les zéros signés, les pièges, les arrondis, etc. Exprimer tous les drapeaux utiles en tant que nouvelles instructions n'est pas l'idéal imo.
Comme contexte supplémentaire, la JVM, pour sa part, envisage de supprimer strictfp et de ne supporter que la sémantique stricte.
Merci @sunfishcode pour ce contexte ajouté ! Je ne connaissais pas cette nouvelle mise à jour et il semble que la motivation soit de consolider les variantes de la bibliothèque mathématique. À y regarder de plus près, Java strict-fp semble être un peu plus spécialisé et n'est pas une bonne représentation de la gamme de points de contrôle offerts par gcc/clang. Les drapeaux -ffast-math et les drapeaux associés semblent être assez populaires dans les dépôts natifs à partir d'une recherche rapide sur github. Je prévois d'étudier les utilisations des drapeaux ci-dessus et les pargmas associés
arunetm
le 12 janv. 2021
Les projets typiques qui utilisent -ffast-math de gcc/clang compilent en code natif. Les développeurs d'applications qui les utilisent testent généralement toutes les variantes de code natif qu'ils créent eux-mêmes. Et puisque tous les ISA matériels populaires ont un comportement à virgule flottante entièrement déterministe, une fois que les développeurs ont testé ces variantes, ils peuvent être à peu près sûrs que le comportement ne changera pas pour leurs utilisateurs. Actuellement, la virgule flottante de WebAssembly fonctionne également de cette façon ; il est entièrement déterministe, tout comme les ISA matériels, donc les hypothèses de longue date des développeurs sur la possibilité d'ajouter -ffast-math et de tester que cela "fonctionne pour eux" sont confirmées.
Un indicateur -ffast-math au niveau WebAssembly signifierait que WebAssembly ne ressemble plus à un ISA matériel à cet égard, et ne confirme plus ces hypothèses. Les développeurs testeraient le binaire qu'ils produisaient, mais lors de l'expédition de wasw à leurs utilisateurs, ces derniers devraient s'attendre à pouvoir l'exécuter sur différents matériels ou différents moteurs. Avec des indicateurs de type mathématique rapide au niveau de WebAssembly, WebAssembly ne se comporterait pas comme un ISA et les utilisateurs pourraient voir des résultats en virgule flottante différents de ceux avec lesquels le développeur a testé.
Il convient également de souligner que les projets utilisant ces indicateurs ne manquent pas lors de la compilation vers WebAssembly aujourd'hui. Par exemple, la plupart des optimisations activées par -fassociative-math sont des optimisations orientées boucle que LLVM est capable de faire avant de produire WebAssembly.
sunfishcode
le 21 janv. 2021
Oui, toutes les décisions qui affectent la précision/le comportement du flotteur doivent être intégrées dans le module Wasm par les outils. De nouvelles instructions peuvent être ajoutées pour les comportements qui ne peuvent pas être exprimés avec les actuels.
aardappel
le 21 janv. 2021
Nous avons eu une discussion sur ce sujet lors de la dernière réunion du CG avec l'ajout de nouvelles instructions comme moyen alternatif à l'objectif. Il semble y avoir un intérêt général à résoudre ce problème par cette dernière direction. Je n'ai pas d'objections si les attentes des développeurs concernant les gains de performances peuvent être confirmées par des optimisations de la chaîne d'outils et l'introduction de variantes d'instructions manquantes. Dans ce cas, il n'est pas nécessaire de justifier la propagation de ces indicateurs à l'environnement d'exécution, ce qui compromet le niveau d'abstraction de Wasm. Il sera bon de comprendre les instructions des variantes sémantiques qui sont nécessaires pour atteindre cet objectif. Nous avons quelques nouvelles instructions identifiées dans le contexte de SIMD qui devront peut-être être étendues pour correspondre aux instructions dont les outils ont besoin pour exprimer pleinement les indicateurs mathématiques rapides. Continuera à chercher dans cette direction.
Merci pour les commentaires.
arunetm
le 22 janv. 2021
Contenu utilisé pour la discussion CG. Wasm ffast-math.pptx
arunetm
le 1 mars 2021
Questions connexes
spidoche
·
4Commentaires
cretz
·
5Commentaires
aaabbbcccddd00001111
·
3Commentaires
chicoxyzzy
·
5Commentaires
Thaina
·
8Commentaires
Commentaire le plus utile
Les projets typiques qui utilisent -ffast-math de gcc/clang compilent en code natif. Les développeurs d'applications qui les utilisent testent généralement toutes les variantes de code natif qu'ils créent eux-mêmes. Et puisque tous les ISA matériels populaires ont un comportement à virgule flottante entièrement déterministe, une fois que les développeurs ont testé ces variantes, ils peuvent être à peu près sûrs que le comportement ne changera pas pour leurs utilisateurs. Actuellement, la virgule flottante de WebAssembly fonctionne également de cette façon ; il est entièrement déterministe, tout comme les ISA matériels, donc les hypothèses de longue date des développeurs sur la possibilité d'ajouter -ffast-math et de tester que cela "fonctionne pour eux" sont confirmées.
Un indicateur -ffast-math au niveau WebAssembly signifierait que WebAssembly ne ressemble plus à un ISA matériel à cet égard, et ne confirme plus ces hypothèses. Les développeurs testeraient le binaire qu'ils produisaient, mais lors de l'expédition de wasw à leurs utilisateurs, ces derniers devraient s'attendre à pouvoir l'exécuter sur différents matériels ou différents moteurs. Avec des indicateurs de type mathématique rapide au niveau de WebAssembly, WebAssembly ne se comporterait pas comme un ISA et les utilisateurs pourraient voir des résultats en virgule flottante différents de ceux avec lesquels le développeur a testé.
Il convient également de souligner que les projets utilisant ces indicateurs ne manquent pas lors de la compilation vers WebAssembly aujourd'hui. Par exemple, la plupart des optimisations activées par -fassociative-math sont des optimisations orientées boucle que LLVM est capable de faire avant de produire WebAssembly.