nnethercote

Joined 15 years ago

Karma

3,691

Submissions

534

Member since

Jul 5

View on Hacker News

Recent submissions

Rust's Standard Library on the GPU vectorware.com

9 nnethercote 9 months ago 0 comments

Comment · 3 years ago

I'm a member of Futurewei's Rust team, and I'm in the Compiler Contributors group.

I started these posts back in 2016 when I wasn't a member of either. It's been a long-running series, and there's never been much reason for them to go on the official Rust blog, because they get enough attention on my personal blog.

In the past I have posted links to Hacker News but usually they don't make the front page and get few if any comments, so I stopped bothering, but others sometimes do. I always post to /r/rust where the level of discussion tends to be higher-quality than HN, because there is a higher level of Rust knowledge.

Comment · 3 years ago

I've tried AST memory layout work in the Zig style, look for "shrinkage" in these two posts:

- https://nnethercote.github.io/2022/10/27/how-to-speed-up-the...

- https://nnethercote.github.io/2023/03/24/how-to-speed-up-the...

It's hard work. Small AST changes often require hundreds of changes to the code. The required changes usually make the AST less ergonomic to work with. And the perf benefits I obtained were very small. Even after shrinking `ast::Expr` (by far the most common AST node kind) from over 100 bytes to 64 bytes on 64-bit.

The linked Zig PR has very impressive reductions in walltime/cycles/etc. but if you read closely it's restricted just to parsing, which is usually a very small slice of compile time, at least for rustc. My experience with these kinds of changes was disappointing. I concluded "I’d love to be proven wrong, but it doesn’t feel like this work is taking place in a good part of the effort/benefit curve."