From dc77646577e9462e87634c38ae13eded78301189 Mon Sep 17 00:00:00 2001 From: Dan Gohman Date: Tue, 14 Jul 2015 08:03:43 -0700 Subject: Add a new page about the JIT/Optimization library concept. This also obviates the need for the floating point library function section. --- FAQ.md | 2 +- FutureFeatures.md | 52 +++++------------------------------ JITLibrary.md | 81 +++++++++++++++++++++++++++++++++++++++++++++++++++++++ 3 files changed, 88 insertions(+), 47 deletions(-) create mode 100644 JITLibrary.md diff --git a/FAQ.md b/FAQ.md index d5603ad..dfbc282 100644 --- a/FAQ.md +++ b/FAQ.md @@ -220,7 +220,7 @@ WebAssembly implementations run on the user side, so there is no opportunity for * Many of the important fast-math optimizations happen in the mid-level optimizer of a compiler, before WebAssembly code is emitted. For example, loop vectorization that depends on floating point reassociation can still be done at this level if the user applies the appropriate fast-math flags, so WebAssembly programs can still enjoy these benefits. As another example, compilers can replace floating point division with floating point multiplication by a reciprocal in WebAssembly programs just as they do for other platforms. - * Mid-level compiler optimizations may also be augmented by implementing them in a JIT library in WebAssembly. This would allow them to perform optimizations that benefit from having [information about the target](FeatureTest.md) and information about the source program semantics such as fast-math flags at the same time. For example, if SIMD types wider than 128-bit are added, it's expected that there would be feature tests allowing WebAssembly code to determine which SIMD types to use on a given platform. + * Mid-level compiler optimizations may also be augmented by implementing them in a [JIT library](JITLibrary.md) in WebAssembly. This would allow them to perform optimizations that benefit from having [information about the target](FeatureTest.md) and information about the source program semantics such as fast-math flags at the same time. For example, if SIMD types wider than 128-bit are added, it's expected that there would be feature tests allowing WebAssembly code to determine which SIMD types to use on a given platform. * When WebAssembly [adds an FMA operation](FutureFeatures.md#additional-floating-point-operations), folding multiply and add sequences into FMA operators will be possible. diff --git a/FutureFeatures.md b/FutureFeatures.md index 2caa720..6f7f5d3 100644 --- a/FutureFeatures.md +++ b/FutureFeatures.md @@ -171,7 +171,7 @@ include: [a proposal in the SIMD.js repository]: https://github.com/tc39/ecmascript_simd/issues/180 -## Platform-independent Just-in-Time compilation +## Platform-independent Just-in-Time (JIT) compilation WebAssembly is a new virtual ISA, and as such applications won't be able to simply reuse their existing JIT-compiler backends. Applications will instead @@ -195,6 +195,11 @@ should support: * Code unloading capabilities, especially in the context of code garbage collection and defragmentation. +WebAssembly's JIT interface would likely be fairly low-level. However, there +are use cases for higher-level functionality and optimization too. One avenue +for addressing these use cases is a +[JIT and Optimization library](JITLibrary.md). + ## Multiprocess support * `vfork`. @@ -287,51 +292,6 @@ techniques such as double-double arithmetic. If we standardize 128-bit floating point in WebAssembly, it will probably be standard IEEE-754 quadruple precision. -## Floating point library intrinsics - -These operations aren't needed for the MVP because they can be implemented in -WebAssembly code and linked into WebAssembly modules at small size cost (as is -traditionally done through C libraries such as libm). This approach: - -* Avoids a non-trivial specification burden for their semantics, precision, and - performance. -* Allows developers to make different application-specific tradeoffs of - precision/robustness versus performance, while still getting deterministic - results across implementations. -* Reduces the implementation burden for WebAssembly, since more than the few - math functions listed below may be needed by different developers. - -[Dynamic linking](FutureFeatures.md#dynamic-linking) will also allow caching of -libm, making this already low-cost sharing trivial. - -Adding these intrinsics would potentially allow for better high-level backend -optimization of these intrinsics that require builtin knowledge of their -semantics. WebAssembly may support these operations in the future if data shows -it would be useful. The rounding behavior of these operations would need -clarification. - - - * `float64.sin`: trigonometric sine - * `float64.cos`: trigonometric cosine - * `float64.tan`: trigonometric tangent - * `float64.asin`: trigonometric arcsine - * `float64.acos`: trigonometric arccosine - * `float64.atan`: trigonometric arctangent - * `float64.atan2`: trigonometric arctangent with two arguments - * `float64.exp`: exponentiate e - * `float64.ln`: natural logarithm - * `float64.pow`: exponentiate - * `float32.sin`: trigonometric sine - * `float32.cos`: trigonometric cosine - * `float32.tan`: trigonometric tangent - * `float32.asin`: trigonometric arcsine - * `float32.acos`: trigonometric arccosine - * `float32.atan`: trigonometric arctangent - * `float32.atan2`: trigonometric arctangent with two arguments - * `float32.exp`: exponentiate e - * `float32.ln`: natural logarithm - * `float32.pow`: exponentiate - ## Full IEEE-754 conformance WebAssembly floating point conforms IEEE-754 in most respects, but there are a diff --git a/JITLibrary.md b/JITLibrary.md new file mode 100644 index 0000000..ef94d69 --- /dev/null +++ b/JITLibrary.md @@ -0,0 +1,81 @@ +# JIT and Optimization Library + +WebAssembly's +[Just-in-Time compilation (JIT)](FutureFeatures.md#platform-independent-just-in-time-jit-compilation) +interface will likely be fairly low-level, exposing general-purpose primitives +rather than higher-level functionality. Still, there is a need for higher-level +functionality, and for greater flexibility than the WebAssembly spec can provide. +JIT and Optimization libraries that would run inside WebAssembly and provide +support and higher-level features would fit this need very well. + +Such libraries wouldn't be part of the WebAssembly spec itself, but the concept +is relevant to discuss here because features that we can expect to address in +libraries are features that we may not need to add to the spec. This strategy +can help keep the spec itself simple and reduce the surface area of features +required of every spec implementation. + +And, libraries are a good way to develop new features that we may eventually +want to add to the spec. They make it easy to iterate, experiment, and gain +real-world insight before freezing all the details in a spec. + +This raises the question of how we should decide which features belong in the +spec, and which belong in a library. Some of the fundamental advantages of +putting functionality in a library rather than in the spec and in implementations +themselves include: + + * A library can freely choose to offer greater degrees of undefined behavior, + implementation-defined behavior, unspecified behavior, and so on. This means + it can perform much more aggressive optimizations, including many that are + extremely common in optimizing compilers and might otherwise seem missing in + the WebAssembly spec itself: + * Constant folding, strength reduction, and code motion of math functions + such as `sin`, `cos`, `exp`, `log`, `pow`, and `atan2`. + * Performing aggressive expression simplifications that depend on assuming + that integer arithmetic doesn't overflow. + * Performing GVN with redundant load elimination, and other optimizations + based on aliasing rules that incur undefined behavior if they are violated. + * Vectorization that utilizes both floating point reassociation and + awareness of the underlying platform through + [feature testing](FeatureTest.md). + + * A library can support higher-level features, and features that are tailored + to certain applications, whereas the WebAssembly spec itself is limited to + general-purpose primitives. Possible examples of this are: + * A richer type system, which could include things like complex, rational, + arbitrary bitwidth integers, non-power-of-2 SIMD types, interval + arithmetic, etc. + * A higher-level type system, which could include basic polymorphism of + various kinds (either with true dynamism or with monomorphisation). + * Richer control flow constructs. + * A broader set of operations, such as string-handling operations, + data type serialization, testing facilities, and linear algebra + operations, all of which can benefit from being integrated at the + language level. + Since every feature required in the spec itself will need to be implemented + by all implementations, domain-specific features run the risk of making + people "pay for what they don't use". With features libraries, people need + only pay for the features they choose to use. + + * A library can evolve over time to meet the changing needs of higher-level + languages. In practice, compiler IRs such as LLVM IR evolve to add new + features, change existing features, and sometimes remove features, and these + kinds of changes are much harder to do in a spec. + +The library approach also means that applications using a particular version +of a library can get consistent behavior and performance, because of the +determinism of the underlying WebAssembly platform. + +A significant range of approaches are possible: + + * "Customized WebAssembly". This might involve a library whose input format + is conceptually WebAssembly but with some additional features. The library + could optimize and then lower those features leaving standard WebAssembly + to present to the underlying implementation. + + * "Bring Your Own Compiler" There's nothing stopping one from bundling + full-fledged AOT-style compilers that compile an independent source language + or IR into WebAssembly right there in WebAssembly itself. Obviously this + will involve tradeoffs in terms of download size and startup time, but it + would allow a unique degree of flexibility. + + * And many things in between. -- cgit v1.2.3 From fc93b347c35666ee5334e621a076fdbdd167127b Mon Sep 17 00:00:00 2001 From: Dan Gohman Date: Wed, 19 Aug 2015 15:45:43 -0700 Subject: Clarify that JIT libaries will facilitate experimentation. Particularly in the area of applications dynamically generating code, experimentation will allow us to determine which features are most appropriate. --- JITLibrary.md | 16 +++++++++++----- 1 file changed, 11 insertions(+), 5 deletions(-) diff --git a/JITLibrary.md b/JITLibrary.md index ef94d69..71167c5 100644 --- a/JITLibrary.md +++ b/JITLibrary.md @@ -5,8 +5,11 @@ WebAssembly's interface will likely be fairly low-level, exposing general-purpose primitives rather than higher-level functionality. Still, there is a need for higher-level functionality, and for greater flexibility than the WebAssembly spec can provide. -JIT and Optimization libraries that would run inside WebAssembly and provide -support and higher-level features would fit this need very well. +There is also a need for experimentation, particularly in the area of +applications wishing to dynamically generate new code, to determine which features +and interfaces are most appropriate. JIT and Optimization libraries that would run +inside WebAssembly and provide support and higher-level features would fit this +need very well. Such libraries wouldn't be part of the WebAssembly spec itself, but the concept is relevant to discuss here because features that we can expect to address in @@ -14,9 +17,12 @@ libraries are features that we may not need to add to the spec. This strategy can help keep the spec itself simple and reduce the surface area of features required of every spec implementation. -And, libraries are a good way to develop new features that we may eventually -want to add to the spec. They make it easy to iterate, experiment, and gain -real-world insight before freezing all the details in a spec. +And, libraries will facilitate light-weight experimentation with new features +that we may eventually want to add to WebAssembly itself. In a library layer, +we can quickly iterate, experiment, and gain real-world insight, before adding +features to the spec itself and freezing all the details. And as new features +are standardized, libraries will become the polyfills which will help those +features gain adoption. This raises the question of how we should decide which features belong in the spec, and which belong in a library. Some of the fundamental advantages of -- cgit v1.2.3