Solving Rust’s biggest problem
HTML-код
- Опубликовано: 26 июн 2024
- Unveiling the most significant improvement to the Rust compiler yet. Witness how Rust is overcoming it's compilation hurdles and solidifying its position as a top-tier programming language.
Free Rust cheat sheet: letsgetrusty.com/cheatsheet 
Наука
📝Get your *FREE Rust cheat sheet* :
letsgetrusty.com/cheatsheet
Slow build aren't because of rust "carefully checking the program". You can use "cargo check" and see how fast that is. It's slow because of colossal pile of unoptimized intermediate code it dumps on LLVM and says "here buddy, have fun, I know you are good at this". Problem is exacerbated by any use of generics or smart macros. Try to use small alternatives for clap and serde_json, and you will see huge improvement to compile times.
Since this comment has blown up, this was what I remembered from the olden rust days. Now there is MIR representation in the compiler with possible optimizations before the LLVM.
"unoptimised IR Code" 😂 Well tell that to the compiler team and see their reactions xD
@@ITSecNEO It _is_ unoptimised. That's kind of the point. LLVM is the one optimising it, not the front end
@@ITSecNEO Well this is nothing new to them, it was a design decision from the start to leave optimisation to LLVM
Way to sneak "unoptimised ir code" code in there. I doubt the rust proj homies would let that slide.
Good point! I didn't mean to imply that checking the program for correctness is the only or even most significant reason for long compile times
0:50 "when people complain about slow builds, they're almost always talking about the slow release build" Do you have a source for that? Because it surprises me a lot. I only care about debug build times because they need to be done often. Release builds are done rarely and run in CI so I don't really care how long they take.
Tal cual pibe, tenes razon
This! I was gonna write the same comment, I couldn't agree more.
Yes, I thought that was odd too.
Yes, I’m doing API dev with Tokio, Diesel (async), bb8, Axum, etc and the compiles every time I change something are pretty long, for compiling with 32 threads and linking with mold.
This video is terrible. full of misinformation
Sure it takes long to compile, but do you rather scroll Facebook waiting for the build to finish or do you want to chase a bug down a rabbit hole, trying to figure out why some variable is undefined?
Well when you put it like that, i prefer to chase a bug down a rabbit hole.
Ah yes, the most obscure and most impossible to fix bug: undefined variable.
Hey where is the excitement of all the busy work figuring out why undefined is not an object or a function? Where is the glory putting out fires of our own creation? You are no fun.
Are those the only 2 options?
Facebook... old man detected...
"Eats personal time" No shot I'm letting compile time eat my personal time. Shit compiles on the clock.
instead of rustc the compiler could have been called crust 🤣
Good point. :P Maybe a great name for the Crablang fork? 🦀 :P
"compilation time decreased from about ten seconds (9.57)
to about eight seconds (8.28)"
you sound like it's 2 sec improvement whereas it's actually 1.29 sec, dude. don't be like that, off by 47%
hah, not even a single order of magnitude. such precision is not needed. i was off by 1e1e15 once.
The exact values are 1.29 seconds, but he likely rounded both figures before subtracting.
I'm not saying you're wrong, I'm just saying he isn't really either
Fair points, not the best example to showcase this feature
They should rewrite the compiler in Rust. Then it would be super fast and completely memory sa-*I walk face first into a sliding glass door*
Huh? Well, it already is written in Rust. In the long ago past it was written in OCaml (also a great language by the way), but nowadays Rust is obviously compiling itself, like a proper compiler should always be able to do.
i think this suppose to be a joke. with the sliding glass door and everything
Can't decide if it's sarcasm or a joke. (Perhaps its both)
I am working on a perf critical app at work, in Rust, so even my dev/debug has to use release optimisations so I can find regressions immediately. Compile times suck lmao
Your regressions are release specific? How come?
they're using the trust_me! macro@@tatoute1
@@tatoute1 I assume performance regressions?
The parallel frontend is consistently slower on (most) of my personal projects, by about one or two seconds.
The only time it was actually faster for me is building the tokio repo (about a second of improvement in debug and half a second in release).
I guess it only speeds things up in niche situations, like workspace builds(?)
Alternatively, think more and compile less. It is not Python :)
I do just that. I think that could even out productivity vs. compile time. 👍🌞💛
Observing the effects of modified code is sometimes the e best way to facilitate thinking about it.
Except the parsing and semantic analysis is also done constantly inside the language server.
This means you have to complete your full thought and type the whole thing before the typing debounce kicks in.
This statement is kind of like "if your code is bad, just make it good"
Also, python is an interpreted language. And the compilation to bytecode is practically instant. What the hell are you compiling? 😂
additionally*
The biggest problem with Rust is the Rust Foundation and its policies.
Tauri needs this update
Cranelift is going to be a bigger boost. LLVM is one of the slowest parts of the compiler. The biggest issue _by far_ is the use of ld, you can get a significant boost by configuring lld (or mold) today.
love Cranelift
i din't knew that cranelift was a thing, this certainly help things if the compile times are that bad in debug build
As long as they don't sacrifice some runtime performance for conpile-time fastening, I'm ok with the new improvement. I always set `codegen-units` to `0`.
Why does this feel like a dejavu?
Is this a reupload by any chance?
Building a large program in "Borland C++ 1.0" was a pain in the ass compared to the then super-fast TurboPascal. I don't find rusts's debug compile times thaaat dramatic. For release, yes, especially with LTO turned on. But I do release build when ... well, releasing only, so not a big issue for me.
Dynamically loaded rlibs plz (for plugins)
I would have preferred if you tried a Bevy hello world fresh compile. That takes about 5 minutes on my computer.
We used to have slow compile times for *everything*. This was a real pain for C because the compiler is bad at getting out of sync and producing spurious errors. You could analyse the messages so far and then they became meaningless.
So there was a tendency to fix the first error or two then recompile and re-evaluate. This avoided wasting time fixing errors that were really only parse failures.
Now if you have better error messages due to more static typing and less loss of sync, it's worth considering more of the reported errors before giving up and recompiling. This increases productivity by getting more work done in the edit phase and requiring less compile cycles.
Does Rust provide this advantage ? if you work differently, do you get similar edit/compile time ratios that you would with fast compilation ?
Also, remember xkcd:303
The more threads and faster you run the compile, the less optimization it can do and the slower the resulting binary. It is a trade off between speed of the compile, vs speed of your code, which is more important to you?
Unfortunately, because of Moore's Law, in 90% of commercial environments in a tradeff between speed of compilation (and other development) and speed of execution, speed of execution loses hands down. And has done for 40 years.
I compile on a ryzen 7950. What's your problem?
Please, make a video, explaining the nightly-only feature, that will never come in to prod
Rust compilation is IMHO still much faster than C++ compilation without C++ modules.
Mold linker and sccache speed up comp times for me
I was excited to hear about this a while ago but upon trying it out, the threaded option is actually slower than single threaded.
24 core Ryzen 5900x
normal: 23.4s
threads: 26.8s
the results are very consistent, around 15% slower with threads
Did you use 8 threads like recommended in the video or all available? It may be possible that there's a sweet spot and adding more doesn't make it faster.
Years ago I once benchmarked a program on a CPU with 4 cores & threads and for some reason it ran the fastest with 32 threads. Going higher or lower would make it run slower. Performance is weird.
As they wrote in the blog post, it strongly depends on the project, particularly how the dependency tree looks like
@@SaHaRaSquad yh, tried with 8 and 12, same results
@@theLowestPointInMyLife
Maybe it is the code you are compiling tho, or even a bug in the implementation (as it is nightly).
@@diadetediotedio6918 yeah, its not uncommon, ive seen many people reporting the same thing, I dont really care tbh, its a non issue for me, my 23s is compiling from clean, when im changing some code with cargo watch running, it only takes about 4s, mildly annoying at worst
Awh yeah, lets get that ISO standard going and make that compiler lightning fast
I do not understand this problem at all.
Why not having a cup of coffee (tea|bear|vodka|whatever you like) while compilation process???
Because I'm not a drug addict and don't want to ruin my kidneys in a day.
@@shinobuoshino5066 A fruit then?
installing trunk takes about 10 minutes
Took me 20s. You sure pc isn't just trash?
@@thegoldenatlas753There will always be devs that compile on a potato and complain about it.
@@1____-____1 I would rather have it be slow on my computer, than completly disregarded performance and expecting my clients computer to be just as fast as mine. It's like activating artificial network speed throttling in the web devtools, so you develop the website from the start in a way that works on slow networks as well.
I’d rather have longer compile times than a night of debugging a dumb programming mistake
A rust interpreter for development would be nice.
-Zthreads=8 has been available for quite some time already. Is there a timeline for when this flag will be stabilized?
it has never worked, actually compiles slower
compile time = coffee break. I don't see a problem.
Yes lol but you cant take a coffee break every 5 minutes
@@Boxing_Gamer
It's not needed every 5 minutes, most of the slowest compiles comes from specific structural changes in the project, the other types of compilations are usually sufficiently fast (like 1-5s max).
thats not an excuse. and coffee makes me sleepy
@@ggsap what kind of metabolism do you need to get sleepy from coffee
@@abdullahmertozdemir9437 for me I think it's my ADHD, caffeine has no psychoactive effect on me, it only very slightly increases heart rate and it helps migraines. But it is a warm drink, and warm drinks make me sleepy. 😅
I just did a test on a codebase I work on. With this flag on nightly 10:24. On stable without the flag 11:09.
I have an issue with when using vectors of some enum I cannot see the values in the debugger even though they are there. It's a bit frustrating not having the ability to see the values in my code. I have to use print statements, but I cannot use those in the unit tests. I never had this issue in any other programming language. I love rust but this is really annoying.
Cargo swallows prints to stdout by default. Run your tests with `cargo test -- --nocapture` to override that.
If the only approach on tackling compile times is parallelizing and incremental compilation, then it is good night for high performance compilation. Other languages compile many orderes of magnitude faster than rust, and still don't use parallel builds or incremental compilation at all. just to name some: Vlang and Jai
JAI and Vlang are not full of useful features yet lol. Wait until their compilers get more complex and you will See the exact same Problems xD
My forth compiler compiles over 4 megabytes of source per scond and is SINGLE threaded. On my 12900k it would probably be much faster and unlike rust Forth is actually a readable language :)
If the compiler is too slow then just... rewrite it in rust?
The problem is that it uses LLVM which has a lot of work put into it, so the end result might not be as good and not as many targets would be supported. It should be done, but it's not easy.
Didn't have a problem when using the mold linker and dynamic linking.. I'm not sure there is a problem anymore really
Isn't mold very limited though?
@@WorstDeveloperDon't know. I've had no problems
@@Boxing_Gamer Afaik it only supports linux, right? I know that they forked Mold and named it Sold, with the intention of making a paid version for Mac and Windows. But no one wanted to pay for it so I think the development of that fork is pretty dead now.
@@WorstDeveloper Too bad.
I guess the only option for windows users then is to have a Linux machine or partition while using Rust.
Doesn't most of the compiler slowness come from llvm, and generating bloated LLVM IR?
No, the Lexer is bottleneck of frontend part in the compiler.
@@buffer0xaa555 I was not talking about the compiler frontend, but the whole compiler as whole. Even non optimized lexers are super fast programs, lexing is very simple.
Wait, it still isn't self hosted?
@@dupdrop Logically simple but it take a lot instruction to the computer.
@@zweitekonto9654
Obviously it is self hosted, but as most languages the final process of the machine code generation and optimizations is done by the old good LLVM.
2:52 Wait, did it actually use 14 GB of RAM for compilation?
doubtful. Windows ram always looks like that
@0:18 - good, the compiler. I thought it might have been a lawsuit when you said "taking them seriously".
That's cool about the compile times. They weren't that bad before actually for typical projects but always welcome news.
Compile times vary a LOT based on the number and kind of dependencies in your project.
@@SaHaRaSquad- but only first compile, which is no biggie
@@jeffg4686 No, some dependencies can actually cause even recompilation to be 30 seconds or longer. I don't know how that's possible but it's happened to me in the past.
trt1 turkey mentioned
it's funny you mentioned Rayon. its error messages are insane
insane as in incredibly unhelpful or insane as in incredibly useful?
@@carlosmspk first. It correctly indentifies the problem (type mismatching) but the problem is detected at method call, not at struct creation (where it actually occures), so you spend your time trying to fix a correct piece of code because you trust Rust's compiler. In other languages, it is just a regular error message, but since it's Rust we're talking about, I expected it to be as usually precise. Luckily, people on Stack Overflow are accustomed to Rayon and know how to deal with it from experience
In my experience Rust's error messages are outstanding until the code gets too generic or macro-heavy, at which point the quality plummets noticeably. There are even situations where the compiler incorrectly throws an error in 100% valid macro code.
That and readability in general are the reasons I usually avoid abstractions and generics and it's a very pleasant experience - but I can only do that because I write Rust in my free time.
@@SaHaRaSquad yeah but if you are not the only person who writes that code or even if you're alone but your code gets complex and is about to scale more, it becomes a shltshow
@@SaHaRaSquadoh that's definitely true. I've also noticed it with custom structs of iterator functions, like Difference, Union, Iterable etc. - you know you're screwed the moment the error messages start looking like "ATypeOfTypesOfLifetimeATypesOfdynTypes doesn't implement ATraitOfTypeIntoAType"
Armature Science.
If I don't have to wake up at 4am then I don't have any problem with compile time. ❤
evcxr could replace ipython for data science if only it weren't so laggy.
tell me if I'm wrong.
I have a REST API made with Actix and SQLx. It builds in... 10 seconds max.
I never saw it as an issue. I can check my email, change the music, make myself a coffee, etc.
It's a real problem for you guys? or you are experiencing larger building times?
Yea I don't really have a problem with it, maybe because microservices are individually small.
The main thing that makes me not care is that I don't need to compile to see compile errors though, they show up immediately in the editor as I'm typing.
Specially when using Tokio
They should just change the default linker, the most bottleneck in all of this. The frontend is already pretty fast, its the backend that scks
i just want to mention xkcd comic 303
Honestly, this is a tempest in a teakettle. I could not care less about how long it takes to compile. Make Hello World take 30 seconds if that means the compiler does a great job, checks the code thoroughly, and the resulting executable is as optimized as possible. The compile time is the least of my worries. I'd like my programs to work properly and quickly. That's the #1 goal. Compile speed is cool and all but that worry comes after most everything else. So, I think Rust got it right. It checks programs thoroughly, it tries to optimize well. After that's all said and done, sure, let's get it compiling faster too. But, calling that it's biggest problem is actually a GREAT sign. If we're down to "it takes 10 seconds too long to compile" then obviously things are in excellent shape.
Good video!
What does "cut by a factor of 3 mean"? It now runs in 1/3 of the time? Or 1/3 of the time was cut so it now runs in 2/3 of the time?
1/3
I think what it meant was that 1/3 of the time was removed, meaning it takes 2/3 the time.
@danielhalachev4714 oh ok
God, sexbots even in programming related channels? jesus
At least they don't even try to hide and makes it easy to ignore. Thank god they have these images. I don't even need to read the text. Wait until they are all upgrading to AI and actually try to look like a human being. That's when RUclips comments really die.
It knows the Rust demographic
@@cls880They are everywhere, regardless of the content.
1 second faster from 9 seconds. How about make it 1 second from 9 seconds instead of "1 second faster"?
Anyone complaining about cargo build times is welcome to run cabal build on 0 imports project.
inserting that clip of that loathsome kanye was stupid, didn't come here to see that kind of crap
problem with rust compile time is llvm or the backend. making the frontend faster is only 30% of the job. the other 70% is moving off of llvm at dev cycle. only use llvm when build --release is enabled
C++ numbawan!
Nice!
The difference is too small to make any dev more productive.
Maybe the benefit is when installing cargo packages for normal usage.
Rust compile times are very pleasant already when you.compare them to a medium to large C++ project.
Full clean build can take 30 minutes or more, not your pesky seconds.
If we only had C++ in this space then maybe there would be less concern about slow compile. But there’s the fast Go. Yes, their application domains aren’t coincident but they do overlap considerably. So that provides an incentive to speed things up.
@@kevinmcfarlane2752 Well, the only thing *I* have available to me at work is C++14. And that's not going to change any time soon.
"Muh compile times!" cries seem just inane to me. Like, really?
It takes seconds for a trivial project in either language, the problems arise as the codebase gets bigger
I have a hard time seeing how you end up compiling so often it becomes an actual productivity issue. Sounds like people are throwing spaghetti at the wall to try to fix bugs, I don't see how else you compile so frequently you have a problem with sub-minute delays. Maybe those long waits will give them a chance to do what they should, and fix their bugs by actually reading their code.
less compile time = less coffee time, so its a loss
I mean really I need to check messages anyway....
As bayrakları as as 🇹🇷🇹🇷🇹🇷
Coding 2 minutes,building 2 hours 😂
A bit disappointed that the video is about the compiler and not that it is extremely hard to properly parallelize code.
what happened to the rust foundation drama?
Rust's biggest problem is its syntax
for development and testing code we could use jit or interpreted
and for publishing and bundling
we could use the traditional compiling 🤔
No, that's not the issue. Creating the machine code is not the slow down, it's mainly the checks.
@@svenyboyyt2304 Also proc macros.
@@svenyboyyt2304
What is the source of your claims that creating machine code is not one of the biggest slowdows? We know this is a problem even for zig, as they are creating their own compiler backend for debug mode just because LLVM is slow.
Simple cuz the language isnt made for web development? idk why ppl are trying to use cannon to kill a rat.
- btw C++ > Rust
it is made for web development, ever heard of wasm or Leptos?
ofc, but keep your fantasy dreams on, ever heard of choosing the right tool for the job?
@@vsantos1 yes, that's why Rust has increasing uptake in web development
Its not biggest problem of rust. His biggest problem is impossibility to make more than one mut borrow. As result writing any tree-like structure to complex. So even c++ better than rust for gamedev. And its reason why crutch like RefCell exist.
More than one mutable borrow can potentially lead to data race
No, that's by design. Using things like RefCell isn't bad.
Lol, this is like almost the whole reason of why Rust is considered memory safe, you cannot make crazy things like borrowing an item from an array and then trying to clear the array while it is in use (or overwrite the item or anything).
And for game dev, you have bevy which abstracts on top of the Rust limitations and gives you a safe interface for handling game logic, you would not need to worry about that in games because usually you would build things in a more unsafe manner and just expose the safe abstractions.
Rust preventing you from using multiple mut borrows is essentially forcing you to do things the right way. Things like multiple mutable borrows are a big cause of memory errors and security holes in programs using C or C++. Rust is thus "harder" to program with but gives much better guarantees about memory safety. It's the whole point of Rust.
Isn't it Arc used for this exact scenario?
trt1 mi? hahahaaaa :D as bayrakları as as as :D 🇹🇷🇹🇷🇹🇷🇹🇷🇹🇷🇹🇷🇹🇷
stop spreading misinformation, have you seen big cpp project compile times?