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.

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

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.

I remembered Go.

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

Sometimes it's even the other way around! ...if you know each other well, of course.

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.

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

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.

compilers are AI

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.

MIPS Assembly is the easiest to read and understand.

What language are you creating the compiler for?

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.

Rust's type system, by ITSELF, is turing complete.

​@@runed0s86so are C++ templates hehe

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 🥲

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

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

/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

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.

19:25 😻

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!

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.

All hail the UKposts algorithm, who just decided today it liked me. Welcome aboard!

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: ukposts.info/have/v-deo/mXyWgXmMj3x72I0.html

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!

That's hilarious. Now you know what I sound and look like!

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

That font is Bitter, you can find it on Google Fonts.

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

2.5 days of editing.

Your feedback has been relayed to the sponsor in question, whose only comment was: mrrraw.

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)

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!

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.

potentially rust and c++ can be "lowered" to pure C by the programmer will 😄 It's true - performance comparison for rust and c++ is nosence

Thanks so much! I put a lot of effort into these and I hope it shows :)

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!

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.