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. --- JITLibrary.md | 81 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 81 insertions(+) create mode 100644 JITLibrary.md (limited to 'JITLibrary.md') 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(-) (limited to 'JITLibrary.md') 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