strager

> Ideally type-checking, linting, highlighting and formatting would run in one language service doing incremental parsing and updates to a shared AST on every keystroke.

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.

Here is the answer I got from vjeux:

> 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.

Sean Baxter is doing a decent job with his Circle compiler, so I hear. https://www.circle-lang.org/

Unfortunately, we live in the real world where compilers do not do the things that you suggest that they ought to.

I'm not sure what you mean. Are you talking about the benchmarks?

I run `cargo clean` before each benchmark. That should clean up changes to third-party crates, right?

I'd love to try Zig and Jai for this purpose, but they are not stable yet. If either becomes stable, I'll happily re-run this experiment.

Nim doesn't look like the language for me.

> Definitely check [Val and Carbon] out if you're looking for a C++ replacement!

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.

> If your main conclusion is based on full builds, i would urge you to re-evaluate.

It's not. I show several charts comparing incremental builds too.

Good question. The author of Zig claims that dev build times will be amazing. One technique is to avoid LLVM. Another technique is to integrate the linker. But all of that is a work-in-progress project.

> I don't know enough C++ or Rust to judge but is it possible that they are optimized around Rust that isn't C++ style? I know I have seen articles about other languages where some very minor changes make a huge difference because the optimizations in place didn't understand what was happening and had to work harder.

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

I have found Clang's -ftime-trace flag helpful in finding bloated #include-s and templates. Also, I have analyzed the .ninja_log file (for CMake+Ninja) to find slow-to-compile .cpp files.

> They seem to have chosen to use mold for C++ and not for Rust after seeing that it gave little benefit for small projects, but I would expect that to change as the project scales.

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’m very confident that Rust would fare considerably better with 24 17.1k-line crates (410k lines, larger due to duplicating the entire thing rather than just the lexer) than with the one 104.4k-line crate apparently tested.

I didn't consider this in my scaling benchmark. You make a good point.

> if I want faster development (among other things), I use an interpreted scripting language. If I want a fast end product (among other things) I compile and optimize to machine code beforehand

I want both. I was hoping Rust would give me both, but it doesn't.

> I assume it also reduces size of created object-files?

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.

Current settings according to BIOS:

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!

> I would expect an idiomatic implementation to drastically go down in lines of code

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

> Raise the FCLK (Fabric Clock) to 1900.

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!)

> I just randomly looked at one part: linked vector.

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!

> A recent change[0] on nightly rustc might help with incremental builds.

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.

>> Someone has to implement them. Note that they're also implemented in the C++ code, so the comparison is fair. > > I'm not sure I buy this argument in code like yours which almost invariably should just use the standard library and definitely needs to measure before replacing standard library features with your own hand-rolled equivalents.

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.

No, I'll stay far away from them, thanks. ;P

> Of course it exists in C++, and has done since before Rust even existed.

Not in C++'s standard library until C++20.

It is a beast. I love my MacBook Pro!

I'd wager that the C++ compiler does more work churning through #include-s than the Rust compiler does tracking borrows.

> Importing binary packages is a terrible idea, and a source of huge problems.

Importing binary packages is a tradeoff.

I have heard talk of compiling proc macro crates with different rustc flags than other code. But I didn't go down this rabbit hole.

I actually pointed it out in the article when I compared GNU ld with Mold. =] And I was actually wrong in my comment; run_linker took 129 ms, not under 100 ms. https://quick-lint-js.com/blog/cpp-vs-rust-build-times/#opti...

Why would a project need to become "idiomatic Rust" for a Rust port to be useful?

Note: I wouldn't draw any conclusions from the -Zself-profile data in the article. It looks at just one rustc invocation, and is one sample.