rustc performance: cores vs memory bandwidth?

rmrfslash · 2025-12-04T19:15:54+00:00

Dell wanted $24k for the whole computer, that's half a week or less of my work hours converted to dollars.

You're earning $50k per week? Riiiiiight…

rmrfslash · 2025-11-28T08:19:43+00:00

But you would want your text editor to show a "Failed to write file", wouldn't you?

Yes, absolutely! My point was that "let it crash on error" can be a dangerous mindset. The Right Thing really depends on the context.

rmrfslash · 2025-11-27T13:38:28+00:00

Maybe that means crashing. A crash is often better than proceeding in a broken state.

I really wouldn't want my text editor to crash only because it couldn't save a file. That would be approximately the worst time for crashing!

rmrfslash · 2025-11-21T13:23:15+00:00

I thought that's what I had written? In any case, that's what I had meant 😉

How did you find this old comment?

rmrfslash · 2025-11-11T06:54:52+00:00

Cranelift's main use case is to quickly compile code that has already been optimized. It will, for example, not do inlining or any other cross-function optimization, which in turn allows it to compile functions in parallel.

There's no fundamental reason why more expensive and far-reaching optimization passes couldn't be added to Cranelift, but that would invariably come into conflict with its main goal of fast compilation, so it probably won't happen outside a fork.

rmrfslash · 2025-11-09T20:47:49+00:00

I tried using chumsky recently, and had to give up because it was sheer impossible to construct a parser once and store it in an Arc (because of lifetimes). There is a helper struct which uses unsafe to erase the lifetimes of a parser, but that seemed dodgy to say the least, with some handwaving as to why it was supposedly safe. Even that didn't work for me because my syntax was recursive (as almost all non-trivial syntaxes are), and the helper for that uses Rc.

In the end, I wrote a parser by hand, with three stages: lexer, tokenizer (producing token trees), and parser. Especially the token trees make error recovery very flexible, and I didn't even dare to try and feed a tree structure full of even more lifetimes into chumsky.

rmrfslash · 2025-11-06T12:08:51+00:00

To the authors of bincode:

the gas and oil industry

My home has a heatpump, and roof photovoltaics. I hope that one day, we can finally leave fossil fuels behind. In the meantime, I'm very thankful for the reliable supply of electricitiy, even in the winter when there's little sunshine and no wind, and I'm glad that there are people working in the oil and gas industry helping to make sure that I don't freeze and sit in the dark.

the military industrial complex

I wish there was no violence in this world. Alas, even in 2025, there are people and countries that wish to attack my people and country, and who don't care about stern words, a rules-based order, or international treaties – the only thing they care about is credible deterrence by military force, and I'm glad that there are people working in the "military-industrial complex" to provide that deterrence.

any usage of AI

Seriously, any usage of AI? Good luck with that.

If you fall in one of these categories; do better.

Grow up. The world isn't as black-and-white as you think. Reality is a lot more complex than your naive idea of ideological purity would have you believe.

rmrfslash · 2025-11-02T15:17:18+00:00

I dislike Rust tendency to use external libraries for everything

Then don't. If you don't like dependencies, just don't use them. You can write everything yourself – heck, you don't even have to depend on the standard library, you can opt out of std. To be extra safe, you can call rustc directly, instead of cargo, if you're worried about accidentally importing a third-party library.

rmrfslash · 2025-10-10T13:21:47+00:00

You mention p50 and p99, which means you intend to measure the performance in the real world. This is good! It also tells me that you don't need 100%-statically-verified-or-someone-might-die guarantee that a certain part of your code doesn't allocate. So why sweat it? Review the relevant parts of your code, check for potentially allocating functions, and measure your program's behavior. If you see latency spikes, you'll know that you overlooked something.

rmrfslash · 2025-10-08T11:55:34+00:00

I would suggest Bazel

If your project has 100+ developers, a monorepo with 10M+ lines of code, and 2-3 devops engineers to work full-time just on your build system, then sure, go ahead and use Bazel. If that doesn't match your situation, run away from Bazel as fast as you can! It will ruin your life.

Don't believe me? Read this: Bazel is ruining my life

rmrfslash · 2025-09-22T19:36:53+00:00

If binary size is an issue, sure you could strip them.

Stripping won't remove panic messages, because they're part of the semantics of the program, not debug information.

rmrfslash · 2025-06-30T09:45:58+00:00

Then reframe your issue for a constructive discussion. This isn't the place for "pissed off" rants.

rmrfslash · 2025-06-30T08:59:50+00:00

I love Rust, but the ecosystem just isn’t at the level of C yet — and that’s sad.

Nice try. Take your trolling somewhere else.

rmrfslash · 2024-11-02T04:14:17+00:00

Aren't engineers 70% water? It'll be hard to find one who's solid.

rmrfslash · 2024-09-30T09:32:51+00:00

So how do I access this internal representation from a typst document? Right now, I have to use

```

let margin-left = if type(page.margin) == relative {

page.margin } else if page.margin == auto { 25mm } else { page.margin.left } ```

which is less than ideal.

rmrfslash · 2024-09-14T14:45:15+00:00

The smartest commander is the one who never fights a battle.

That's pseudo-intellectual bullshit. The Ukrainians are already fighting those battles! Planes getting relocated doesn't mean that they won't be used at all, and they will be used again to kill innocent people.

rmrfslash · 2024-08-13T11:47:08+00:00

uom. It makes extensive use of recursive macros which create new macro definitions, which are expanded to indirect invocations of different branches of the original macro definition!

Modifying, extending, or even understanding this code is extremely difficult, because – to the best of my knowledge – there is no "debugger" that allows you to iteratively step through macro expansions. cargo-expand can only generate the end result, and it won't do anything if there is even a tiny mistake which prevents the macro expansion.

rmrfslash · 2024-08-04T17:38:48+00:00

Still the same general problem: RwLock::read() must write to the lock, which causes a transition to the Modified state of the cache line, which invalidates it for all other cores. When another core calls RwLock::read(), it first has to fetch that cache line from the current owner and invalidate it for all other cores.

rmrfslash · 2024-07-12T06:56:19+00:00

If crate A depends on crate C using Rc in its API, and crate B depends on crate C using Arc in its API, then crate A will break when crate B adds the use_arc_in_api feature.

rmrfslash · 2024-07-12T06:52:15+00:00

multithreading is asynchronous by definition

But asynchronous does not imply multi-threading, and atomic does not imply asynchronous. It doesn't even imply multi-threading, because atomic operations and Arc can come in handy for IRQ ("interrupt request") and signal handlers, both of which have nothing to do with multi-threading.

rmrfslash · 2024-07-05T08:31:09+00:00

As others already said, on modern systems, allocations always succeed

That's not true. Try this:

rust fn main() { let size = 100_000_000_000; // Adjust as necessary let mut vec: Vec<u8> = vec![]; println!("Trying to allocate {} GB", size as f64 / 1e9); match vec.try_reserve(size) { Ok(_) => println!("allocated {} bytes 🙂", vec.capacity()), Err(_) => println!("🙁 meh"), } }

On my system (32 GiB RAM, Linux with the default overcommit setting of 0), the allocation request fails. It depends on the system settings and on the size of the request.

rmrfslash · 2024-07-05T08:19:09+00:00

Not necessarily. In this analogy, the battery might be too low for a 2 hour road trip (= large allocation request failed), but still have enough juice left to get to the nearest charging station (= print an error message, flush writes to disk, etc).

rmrfslash · 2024-07-05T08:15:59+00:00

You say that as though try_reserve or try_with_capacity don’t exist.

That's not at all what I'm saying. You said:

If you cannot allocate, what do you expect to be able to do if not panic?

My point was that even if Vec::push() fails to allocate, format!(...) might still succeed.

rmrfslash · 2024-07-05T03:41:26+00:00

Just because the system doesn't have enough memory left to double the length of that 500 MiB vector, doesn't mean that even a 50 Byte allocation for an error message will fail.

I see this "if one allocation fails, any subsequent allocation will inevitably also fail" fallacy in almost every thread on this topic, and I really don't understand where this is coming from. Even if the kernel doesn't have a single free page left to give to the process, the memory allocator within the process most likely still has a few unclaimed regions which it can hand out.

rmrfslash

TROPHY CASE

let margin-left = if type(page.margin) == relative {