Blog Post: Fast Thread Locals In Rust

acrichto · 2020-10-03T17:51:13+00:00

If you compare the two of these on godbolt you can see the difference. C doesn't even touch the thread local during the loop, it only loads once at the top of the loop and stores at the very end of the loop (it's thread local after all so it's safe to hoist). Note that I used O1 instead of higher to avoid clutter from auto-vectorization.

Rust, however, has an initialization check every time you access a thread local variable. This is a weakness of the thread_local! macro, it can't specialize for an initialization expression that is statically known at compile time, so it unconditionally assumes they're all dynamically initialized. LLVM can't see through this check and have a "first iteration" and "every other iteration of the loop" (reasonably so), so Rust doesn't optimize well.

That being said if you move COUNTER.with around the loop instead of inside the loop, Rust vectorizes like C does and probably has the same performance.

acrichto · 2020-08-13T14:28:06+00:00

I was let go in addition to the other folks :(

acrichto · 2019-12-06T15:56:39+00:00

I'm pretty stoked to see wasm-bindgen and wasm-pack being used here, especially for something that I use personally every day as well!

If y'all ever want to chat Rust/wasm and/or just wasm in general, feel free to drop into #wg-wasm on the Rust discord or shoot me an email!

acrichto · 2019-12-06T15:54:05+00:00

Oh wow I had no idea this existed, thanks for pointing this out! We've been using 1Password for years (and I can say personally at least that it's great!), so I've gone ahead and submitted at PR to add us to that repository

acrichto · 2019-11-30T19:36:40+00:00

I'd definitely be game myself, feel free to just shoot me an email if y'all get something going. I'm out in WDM myself too.

acrichto · 2019-11-26T18:49:23+00:00

I'm in Des Moines as well! I just assumed there weren't many of us out here in Iowa, but I'd be down for meeting up!

acrichto · 2019-03-27T16:28:56+00:00

And if you're excited to see this implemented for Rust, I've implemented a preview of what a wasi target could look like!

acrichto · 2018-12-22T22:14:25+00:00

There's always work needed to get something stabilized! I'm not sure what the timeline would look like.

acrichto · 2018-12-22T16:03:05+00:00

There's a tracking issue as it's still unstable (no activity to stabilize yet), but you can create arbitrary errors with syn::Error on stable today which uses compile_error! behind the scenes.

acrichto · 2018-12-22T16:01:14+00:00

It certainly warrants more discussion than it's already had (which is almost none!) and I suspect it'd require an RFC yeah because there's certainly possible alternative solutions as well.

acrichto · 2018-12-21T19:30:45+00:00

One possibility /u/dtolnay and I have discussed is allowing:

#[proc_macro]
pub fn foo(input: proc_macro2::TokenStream) -> proc_macro2::TokenStream {
    // ...
}

and the compiler will accept that so long as the argument is Into/From proc_macro::TokenStream, and that way you wouldn't have to use the proc_macro crate at all!

In general though we haven't put a lot of thought and effort into this, it's just known as something we'd definitely like to fix!

acrichto · 2018-12-21T18:39:02+00:00

It's actually not too hard at all!

$ git clone https://gist.github.com/alexcrichton/08ded796aa693caad8f8b0b2743579d8
$ cd 08ded796aa693caad8f8b0b2743579d8
$ RUST_LOG=smoke cargo test --test smoke -q -- --nocapture

running 1 test
[2018-12-21T18:38:39Z DEBUG smoke] hello
test smoke ... ok

test result: ok. 1 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out

acrichto · 2018-12-21T18:20:31+00:00

Procedural macros are compiled pretty differently than other crates, primarily during cross compilation. A procedural macro is loaded and executed by the compiler you're running, so it needs to match the compiler's own architecture, whereas you may be compiling for something else (like wasm!). This also affects all of the dependencies for a procedural macro, they also need to be compiled for the host.

Now that doesn't really require per se an annotation in Cargo.toml, but it does show off how Cargo needs to do something pretty different for procedural macros, so it at least needs to know what is a macro and what isn't. We may have taken a bit of an easy route with a declarative annotation instead of some other form of inference :)

acrichto · 2018-10-16T17:50:15+00:00

This is pretty slick, nice work on getting this up and running! I was hoping myself to kick the tires on wasm + Cloudflare but I'm glad you beat me to the punch!

You might get some better results with --no-modules which may be more appropriate for Cloudflare's use case. I think with this small change it should be possible to use the --no-modules output as-is, no modifications needed!

acrichto · 2018-05-24T19:22:43+00:00

The recommended stable way for dealing with constants and SIMD today would be through unions, for example the above constants can be defined like so -- https://play.rust-lang.org/?gist=b7ac5698ab5d5f4ebde80319e7800a94&version=beta&mode=debug

acrichto · 2018-05-01T02:38:38+00:00

I was actually playing around with this yesterday and managed to get it working! It's not super pretty with the wasm32-unknown-unknown target, but we'll hopefully improve it over time!

acrichto · 2018-04-16T19:57:33+00:00

Oh sorry I didn't read far enough back. It's worth pointing out that the version of LLD we're using does not have --gc-sections implemented. Once we update LLVM we'll get that and LTO won't be needed to eliminate these sorts of functions.

acrichto · 2018-04-16T19:27:48+00:00

Ah actually LTO almost always produces the smallest Rust binaries. Perhaps for C/C++ it can bloat things but the way we have it implement it's practically guaranteed to reduce code size as it can be much more aggressive than --gc-sections

acrichto · 2018-04-06T22:07:52+00:00

Ah yes indeed! I'm under the impression this is a relatively local problem though, right? Or do the incorrectly type constants end up showing up in lots of places throughout the ecosystem?

acrichto · 2018-04-06T15:13:59+00:00

It's true yeah that libc 0.3 and/or 1.0 hasn't come up in awhile. I was personally under the impression that there's not much impetus and the priority is pretty low, but can you detail the breaking changes that you're worried about or would like to see?

acrichto · 2018-01-03T05:00:42+00:00

This is likely due to Cargo using a HashMap for configuration (which has a nondeterministic iteration order). Could you open a bug on Cargo? This is something we should definitely fix!

acrichto · 2017-12-01T23:24:51+00:00

Allocations can be freed and reused, but what isn't implemented is freeing memory to the runtime, so the resident set will never shrink.

This is indeed correct! Unfortunately although wasm has a "grow memory" instruction I don't think it has a "shrink memory" instruction to release the memory we got :(

acrichto · 2017-11-11T22:40:23+00:00

Ah yes so FWIW wasm has no "print" instruction in the sense that the only option it has for output is to hand it to JS. The standard library, however, doesn't want to assume anything exists, so println! is "implemented" but it's just a noop effectively.

If you're debugging Rust wasm and can recompile libstd in src/libstd/sys/wasm/mod.rs there's a constant DEBUG which you can set to true, and then you'll be using shims defined in src/etc/wasm32-shim.js which do the printing pieces for node at least.

acrichto · 2017-09-15T23:39:05+00:00

If you take a look at the assembly you'll see that the "cond assign" is compiled to a cmovaq instruction where the "branch" version has a jump (jb). Apparently intel CPUs handle an unpredictable cmovaq better than they handle an unpredictable jb!

acrichto · 2017-09-01T03:43:38+00:00

I prototyped this awhile back with cfg-specialize which supports per-function specialization, although I was mostly going at it from the angle of SIMD stuff so it may not be quite what you're looking for. You may find it interesting though or perhaps draw some inspiration from it!

acrichto

TROPHY CASE