What exactly is WasmAllocator?

chung-leong · June 18, 2024, 9:07pm

The documentation doesn’t really say a whole lot:

This is intended to be merged into GeneralPurposeAllocator at some point.

Is it an allocator that for some reason works better in WASM than the GPA?

dimdin · June 18, 2024, 9:45pm

The description is in std.heap.wasm_allocator

This allocator is fast, small, and specific to WebAssembly. In the future, this will be the implementation automatically selected by GeneralPurposeAllocator when compiling in ReleaseSmall mode for wasm32 and wasm64 architectures. Until then, it is available here to play with.

andrewrk · June 19, 2024, 3:35am

It’s past time to make that foreshadowed change - the compiler has been using this allocator when building from source for 1.5 years now, autodocs uses it since my rewrite, and I’ve been using it in a personal project. It’s tried and true at this point.

console_buche · March 6, 2025, 10:29am

I second that Andrew.

Been using this wasm allocator in my current Zig/Wasm project, works great whereas the standard gpa allocator throws warnings and evetually assertion fails in some cases.

Auto selection refactor sounds neat, although it’s pretty nice to actually be able to pick that allocator manually. Fits the no hidden flow/stuff/make your own allocator Zig vibe.

So would be great to either merge or remove the “in the future” comment altogether yeah

floooh · March 7, 2025, 8:08am

…just as a side note, in my home computer emulator project the ReleaseSmall mode is massively slower than both ReleaseFast and ReleaseSafe (about half the performance of both Fast and Safe).

When I checked the compiler output, this is because the compiler was aggressively outlining identical code snippets from a big switch-based CPU instruction decoder into function calls, and this totally destroyed performance.

E.g.: I’d still want to be able to use a small allocator on WASM even when not compiling with ReleaseSmall In my code, allocator performance doesn’t matter (since I allocate only very infrequently, and mostly at startup), but code size does.

Luke · March 7, 2025, 2:02pm

I guess even if gpa can do some smart or not so smart choice, you can always override that choice by actually using a WasmAllocator directly.

squeek502 · March 7, 2025, 5:38pm

Potentially helpful in the future:

github.com/ziglang/zig

replace @setRuntimeSafety with @optimizeFor

opened 02:29AM - 03 May 18 UTC

andrewrk

proposal accepted

> Communicate intent precisely. Right now you can use `@setRuntimeSafety(fals…e)` in Debug and ReleaseSafe modes to allow the optimizer to speed up particular blocks of code. This would make sense to do in a well tested high performance crypto algorithm for example. Or in general the bottlenecks of your library or program. So the pattern here is that the build mode specifies the default, and you can override it at a per-block (or function) level. Here's a table of the parameters and the defaults that the build modes set: | Parameter | Debug | ReleaseFast | ReleaseSafe | ReleaseSmall | |-------------------------------------------------------------------|-------|-------------|-------------|--------------| | LLVM Optimizations - improve speed, harm debugging & compile time | | -O3 | -O3 | -Os | | Runtime Safety Checks - harm speed, harm size, improve debugging | On | | On | | With `@setRuntimeSafety` we can make a block of code adhere to the principles of Debug even in a ReleaseFast build, and vice versa. ...to some extent - it does not affect optimizations. But it could! LLVM supports choosing `-O3`, `-Os`, or `-O0` at least at the function level. You can probably guess what I'm leading up to here. Really instead of specifically asking to turn off safety, what we really want to communicate to the compiler is what we want to optimize for. `@optimizeFor(comptime mode: BuildMode)` Where `BuildMode` is already defined as `@import("builtin").BuildMode`: ```zig pub const Mode = enum { Debug, ReleaseSafe, ReleaseFast, ReleaseSmall, }; ``` And then the other issue we need to solve here is that the same intent should be communicable for types. Zig reserves the right to order fields and insert padding and such for structs, and therefore we should also allow the programmer to tell Zig what to optimize for. For example Debug might randomly order fields to make sure one does not accidentally depend on field order. ReleaseFast might arrange fields in an order most likely to have better cache performance. ReleaseSmall might sort fields by descending alignment to minimize padding. One little tidbit: `ReleaseSmall` is about generated binary size, not runtime memory size. So there is a slight disconnect here. But "small" is definitely something you would potentially want to optimize for in a struct, union, or enum. We can think about how to name the release modes and the optimization targets more coherently.