strager
I think this is the reason Biome (originally called Rome) started. Rome's vision was a shared toolchain to yield better performance and to fix config hell.
> There's a lot of fast web tooling being written in rust those days. https://twitter.com/Vjeux/status/1722769322299609565
I don't buy it. I think vjeux is riding the hype.
I run `cargo clean` before each benchmark. That should clean up changes to third-party crates, right?
Nim doesn't look like the language for me.
I don't want to base my project on an experimental language like Carbon or Val.
I want a C++ replacement which compiles quickly. Do Carbon or Val compile quickly? If not, I don't know why you mention these languages.
It's not. I show several charts comparing incremental builds too.
Are you talking about run-time optimizations? My article is focused on build times. I don't think what you mentioned applies to build times. I could be wrong, though. (There are certainly compile time traps you can fall into, but I wouldn't know what those are in Rust.)
> And did you try any of the optimization strategies again at 24x? I would be curious if there are differences there.
No, I did not. That's a good suggestion. But I was pretty tired of this project by the time I made the scaling benchmarks. xD
The benchmarks show Mold for both Rust and C++. This wasn't explicitly stated in the article; sorry. https://github.com/quick-lint/cpp-vs-rust/blob/f8d31341f5cac...
I didn't consider this in my scaling benchmark. You make a good point.
I want both. I was hoping Rust would give me both, but it doesn't.
Normal template instantiations are deduplicated by the linker. Total object file size is smaller with explicit template instantiations, but the size of the final executable is the same with both styles.
Target CPU Speed: 3400MHz
Target DRAM Frequency: 800MHz
Target FCLK Frequency: 1800MHz
DRAM timings: 19/20-19-19-19-39
(The DRAM CAS# Latency setting is set to 19, but "CHA" and "CHB" show 20. I don't know what this means exactly.)
So I think you're right, scns. I was not getting the best performance.
---
I changed FCLK to 1900MHz and re-ran the Linux C++-vs-Rust benchmarks. Some results:
build+test w/o deps: 1847ms Rust, 1874ms C++ --> 1801ms Rust, 1837ms C++
incremental test-utf-8: 288ms Rust, 358ms C++ --> 280ms Rust, 350ms C++
So I did get a performance win for both C++ and Rust builds by fixing my FCLK. Thanks!
Can you give an example of where something in the project could be, say, 20 lines of code instead of 30? https://github.com/quick-lint/cpp-vs-rust/tree/master/rust
Hmm, I think I did this, or something like this. I'llcheck tomorrow. (If I did, then my comment about not overclocking the CPU is misleading!)
How would Rust LinkedVector's implementation have fewer lines than C++'s linked_vector?
> It would be a great experiment to use lots of external libraries. You might find that the code doesn't get slower (build times would probably go up though )
Build times going up is a great reason why I would not use external libraries!
I tested with rustc Git commit c7572670a1302f5c7e245d069200e22da9df0316, which (I think) includes that change.
> And for repeated clean + full build cycles there's sccache[1].
You're right. I included full builds in the article because almost-full builds happen a lot in C++ (after common certain header files, or if you think the build system broke something).
I imagine almost-full builds rarely happen when working in Rust though, so maybe I should have deemphasized my full-build benchmarks.
I did for the C++ code. And for a fair comparison, I ported my C++ vector to Rust.
If I made the C++ code use a custom vector and the Rust code use the standard vector, then people would complain that the Rust code was artificially shorter.
> For example in strolling around this code, I ran into sorted_search. But, isn't this just [&str]::binary_search() except written by hand?
Yes. But the standard binary_search isn't `const`, and mine is. I need to run my `sorted_search` at compile time to map translatable strings to magic numbers. (The C++ code does this too.)
> Actually the fact there are "linked lists" and yet there's no concurrency sets off alarms in my head. [...] why Linked Lists ?
The linked lists are actually linked lists of arrays. They are not grade-school linked lists with one item per node. In the C++ code, the classes are linked_bump_allocator (a memory arena) and linked_vector (a deque-style container).
I wrote linked_bump_allocator so I could use an arena allocator for parser ASTs, temporary strings, etc. I originally used Boost's monotonic allocator, but I wanted a rewind feature, so I wrote my own implementation.
I wrote linked_vector only because std::deque took too long to compile. (I'm not kidding.) So I could have easily used Rust's standard deque.
Not in C++'s standard library until C++20.
Importing binary packages is a tradeoff.