C++ vs Rust: which is faster?
ฝัง
- เผยแพร่เมื่อ 16 พ.ค. 2024
- Follow me on Mastodon: hachyderm.io/@fasterthanlime
Support me on Patreon or GitHub: fasterthanli.me/donate
00:00 What is Advent of Code?
00:48 Python vs Rust
01:19 Interpreters vs JITs
03:03 Buffered I/O
04:27 Day 18 Benchmarks
05:00 How does the code feel?
06:49 Day 19 Benchmarks
07:17 Profiling, disassembling & decompiling
08:14 x86 assembly crash course
12:44 Suddenly SIMD
15:52 Day 19 mystery solved
16:40 Register allocation is hard
18:08 Switching calling conventions
18:31 2x3 != 3x2
19:12 Thanks & sponsored segment
Rust & C++ sources for day 19: gist.github.com/fasterthanlim...
Speculation in JavaScriptCore: webkit.org/blog/10308/specula... - วิทยาศาสตร์และเทคโนโลยี
Rust & C++ code is here: gist.github.com/fasterthanlime/b2e261c3d1492171d6a46edf620a0728
If someone's watching this going "I /know/ I can beat that by tweaking the C++ code", you should do it! I think there's a lot of good that can happen with some friendly competition between the C++ and Rust camps, as long as we both treat it from a "huh, neat that we can get compilers to do that!" perspective and not just shout at each other from opposite side of a virtual stadium.
I'll try to make a full write-up that goes a little deeper (maybe comparing emitted IR between clang and rustc), but first I have more research to do.
You might want to pin this comment, so it doesn't get lost. Atleast until someone makes an optimized C++ version.
Definitely need to get someone who knows relatively-modern C++ to refactor this more idiomatically (might even try it myself). So many macros and C-style code.
And immediately de-referencing begin() is not undefined behaviour, it’s programmer error - the programme did exactly what it was told it to do.
@@decky1990 i dont consider anyone who write using namespace std; as a C++ programmer, because if they had access to any decent C++ teaching materials they would have known using namespace std; is REALLY REALLY lame. if they have heard they shouldn't use using namespace std; and keep using it then they aren't seriously enough and treating C++ as a toy language that for lame competitions. is this gate keeping, yes, but is is it unreasonable to expect this, no. Maybe because there are so many bad youtube shorts, tiktok videos about C++ out there is become a norm. I couldn't believe that @fasterthanlime think this is how people write C++ and use this kind of code to compare with Rust (5:00 section).
There's also a lot of unecessary by value copying on the C++ implementation. Quick examples I've noticed is in the for-each loop and when populating an object then passing it to a push_back() of a vector. Though I'm not sure how much of that impacts performance.
There's performance left on the table from using cout and endl since the implementation of those two are notorious for slow IO without some configuring.
@@tsunekakou1275 aye the namespace directive is a bit of a faux pas. I’ve heard stroustrup kills a kitten every time some uses it. I suppose this was my cry for more idiomatic writing. I don’t want to beat the guy up for posting interesting content, but maybe get someone who specialises in the language instead of Jack-of-all-trading them, such that they’re all average implementations. Would be a really interesting comparison.
As soon as I saw the C++ solution I knew that it wasn't written by someone who knows C++ all that well so I decided to attempt my own solution. My solution ended up being around 4000x faster. C++ and Rust are close enough that the deciding factor for any non-trivial task is almost always going to be the algorithms used, not the language. So study your algorithms, folks. :P
truly insane how many orders of magnitude are hidden to be optimized even in millisecond programs.
@@arthurpenndragon6434Once you get used to looking at the disassembly, it's pretty easy to make 3 order improvements consistently, on other people's software anyway...
Algorithms rules supreme
Fair. What you are is a specialist. The acreage cpp programmer wouldn't go into your level of detail .. but I must ask, are you still using cpp if you are optimising the compiler?
@@bluedark7724 Knowing algorithms has nothing to do with optimizing the compiler
I know **just** enough low level computer magic to understand this, but man was it work. This was very well presented, I've seen much simpler things explained with far less clarity.
This is perhaps the best compliment I've received all year. I know the year is young, but still! I'm really happy that the video is understandable at some level - it's really hard to strike a good balance between "obvious to a lot of regulars" and "desperately impenetrable".
@@fasterthanlimea big part is your delivery takes you through the emotional journey(like saying “let’s not talk about that, and hopefully never again”, about an especially complicated topic) which makes it a lot more engaging than other comparatively similar videos.
I dont understand it my head gone blank 😭 do i need to study more ??? can you tell me something in which i can learn about it
@@spoofilybeloved6729 absolutely, their approach is much more like a teacher who wants to ensure you can follow along and feel included. A lot of presenters will pride themselves on knowing something and make you feel small for not understanding.
I failed to understand SIMD section, but i understood general principle and difference between 2 cases. It means that you explanation is really great. And i’m not even a developer or a programmer.
"This has been an ongoing fight for years according to sources who are very tired"
I felt this in my soul
I remembered Go.
Love the video! Absolute madness at the end, LLVM is probably such mess at this point because of the optimization priorities that it takes a team of compiler engineers a couple of days to even trace a problem lol, but they are the real heroes
The Static Single Assignment (SSA) form that LLVM IR uses simplifies dataflow dramatically. In Rust, it's a bit more SSA like due to borrow checker rules limiting aliasing, while C++ aliases at will, which can cause some optimizers to be disabled since the dataflow (and if it could have changed) is un provable at compile time.
This is the kind of thing that every optimizing compiler has to deal with.
Ok sir, tell me a non mess compiler infra then
Maybe you doubt, that I - not a rust expert -can write code slower than c++ one? I can, trust me. Another question is proficiency level of the one who wrote these C++ solutions that were ported.
@@darshanbhat9457I think you misunderstood. They aren't dissing on LLVM at all; it's a mess by necessity
The conclusion that compiler engineers need hugs and cats need petting are both true.
Sometimes it's even the other way around! ...if you know each other well, of course.
This video is really great! I also did Advent of Code with Rust and it really helped.
It's really refreshing to listen about Assembly in a clear, non-scary way.
I'm glad you felt that way! As I rewatched along during the premiere, I was convinced everyone would drop off as soon as the assembly section started, but maybe it's because I've heard those sections a hundred times while editing already!
@@fasterthanlime No way! More assembly plz
@@fasterthanlimeThe graphics were excellent, I doubt I would have followed along otherwise.
Just a note, if you're using the same "backend" eg: llvm for rust and c++ the results should be similar, the reality is though while llvm is a generalized backend for multiple languages, it's history is primarily to support the clang frontend. Essentially you're comparing how well integrated one frontend is with another so don't be too surprised if rust falls behind c++.
The add_examples issue is due in part to padding. Your struct with 3 members is likely being handed off to the compiler and it sees a struct which isn't perfectly aligned to a power of 2. So while you're thinking you're dealing with 3 64 bit registers the compiler's going to treat that struct as 4 64 bit registers. While you're right that you're just adding 6 64 bit integers together, what you've likely done is trip up an optimization stage because the compiler sees 8 64 bit integers (where the 4th and 8th are essentially discarded) and that likely is enough for simd optimizations to kick in (where adding 6 may not be worth doing) and then confuse later optimization stages.
How is this llvm's and not rusts' fault? The only stable backend for Rust is LLVM. It was their(rust creators) decision to use LLVM. They could've written their own backend(which would've been a disaster) but they didn't.
I think it's completely fair to compare Rust and C performance by how well they work with LLVM
@@igorordecha I get your point but I disagree. It could easily happen that a future release of clang or gcc outperforms rust just by tweaking how it interacts with compiler. Or someone could write a transpiler from c++ to rust and then compile code that way. I have to say that i don't agree that any this video does not demonstrate that one language is superior or inferior to the other.
@@mvuksano rust might be better language (and it is) as far as the spec and syntax go BUT with current tooling it IS slower* than C. It doesn't have to be that way in the future but it is slower* now. And that is what this video shows. It isn't "not fair comparison" because at the end of the day the binary built with rust is worse*. Yes, it's not the Rust's fault. It's the tooling's fault but it directly make the language worse (for now)
* yes, as shown in this video, you can make the binary faster by tweaking the number of arguments but in the real world you're not changing the API because the compiler has a bug.
This point (and all its replies) is very good - as is the whole video and many more of the reply comments. I'm just about to embark on learning Rust (and Go at the same time), and although this is definitely not my first computer language rodeo (I used to be somewhat of a collector (some might say hoarder) of computer languages, but the number of languages available has now gotten somewhat ahead of my rate of collecting them), I'm glad I saw this video first.
What I've learned here, is that if you want to write performant Rust code (on X86 target CPU, say), you're gonna have to learn how to outsmart the combination of the Rust compiler plus LLVM plus all the cumulative stupidities of the 50-year process of patching the X86 instruction architecture plus especially the well-motivated but often badly implemented SIMD instructions. One problem is that the code generation process does not have sufficient knowledge of the approximate relative performance of various instructional/architectural approaches to ASM-coding the given Rust code. If it did, it could at least loop over the several aproaches and reject using those SIMD instructions when the extra wasted execution time makes it such that using SIMD slow down the execution. There probably needs to be finer gained compiler control over its use of SIMD (not sure what's available at this point). You don't want to tell it not to use SIMD at all, just to un-screw-up its compilation a function for X = Y + Z, when later in the code you have a whole huge section that definitely needs the SIMD instructions.
Also, it's clear to me that (assuming I'm targeting X86 again, for sake of argument) I'm gonna have to learn the ugly X86 instruction set in order to do performance tuning in Rust. Darn, I thought I could just use Rust, but at the same time not only avoid the inanities of C++, but also say to the option of "learn X86 ASM" been-there-done-that-earlier-in-my-career with a much better computer architecture so really don't want to go down that road again only this time with a horrible X86 instruction-set architecture.
One wonders whether, in spite of the fact that Rust is not an interpreted language and thus does not require a formal byte-code intermediate language technically speaking, it might not be a great idea to define a (better than Java and perfectly defined for a hypothetical Rust virtual machine that matches well against current X86 and Arm architectures) Rust byte-code architecture, and then compile Rust to that Rust VM, then send that on to LLVM for final compilation to target machine. You could maybe make that first to-byte-code translation smarter, say smart enough that the Rust coder doesn't have to stand on his/her head just to outsmart the current combo of Rust + LLVM.
its*
I spent weeks of my life shoving SIMD into an unreal engine module to leverage new cpu architectures and you managed to sum up basically 3 weeks of pain into 20 minutes and I still understood it better than all the formal sources I bled my eyes at. Compiler engineers deserve all of the love in the world and they are criminally under appreciated.
compilers are AI
Matt Godbolt has a podcast (two's complement), and on the latest episode he quoted 'the first rule of profiling is that you're wrong' by which he means (I'm assuming) it is virtually impossible to guess the performance of a piece of code, or know which version will be faster as you illustrated here nicely.
So I'm guessing the answer to the question in the title is 'it depends' or just 'they are similar'
Like most titles in the form of a question, that one's not really meant to be answered - but I agree, they both performed pretty close to each other (and I still want to have a C++ person look at it - which I'm hoping this video will achieve).
Being wrong is something I'm trying to get better at, since every time you're wrong is an opportunity to learn something, and I love to learn. Here my first two go-to tools (callgrind & not-perf) revealed themselves to be not so useful and I was forced to stare at assembly for a long while, which I think is a happy outcome for everyone!
The title is very clickbaity of course. It doesn't make sense to compare languages for performance; rather, we compare compilers' codegen, which is what the video demonstrates.
@@fasterthanlime If you would like C++ opinions, I suggest you post this on r/cpp. You might not get a warm reception but you will get opinions.
Thank you for the recommendation of the Matt Godbolt podtcast. Thanks to you i started to listen to it and i am enjoying it so far.
@@AdvancedSoul well, you can compare programming language features by performance, because some can be implemented faster than others. Rust and C++ are basically the same in this regard though. With a theoretical advantage for Rust because it often knows more about borrowing, but that is currently not exploited by the LLVM backend.
So yeah between Rust and C++ it comes down to what the compiler does and if you use LLVM for C++ it will come done to some very random implementation details.
Your way of describing complex SIMD instructions was superb, congrats Amos!
"If you see a compiler engineer in the wild, ask if they need a hug." 😂 Very interesting to see the differences in compilation between C++ and Rust, and the effects of Stack vs register allocation illustrated so well. Great video, tons of information packed in a very short space. Thank you.
Great video. I love the low-level stuff, and compiler writers definitely deserve many hugs. I have my own toy compiler written in Rust, and even implementing the dumbest register allocator possible was already worth at least two hugs per day, because debugging even the tiniest of changes means reading screens of assembly code, interpreting that in your head and trying to keep up with tons of info, such as which variable should sit in which register, what registers are spilled at a particular point, etc. That's hard even given that I "cheated" and decided to generate code for RISC-V, which is much simpler than x86 or amd64, and I'm just playing around. I don't know if I am even able to write a more sophisticated one correctly with my ADHD and average intellectual abilities. How hard is what serious compiler devs do? Probably insanely hard.
The good thing is I have a cat too (btw she has the same pattern on her forehead as your cat). Whenever I feel overwhelmed with coding, she's always there for me. By that I mean she is sleeping nearby, not caring even a little bit about my struggle with my own inability to think clearly. But occasionally, she jumps on my lap and gently reminds me of things more important than code, such as scratching her cheeks 😁
What language are you creating the compiler for?
I do think it’s interesting the difference in knowledge of the two languages and what is “easier”. I know C++ very well I would say and I’ve never even touched rust, but when he went over the operator overload functions and mentioned how C++ was difficult and rust was “just implementing a trait like any other”. This made me audibly laugh since for me C++ overload is super easy and clean, when I saw the rust code at 5:56 it looked insanely bloated and had characters that seemed absolutely useless.
I’m not trying to bash Rust or the knowledge Faster, just pointing out how coding in a language with little knowledge creates MASSIVE bias and situations like this where something is “simple” just because you know it.
I completely agree with what you're saying, but I think the point he was getting at is the Rust way is a typical trait implementation. I think he meant that if you know even a minimal amount of Rust then you're going to know how to use traits whereas operator overloading is extra knowledge in C++. Also, he did simplify it down to simply writing #[derive(PartialOrd)] right after :P
@@RottenFishbone even the simplified went right over my head👀
exactly my thoughts! overloading couldn't be easier in C++
"hard to remember"... lmao.
@@RottenFishbone i wouldn't say "overloading is extra knowledge in C++", it's not template level difficulty, you can learn overloading after a week or two. sure overloading has a lot of thing going on there but at least it in your face instead hiding. you could argue Rust PartialOrd is newbie friendly but i kinda disagree with that even.
This is the first video I have seen from you, and I have to say, it made me sure I want to see more from this channel. Such well present, such cat, such content.
You have a really nice style, keep it up.
Just glancing over the C++ code it could definitely be improved by:
Removing the globals
Removing the horrific macros (for endl specifically)
The constants could be made into constexpr constants (i.e real constants, not text replacement)
Removing the using namespace std
Removing the `typedef` struct (this has never been a required thing in C++, this is pure C)
Replacing the remaining typedefs with using
Adding defaulted comparison operators for the structs that would essentially all be one liners without any user defined bodies (structs are just classes, they can have member functions, even though the operators would be friended and not technically members).
Not much about performance itself which could probably also be improved, just cleaning up the code immensely by following the c++ core guidelines.
Yeah I mentioned in the Day 18 write-up that these solutions felt a lot like "C/C++", not "proper C++", but like you said I don't think any of these actually would impact performance. I would really hate if the original author would get negative feedback from all that though 😬
Thanks for the C++ refresher!
@@fasterthanlime There are lots of needless deep-copies in the C++ code that would certainly effect performance though...
Interesting points, I didn't know that the typedef wasn't needed in C++.
@@Wunkolo Yeah when doing a for each the code should be doing it by reference, i:e: for ( BluePrint& bp : bps ) {
The copies are certainly making it slower.
The content was really great, super informative. It was like reading one of your blog posts but in video form.
I watched the day 18 stream and learned a ton.
Some of the assembly stuff went over my head but that's just because I'm not too familiar with it. But even so, it was explained well. I'll definitely be coming back to watch it again once I know more about assembly.
MIPS Assembly is the easiest to read and understand.
Love your blog posts. Keep doing what you're doing. It's great. 👍
Thanks!! I'm glad I'm finally able to release videos on par with my posts, there was a big gap for a while and the audiences for both didn't intersect much.
Well, that escalated quickly. Came for Rust, got to Assembler. I wish I learned this in the university, it is so fascinating. Makes me think how many decisions were taken for us in higher level languages. Thank you for the deep dive and clear explanation. I feel complete… Turing complete now 😅
Rust's type system, by ITSELF, is turing complete.
@@runed0s86so are C++ templates hehe
Incredible video. I am going to share it with everyone in the company I run! Keep up the ultra-nerdy-geeky subjects & explanations, you are REALLY good at it and makes this kind of high level stuff very accessible to whoever is listening.
This is an absolutely fantastic video! Loved the way you described SIMD instructions! Respect! 🙌🙌🙌🙌
I wish to see an x86 programming tutorial course from you!
Great video and explanation. Love reading your articles, so watching the video was fun.
I was rewarded not just with knowledge, but also with a cat video at the end. Obviously this is now the best video ever.
19:25 😻
I believe the reason that 3×u64x2 uses registers where 2×u64x3 uses stack is as simple as the Rust ABI having a ScalarPair mode to pass scalar pairs (like slice references, or other structs which are just two ints) as two separate arguments. So before LLVM sees it, the function taking 3×u64x2 gets turned into a function taking 6×u64. The 2×u64x3 is given to LLVM as a function taking two pointers.
IIRC LLVM does actually have the ability to pass more complex types than just scalars in function arguments (i.e. virtual registers), but rustc never uses this functionality because the semantics of compound types in LLVM don't line up well with Rust's semantics.
Interesting! Can you expand on "the semantics of compound types in LLVM don't line up well with Rust's semantics"? Preferably in blog post form, 2 pages minimum, no maximum, you have 4 hours ago, ready set go (just kidding, but I would love to read more about this if you feel like posting a link to something!)
@@fasterthanlime for simple and "full" types like u64x3 here, I don't think there's any difference. I honestly know very little, just that rustc only uses LLVM's compound types for field offset indexing and lowers padding to explicit fields. I also think compound types in LLVM may also carry TBAA implications, though that wouldn't matter if only used for passing compound types as function arguments.
The TL;DR version is quite literally just that doing pass-by-reference for all compound types is simple, sufficient, obviously correct, and doesn't impede inlining optimization.
Those are words
heh, "you have 4 hours ago"... gg on making us feel way too familiar within this environment! xD
I love your Advent of code articles! I already picked up some new Rust knowledge!
And your writing style is really nice!
I don't comment very often, but I have to say I really enjoyed this deep dive on why C++ was faster.
Keep it up!
/s? 😂
@@plasticstuff69 Typical Crab
It took a Rust expert digging into assembly to beat a naive C++ implementation (sometimes). So, yeah. Agreed.
if both use llvm as backend, they are similar, if c++ use gcc instead llvm then they can different, but rust can use gcc too, so they are similar. now take a look to the feature, rust give more feature and its design is 100% memory safe, preventing memory leaks that can happen in c++ when building big project with many people that they may forget to delete a variabel after unused.
@@doublekamui exactly what smart pointers are made for
Nice stuff 😁
I remember manually optimizing vector functions in MPI using MMX and SSE commands when this was still the hot stuff and compilers had no clue about them.
Putting in some prefectches here and there to optimize caching helped as well.
That were fun times. 😍
Extremely high-quality explanation, I'll make sure to send this to whoever wants an introduction to the world of assembly and the wild west of compiler optimizations!
Very well made video helped me expand my knowledge on “non basic” assembly. Keep up the good work!
been reading your articles for a while, never knew you had a youtube channel. loving all the content, keep it up!
Thanks! I do link to my latest video at the bottom of every article, but seeing how long my articles are, maybe I should put them higher up 🥲
You're awesome, subscribed. Going to go through those videos on Rust you mentioned at some point. Watching other people code is my favorite thing to do when not writing code.
Really enjoyed this video about the compiler and assembly topics :)
Good job with the video! I'm not too comfortable with assembly but the way you explained with visualisations helped a lot.
I actually used pshufd to move half cat parts to both halves of an XMM register. Beware: if you get the `order` operand wrong, things get weird. Real weird.
Amazing video. Thank you for putting you time into educating people and creating high quality content. I wish more youtubers put as much effort in what they do as you.
This was really educational, for the parts that didn't go over my head. Nice chiptunes, btw!
This was great. I really like these deep dive type of videos!
Great video, Amos! You should upload the x86 assembly and SIMD segments of the video as a separate video also as they are a very good intro to asm
There's still more layers of complexity. Code speed differs depending on whether the instructions/data hit the on-chip cache which in turn depends on the level and size of the cache. Also, optimal alignment of data can make an utterly huge speed difference (address boundary of 8 vs 16 vs 32 vs 64 vs 128). Ultimately, all these factors will be optimized by compiler backends which have been trained by machine learning. I'm an old compiler guy who is spending his retirement on doing just this. I'm betting we can dump LLVM for a machine-instruction-machine-learning-neural-network.
That is true (and way beyond the scope of this video). I remember seeing some stuff re: machine-learning driven register allocation in LLVM, but I have no idea if it's actually mainstream enough to, say, be used by default in rustc. Do you happen to know? I'm curious!
Turn compilers into an even bigger black box! It would be scary if a malicious AI corrupted compilers so that all programs would contain silently executing code to do...something.
@@HansLemurson nevermind those extra skynet instructions
@@StanleyPinchak Just a few socket interrupts and some speculative execution...nothing to see here...
that assembly review was so juicy ty
i want to learn Rust, and later Assembly
and ive always wanted to learn whats going on under the hood
ty, this is exactly what ive always wanted
SUPER interesting video! I learnt a lot :D and I will stick around on your channel hoping to learn more!!
I would love to see more showcase explained in depth like this. Well done!
I love the way you explain function calls and argument passing, it's like a crash course of what the compiler does in "higher level" languages, explained to an audience of 50 year old 6502 programmers hahaha! Really a great way to go about it IMO, well explained but not dumbed down ELI5 style :-)
To include binary data into c++ on Linux, creat the binary file and use LD with the right input file type flag to generate a .o file, that object file will have two symbols for the start and end of the data which you can access by declaring the right arrays with the right names (no length values required) something like unsigned char symbol_start[]; where you replace "symbol" according to the symbols name.
Awesome video! Gonna check out that livestream VOD.
Very informative vid and furthermore you killed me at the end, that's funny ^_^
For the C++ version, I'd suggest making the operator functions static and turning bps into a local variable in main.
5:05 Replacing whatever C++ map you were using with absl::flat_hash_map or some other high performance map implementation would probably have significantly improved the C++ performance. But you're right you need a certain level of experience in C++ to know that the standard library map types are kind of shit for performance.
5:50 In C++20 you can just do `auto operator(const Cube&, const Cube&) = default` and the compiler will automatically implement a lexicographic comparator, like the Rust derived comparator. While this is a fairly recent feature, I would consider it something every C++ programmer should know, just like every Rust programmer should know about derive, because it is so useful.
On one final note, having recently been comparing some C++ and Rust code for performance, I'll say that one Rust feature that can often give it an advantage over C++ is destructive moves, which allow the Rust compiler to make some good optimizations when passing objects by move that would not be possible in C++.
I remember realising how good the STL implementations were compared to mine, when I studied Introduction to programming in university. Tests, I couldn't pass with my implementations, worked times faster with STL. If standard libraries are considered slow, I can't imagine what "high performance" means!
Wow, great video. Both content-wise and presentation-wise
You now have my attention and a sub. Keep doing what you are doing!
Thanks for the great video! I'd like to see how some more complicated language features (such as fat pointer/vtable, or enum vs tagged union) may affect the compiling result and the performance
That would be interesting! My guess is that, like here, they're fairly close. One area where I think we'd see a real difference is noalias, but I need to figure out how to showcase it.
"I felt pretty stupid while reading it, and I wish you the exact same- that just means you found something you can learn about." 2:57
That's a great way of putting it, and it makes me a lot more comfortable learning that I'm not the only "stupid" one when it comes to working with and learning to code. Thanks for that!
Excellent video. Looking forward to your nix series, just sponsored you on github :)
Thanks for your support! The series is taking longer than expected to finish up, but for good reason: I managed to get to a place where I feel like I understand the fundamentals of the language better, so I could see myself making a video about the language itself as a companion piece. We'll see!
This video helped me understand SIMD a lot!
Could you maybe make some sort of x86 explanation series, where you also explain some more SIMD instructions?
That detailed x86 SIMD crash course earned my subscription to this channel. I enjoy hearing experts talk about this stuff!
This is super interesting and the quality of your videos are amazing! Currently going deep into low level representation and assembly and it starts to make sense!
Stumbled across this channel, love the content! Just subscribed.
All hail the TH-cam algorithm, who just decided today it liked me. Welcome aboard!
Just discovered your channel. Pure gold.
What a great video! And most of all, thanks for sponsoring the Cat. 😍
Very good video! I would love more videos covering things like this
I want to go a little bit deeper down this rabbit hole, to see where it leads, but in the meantime you can check out videos like How The Detour Crate works, if you're interested: th-cam.com/video/aLeMCUXFJwY/w-d-xo.html
Well... now i have to lookup a bunch of things. I do some c++ but i never realy looked at the assembly. I guess i should look into it. Also a fun project would be if i compare the LLVM assembly to the GCC one.
Thanks for the weekend project!
Awesome format an ini-depth knowledge. Super useful! Makes me want to pick up Rust now :)
What luck! I know someone who has a website full of articles focused on learning Rust! (the Advent of Code 2022 series is a good start - there's probably enough content on fasterthanli.me that it's disorienting)
was very impressed with how knowledgeable you seemed and thought to myself why I hadn't seen you before but then I saw the channel name and everything clicked haha
That's hilarious. Now you know what I sound and look like!
Awesome video. Really enjoyed it. Keep up the excellent work! Cute sponsor.
Your feedback has been relayed to the sponsor in question, whose only comment was: mrrraw.
usually when someone try to explain assembly my brain shuts down, but with you, amazingly, i got it
Amazing video, thank you so much! You're great at clearly explaining these sorts of concepts in a calm and constructive way
Ah crap, that's right! This is why you don't go off-script!
@@fasterthanlime But you clarifying it as "the function calling the other function" clears up any potential confusion it could've caused, so it's all good
Also I wrote that comment before finishing the video, and I really didn't think I could love it even more. But that ending with "if you ever meet a compiler engineer in the wild, ask if they need a hug" and the sponsored by cat segment are fucking amazing
How did it take the algorithm this long to show me your videos. I've read all your articles as I see them show up on Reddit. Happy to see your videos are just as interesting.
Excelent, excelent video, superb analysis of produced machine code as well. Your Rust content never fails to deliver.
Top tier content. Yearning for more!
I have a few other good ones, but be warned that as you go back in time, you'll see myself get worse and worse at script writing, performing, shooting, and editing. Thanks for the kind words!
@@fasterthanlime This format really with fluid and beautiful code presentation while diving deep into interesting concepts of computing is surely the best match for my tastes, but I still really enjoyed some of your other videos and they are all really good so.. thank you for your hard work!
Great explanation Amos 🚀 I really love your style of both writing and recording.
What is the font used for your website URL in the "Thanks to my patrons & sponsors" slide?
That font is Bitter, you can find it on Google Fonts.
Great video with good illustrations, thank you!
LOL the intricate depth of compilers and optimizations. great video
This is an awesome video. Great work!
Very interesting video (you earned my subscribe). One thing that I was a bit surprised at (though my experience is with c++ in the g++ ecosystem, so forgive any ignorance); Based on you comparing how the calls were made (compiler's choice in how to marshal the parameters, that meant that your final profiling was done without externing the functions (as you mentioned at the end of the video)), but Im pretty surprised that the function existed at all. g++ generally has a very aggressive optimizer for single file non-externed programs. In most cases that Ive seen, those functions themselves should be optimized away so you are left with just the actual meat of the functions without any functional overhead.
If it's not doing it on it's own, maybe try adding a forceinline to the function declaration (I know it's technically not standard c++ but the biggest compilers do support it) (does rust have an equivalent)? It would be a really interesting optimizations experiment to see how they compare once the optimizer is allowed to view the entire program at once.
Rust does have #[inline(always)], but it wouldn't help here since the function is recursive (and not tail-recursive, unfortunately).
The code for both the C++ and Rust version is linked in my top level comment if you want to play around with it yourself!
@@fasterthanlime Oh, I must have missed that in the video. I will for sure check out the code and play around with it if I get a breather during work this week. Keep up the good work. Despite being a huge c++ advocate, I am really looking forward to the day when I do move on to a language without the metric tons of baggage. I will definitely check out the rest of your videos.
@@fasterthanlime why not pin the comment with the link though? it's starting to slide down...
Also, i'm not getting your point. The backtracking function is recursive, sure, but not the operator+, which is what J said would get optimized away (in-lined instead of f-called).
Not that I have understood everything that you said - my knowledge cannot keep up with my enthusiasm 😁 - but, I have learnt a few things. More pertinently, the effort you have taken to prepare the material, deserves a sincere applause! Thank you very much.
Your setup looks nice, clean and elegant, good job
I have encountered assembly briefly from looking at some disassembly projects in the video game preservation community.
Anything that helps me understand what is going on with assembly in practical and easy-for-newcomers terms is really fascinating and helpful to me. Want to know what those Game Boy Color games were doing under the hood!
Thanks for this video, seems really impartial but also very human. Just what I like to see in the tech space. Heart > factionalism! Neutral reviews of the tech can both serve as documentation *and* impetus for those who are closer to the tech to maybe improve the state of the art based on really having the problem laid out in front of them. Takes you out of the fog and makes you go "hmm, yeah, maybe that thing right there".
just pointing out -- on the programming language benchmark game website, you have to scroll all the way down on the toy program page (n-body page for example) to find the unsafe solutions, where you will find even faster submissions. For example, at the time of writing this comment, the fastest is a C submission which is twice as fast.
ty for teaching me to keep my structs even, avoiding odd when i can
This was the first video I watched and immediately subscribed. This content is amazing! Super well explained.
Great explanation, I haven't seen any video that explains low level computer wizardry this well.
I did AoC as well last month, and it improved my programming greatly, though it's clear that I still have a hell of a lot to learn.
Best sponsored segment ever!
Now, this is the tech content we crave!
Great video, as usual! A bit disappointed that I can't use a discount code with cat, but the information more than makes up for it. Wanted to ask, could alignment have something to do with the compiler's choice of using SSE registers, or may that be just because the size is bigger than 16 bytes and the compiler just treats smaller structs as a special case? Though otoh smaller structs could also mean say [u8, u16, u8, u32, u32]...
I think it has more to do with the latter: heuristics based on the maximum argument size the compiler is willing to pass by registers. But I don't feel comfortable making these claims without doing a bunch more research.
Re SIMD, note that the compiler is using movdqu, the unaligned version. I don't think there's any guarantees the struct will be 16-byte-aligned, but I may be talking out of my butt.
Fantastic content!
11:00 You actually can't have "more complex expressions". Both the number of registers in the expression and the specific registers that can b used are fixed. Each full expression is a different addressing mode, which is (ussually) a completly different instruction opcode, and not an operand change. x86_64 registers are much more "general purpose" than x86 registers are, but there are still some instructions that only operate on certian registers.
From a machine code perspective, sure! The specifics matter less when writing (or reading) assembly, and I haven't even shown multiplications in there. That said, nit picking is very much in the spirit of this channel, so thank you!
Great video, thanks for the depth. How long did it take you to produce the graphics and edit all this? Great job man.
2.5 days of editing.
You're one of the best content creator in the programming field, I've seen matching quality only from Sebastian League and that's really something
Amazing vid thanks
I'd open an issue on that or reach out to one of the core devs. That seems like an oversight from the compiler team. Has to be some issue with the IR code that's generated not playing nice with LLVM
So a friend of mine who's a rustc contributor looked into it some. This is the closest report I could find: github.com/rust-lang/rust/issues/26494#issuecomment-619506345 - according to them, it's an extremely common report with no easy solution, most PRs to "fix it" introduce regressions 🙃
the ScalarPair ABI in rustc might be slightly suspect here too - it makes 2-element structs special
@@KaneYork that seems likely - it's probably what my compiler friend tried to explain to me and it flew right over my head.
@@fasterthanlime solving this seems like it is related to the bin packing problem only a little bit more complicated because of things like alignment requirements.
Interesting! Good video. Followed.
Wow! I just saw Compiler Explorer from your vid and tried it out while watching you. It's actually pretty good.
Thank you YT algorithm for recommending me this video and thank you @fasterthanlime for this vid. I subscribed and look forward to more awesome programming videos. :)
elegant but hardcore assembly deep dive, very few coders have such advanced knowledge on programming
Good video. Sometimes I'm digging into machine code generated by LLVM, and I assumed - INLINE ALL if you want performance😊 Otherwise you will see strange glitches with argument passing / register usage like it was described in this video
Wow. I got so much useful information than I thought when I clicked this video.
You really should get much more subs! Thanks for creating good contents :)
Thanks so much! I put a lot of effort into these and I hope it shows :)
I think that it's important to consider the development time of the application, when talking about speed. Which is why Javascript is so popular, despite being slower than C++.
Rust seems to be an amazing middle ground with speeds that compete with well written C++ code! Thanks for the video.
Oh definitely. You should also take into account maintenance costs, otherwise you end up with Go 🙃
@@fasterthanlime I used to write some small scale programs in Go 2-3 years ago, switched to Rust since. Can you elaborate how Go programs grow unmaintainable that‘s specific to the language?
I am just curious.
“It’s been an ongoing fight, according to sources who are very tired.”
Literally almost spit out my drink. That is some quality wit, characteristic of this whole, excellent video.
Oh no, at the end I thought you were gonna ask about one struct with four fields and another with two! I vaguely recall something about field structs in the sysv abi, so your three structs each with two fields doesn't necessarily test just even/odd stuff
Great explanation. Very interesting dissection.
Very high quality content. Nice!