I've also only really tested wazero. I can't know for sure that this is a straight improvement for other runtimes and architectures.

For instance, the code delays using wasm_i8x16_bitmask as much as possible, because on Aarch64 it can be slower than not using SIMD at all, whereas it's plenty fast on x86-64.

C calling conventions are already the standard for FFI in native code, and that means dropping down to what can be expressed in C if you want to cross that boundary.

If there's interest, the set of implemented functions can definitely be extended.

To answer your question, it needs a libc because you're including stdlib.h, and exporting and allocator (even if you're not otherwise using it). You need a libc for malloc.

This is generally a good idea, if you need to send anything beyond numbers across the API (e.g. you need an allocator if you want to send strings as pointers).

I never used WIT, so I have no idea if this a requirement for WIT.

It's generally used for techniques that apply SIMD principles within general-purpose registers and instructions.

Assume you've loaded a 64-bit register (a uint64_t) with 8 bytes (unsigned char) of data. Can you answer the question “is any of these 8 bytes zero (the NUL terminator)?”

If you find a cheap way to do it, you can make strlen go faster by consuming 8 bytes at a time.

Et voilà:

   #define ONES ((uint64_t)-1/UCHAR_MAX)
   #define HIGHS (ONES \* (UCHAR_MAX/2+1))
   #define HASZERO(x) ((x)-ONES & ~(x) & HIGHS)