dependabot[bot] opened a new pull request, #30222: URL: https://github.com/apache/beam/pull/30222
Bumps [github.com/tetratelabs/wazero](https://github.com/tetratelabs/wazero) from 1.5.0 to 1.6.0. <details> <summary>Release notes</summary> <p><em>Sourced from <a href="https://github.com/tetratelabs/wazero/releases";>github.com/tetratelabs/wazero's releases</a>.</em></p> <blockquote> <h2>v1.6.0</h2> <p>Hey, gophers! Do you know what time it is? It is that time of the year again! That time when we all gather together to share our time with friends and family to celebrate <strong>ANOTHER AWESOME WAZERO RELEASE</strong>!</p> <p>Notably, this release includes the first public experimental release of the <strong>long-awaited, highly-requested multi-pass optimizing compiler</strong>! Keep reading for more details!</p> <p>A huge thanks to all the contributors, old and new, and always remember that all the developers hang out at the [Gophers Slack][gophers] in the #wazero channel; and if you haven’t already you can <a href="https://github.com/tetratelabs/wazero/stargazers";>star</a> our repo. You know, Santa is making a list, and checking it twice.</p> <p>It’s been a while since v1.5.0, but we promise <strong>v1.6.0</strong> was <strong>worth the wait</strong>! Fun facts about v1.6.0:</p> <ul> <li>This is the best release since the last one.</li> <li>This release is 100% richer in holiday cheer. ❄️🎄</li> <li>Mulled wine is a fantastic developer productivity boost.</li> </ul> <h2>The Optimizing Compiler</h2> <p>Jokes aside, we have a lot to cheer about! The <strong>lion share</strong> of this release is obviously our <strong>brand new optimizing compiler</strong> (codename “wazevo”) now available as an <strong>experimental feature for arm64</strong> (<a href="https://redirect.github.com/tetratelabs/wazero/issues/1496";>#1496</a>)!</p> <p><a href="https://github.com/mathetake";><code>@mathetake</code></a> led the design and implementation. Work started this summer, and it has evolved in a few iterations over the last months. Initial focus has been on general abstract infrastructure and support to the <strong>arm64</strong> instruction set as our first compilation target. <a href="https://github.com/evacchi";><code>@evacchi</code></a> contributed to the arm64 backend with special focus on the SIMD instructions, and <a href="https://github.com/achille-roussel";><code>@achille-roussel</code></a> helped improve the initial register allocator (this was then further evolved and eventually overhauled again by <a href="https://github.com/mathetake";><code>@mathetake</code></a>). <a href="https://github.com/ncruces";><code>@ncruces</code></a> contributed with suggestions and testing.</p> <p>We held off a few releases to polish this new compiler and gain more confidence in the implementation. In this first public release, the optimizing compiler is only available for <strong>arm64</strong>. The journey to supporting <strong><em>amd64</em></strong> is set to begin soon with <a href="https://github.com/evacchi";><code>@evacchi</code></a> leading the effort.</p> <p>The new compiler has been, as usual, <strong>extensively tested against</strong> the Wasm spec, our own unit tests, and against the standard libraries of TinyGo, Go and Zig; and of course it has also been hardened through hours-long fuzzing.</p> <p>You can enable the optimizing compiler by replacing <code>wazero.NewRuntimeConfigCompiler()</code> or <code>wazero.NewRuntimeConfig()</code> with the new experimental API as follows:</p> <pre lang="diff"><code>- c := wazero.NewRuntimeConfigCompiler() + c := opt.NewRuntimeConfigOptimizingCompiler() - c := wazero.NewRuntimeConfig() + c := opt.NewRuntimeConfigOptimizingCompiler() </code></pre> <p>The CLI is now also exposing an experimental flag <code>-optimizing-compiler</code>:</p> <pre><code>wazero run -optimizing-compiler myapp.wasm </code></pre> <p>The optimizing compiler is an <strong>experimental feature</strong> so <strong>we welcome your input</strong>. It is also a <strong>work in progress</strong>: we implemented only a few optimization passes, guiding our choices through testing and benchmarking.</p> <p>It is worth noting that <strong>WebAssembly is an interesting beast</strong>: since it is a compilation target, most compilers generate pre-optimized output; therefore, some traditional optimization passes may surprisingly only add build-time overhead and produce no observable improvement. However, our work there is far from being done: <strong>more optimization passes can be added</strong>; we invite you to do your experiments and bring your own suggestions. For instance, among others, we currently implement forms of <strong>dead-code elimination</strong>, and <strong>bounds-checking eliminations</strong>.</p> <p>In your experiments, you should also expect the <strong><code>CompileModule</code> phase to take a while longer than the old compiler</strong>: the difference may be noticeable with large modules; but you can still <strong>cache the result</strong>, so you can pay this cost only once. The <strong>good news</strong> is that, in our tests, the <strong>run-time should always visibly improve.</strong> Interestingly enough, there are also <strong>some cases where <em>both</em> compile-time and run-time have improved</strong>: this might be the case when the input module is not pre-optimized, and the dead-code elimination procedures kick in.</p> <p>For instance, the <strong>Zig standard library</strong> is about <strong>2x quicker</strong> to compile and <strong>4x faster</strong> to run than the old compiler. However, a pre-optimized test binary (<em>e.g.</em> pre-processed [using Binaryen’s <code>wasm-opt</code>][wasm-opt]) will be much faster to build on the old compiler, but the new compiler will still produce <em>2x</em> faster code. This is fully expected because <strong>the old compiler does a straightforward translation from input Wasm to native code</strong>: therefore, processing time tends to be low; but if the input is large, the generated output will be large. The new compiler is smarter, in that it is able to drop all the irrelevant code sections; in fact, processing time is about the same on both an optimized and unoptimized binary.</p> <p>The bottom line is: if you control the Wasm binary, run it through [<code>wasm-opt</code>][wasm-opt] and compare the result for your workload!</p> <h2>Deprecations</h2> <!-- raw HTML omitted --> </blockquote> <p>... (truncated)</p> </details> <details> <summary>Commits</summary> <ul> <li><a href="https://github.com/tetratelabs/wazero/commit/27624049dc46c307f0fc6c4771b7df0609c63ff1";><code>2762404</code></a> wazevo(frontend): faster non-imported global access (<a href="https://redirect.github.com/tetratelabs/wazero/issues/1889";>#1889</a>)</li> <li><a href="https://github.com/tetratelabs/wazero/commit/68729c0a8e2e2dfd8f9f8eec98f353709b96866c";><code>68729c0</code></a> Correctly exit Stdlib tests on failure (<a href="https://redirect.github.com/tetratelabs/wazero/issues/1888";>#1888</a>)</li> <li><a href="https://github.com/tetratelabs/wazero/commit/866d5558742e17ea100d8aa0ad1cb6753f9c1889";><code>866d555</code></a> wazevo(arm64): optimize out unnecessary UExtend (<a href="https://redirect.github.com/tetratelabs/wazero/issues/1886";>#1886</a>)</li> <li><a href="https://github.com/tetratelabs/wazero/commit/cd143e849f7a78b9588d49f6336d94149f42af2b";><code>cd143e8</code></a> Makes Std lib tests benchstat compatible (<a href="https://redirect.github.com/tetratelabs/wazero/issues/1887";>#1887</a>)</li> <li><a href="https://github.com/tetratelabs/wazero/commit/6fdb893c65531b594fa1517bbadf9775e0294070";><code>6fdb893</code></a> Fixes std lib cases actually benchmarkable (<a href="https://redirect.github.com/tetratelabs/wazero/issues/1885";>#1885</a>)</li> <li><a href="https://github.com/tetratelabs/wazero/commit/8c71d4d0fe7de6b0df09d989af9d325dce4a1605";><code>8c71d4d</code></a> Flattens std lib test cases (<a href="https://redirect.github.com/tetratelabs/wazero/issues/1884";>#1884</a>)</li> <li><a href="https://github.com/tetratelabs/wazero/commit/823d573fd2fcd3aac16ec6322a55fe75a1bbb7c6";><code>823d573</code></a> bench: add stdlib benchmark old vs new compiler (<a href="https://redirect.github.com/tetratelabs/wazero/issues/1878";>#1878</a>)</li> <li><a href="https://github.com/tetratelabs/wazero/commit/fa2b2fc090a78a585be6594a28ca24260aff210c";><code>fa2b2fc</code></a> wazevo(frontend): simple bounds check elimination on mem access (<a href="https://redirect.github.com/tetratelabs/wazero/issues/1883";>#1883</a>)</li> <li><a href="https://github.com/tetratelabs/wazero/commit/d26cbadd46f75e4d38fc5dab51937e16fc619544";><code>d26cbad</code></a> wazevo(arm64): adds missing PerfMapEnabled branch (<a href="https://redirect.github.com/tetratelabs/wazero/issues/1882";>#1882</a>)</li> <li><a href="https://github.com/tetratelabs/wazero/commit/1a067a5e28b82640d8a6bbc6b3689127743ba195";><code>1a067a5</code></a> wazevo(arm64): lower constant bitwise ops with bitmask immeidates (<a href="https://redirect.github.com/tetratelabs/wazero/issues/1881";>#1881</a>)</li> <li>Additional commits viewable in <a href="https://github.com/tetratelabs/wazero/compare/v1.5.0...v1.6.0";>compare view</a></li> </ul> </details> <br /> [](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores) Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting `@dependabot rebase`. [//]: # (dependabot-automerge-start) [//]: # (dependabot-automerge-end) --- <details> <summary>Dependabot commands and options</summary> <br /> You can trigger Dependabot actions by commenting on this PR: - `@dependabot rebase` will rebase this PR - `@dependabot recreate` will recreate this PR, overwriting any edits that have been made to it - `@dependabot merge` will merge this PR after your CI passes on it - `@dependabot squash and merge` will squash and merge this PR after your CI passes on it - `@dependabot cancel merge` will cancel a previously requested merge and block automerging - `@dependabot reopen` will reopen this PR if it is closed - `@dependabot close` will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually - `@dependabot show <dependency name> ignore conditions` will show all of the ignore conditions of the specified dependency - `@dependabot ignore this major version` will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this minor version` will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this dependency` will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself) </details> -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
