The frist example is weird and bad because it illustrates a user's ineptitude, instead of just focusing on how rust requires a few more keystrokes. Nobody would use clone() before using &borrow. Also, you wouldn't be using "more and more" memory for each clone(), because each cloned variable would drop at the end of the greet() call, you would just be wasting cycles by creating and dropping the same variable. The point still stands, the fact that you need to put a little more effort in but your code is more manageable over the long term, but it's a strangely made point.
Your explanation is great. Here is my doubt, I have written a program that has 4 threads between every thread busy waiting on the segment queue. We are creating a packet in one thread and passing via queue to another and processing something in every thread and that packet processed in the last thread and we time stamp at every thread. Total 1million packet processed. We have written a similar program in c++ also. Performance : MACOS: rust : 2.9sec c++ : 2.7sec LINUX rust : 15sec C++ : 3.3sec Why rust is too slow in Linux. Can anybody help me to solve my problem, I have used every compiler optimization of everything, still nothing happens.
With the 1st and 2nd cases the word "biased" immediatly poped up in my mind, how you use silly things to pretend that rust is better. The simple fact you ommit things like references "&" and " the "const" keyword in C++ that not only tell us if the contents of a pointer will be changed but also tell us if the contents of where is pointing too will be changed.
I'm relatively new to Rust but I'd say in this example there is no "real" difference between C or Rust in terms of writing the implementation. The Rust code was easily readable to me, even as a beginner, because I am familiar with the syntax (I was screaming "just pass a reference" like 20 times) because thats what I am used to. And tbh the C code seemed to do the same (char *). The difference likely lies within a lack of dedicated Rust libraries C/ C++ had for decades and being forced to handle Results / Options, Err etc. whereas C will let you do whatever. This will be a negative for short POCs but in large code bases you will implement the exact same things that are standard in Rust anyway
"Rust is more modern than C and C++ thus is able to have faster default implementations of data structures" -> Oh come on. This has nothing to do with Rust being modern/new. There are currently (if I am not mistaken) 3 implementations of the C++ stl (msvc, gcc, clang) The C++ STL usually describes the data structures in general and doesn't force a specific algorithmic implementation for containers. Moreover, you just tested one data structure. Lastly, one can find very good C++ implementations of any data structures one desires if the STL ones don't fit their needs.
C code @3:20 is incorrect. The divide function definition has an integer pointer as first parameter. So when calling the divide function, you pass with & a normal variable not a pointer to the divide function. int a = 20; int return_value = divide(&a, 4); printf("%d ", a);
Outside of the code writing I believe that Rust is great for teamwork because of the config file, the toml I think. Just type in whatever dependencies you need in there and cargo will do it all for you, all the correct pakages, the correct version of Rust you want and then cargo run, kinda like Python venv. So not only does Rust code is explicit and precise, but the way Rust manages itself is just so good, any team member with Rust installed can just take that toml file and run it, and they are set.
When's the next video my dude? You've got everything here that makes a great channel, what are you currently passionate about? Tell us about it! 😄 (My only feedback, if I may, would be to use a better mic, don't buy one, just use your phone's microphone like I demo in my "how to sound great" video) Looking forward to seeing more!
Thank you, that means so much coming from the best! I will definitely follow that advice if I end up making another video. I was having a lot of trouble with my adsense account which was killing my motivation, but hopefully the situation can be resolved in the future. Until then I will learn as much as possible to have some material for the future! ;)
U can't just say "when we benchmark" show an actual benchmark and compiler details... I would bet c usually wins if u choose a good hashmap especially if u optimize for ur data distribution
The speed of Rust depends a lot on what your code actually does. I have a small test benchmark that performs fractal calculations, no fancy objects or structures are involved except arrays, and this code runs 10% faster in Rust than in C, who would have expected that? However, if I modify the benchmark to compute many more fractal values that all need to be held in memory, the Rust code is suddenly 20% slower than the C code. Sure, in the end it's all LLVM, but there are certain operations that are faster in LLVM than others, and certain combination patterns cause more code than others (e.g. because of extra checks or more cleanup at the end of a function). Rust is neither guaranteed faster nor guaranteed slower, it all depends on what your code actually does and how your code does it, and how well the compiler can optimize away the things that would otherwise make Rust slower, or how much the compiler can benefit from making assumptions about data or code flow that it can only make in Rust but not in C, where those assumptions end up leading to better CPU code. Since Rust is much more complicated under the hood than C, the final speed will always be a kind of gamble ("Oh, if I change this, my code will be 60% faster... I didn't expect that"), whereas speed in C is predictable most of the time ("It was clear that this will be faster than that"), but that still doesn't mean that C will always end up with the best performance, as C simply provides less meta-information for compilers to work with, so compilers can't always figure out the best optimization path, as they simply have less understanding of what's really going on, or they have to be prepared to deal with exceptional cases, which may be guaranteed not to happen with comparable Rust code. The takeaway is that for a way safer and way better typed language, Rust is often comparable fast, but in most cases it will still be slightly slower, so you are trading a tiny bit of speed for way more safety. My biggest grief with Rust is that I already disliked C++ just because it's syntax is so ugly but the syntax of Rust is even worse.
There is nothing unsafe about C. People simply don't know how to use it. I also doubt that Rust can beat properly optimized C code if the compiler optimizations are the same. It might not even be the code. Individual results might have something to do with cache hit/miss rates or pipelines rather than the actual code. Even LLVM can not optimize that since it's strongly data dependent.
@@lepidoptera9337C is unsafe because its memory model is unsafe. Unless you use C11 atomics (which didn't even exist prior to 2011), C provides no guarantees about memory access at all. The problem is that every platform/CPU has its own memory rules and you would have to make sure to write C code that follows those rules but since those rules vary by platform/CPU, it's actually not truly possible to write C code that is guaranteed to work correctly on more than one platform. If it does, that's plain luck. Modern programming languages like Rust, Swift, Go and even Java and C# do define a memory model as part of the language that is valid for all platforms the language supports. It's up to the compiler/interpreter to ensure that this memory model works as defined by the language on the platform, no matter what is required to make that happen. The programmer doesn't have to adopt his code to any platform for those, the programmer can rely on what is defined in the language standard. Here's a very simple example: You have a global variable of type int, whose value is currently 0 and you change its value to 10 in thread A. 30 minutes later, the variable has never been touched ever since, you read the value of the variable on thread B, what will the value be? 10? Show me where the C standard makes that guarantee. Fact is: It doesn't. Prior to C11 C didn't even acknowledge the existence of multiple threads. But even without threads: You only have one thread, that runs on CPU 1 and you write a value, 30 minutes later the SAME thread runs on CPU 2 and reads the value. Again, where does the C Standard guarantee that CPU 2 will see the value that CPU 1 has written? It doesn't, because C does not acknowledge the existence of systems with more than one CPU. And what applies to CPUs also applies to cores of a single CPU. Only when using atomic variables as defined by C11, there now is a memory model and you as programmer can even choose between 6 different memory models but for everything that is not atomic, nothing is defined. Without atomics, the way you think C works in fact only works if all your code is always running on a single thread only and your system only has one CPU core or if you are lucky and the CPU does make that guarantee in hardware; like x86 does most of the time but PPC, ARM, Alpha, RISC-V, etc. doesn't make those guarantees. That's why so much C code that worked flawless on x86 CPUs fore decades suddenly breaks when it has to run on other CPUs. The code was never correct in the first place but x86 is very forgiving and gives a lot of memory access and ordering guarantees that other CPUs don't. So you basically had C code, that was valid for x86 in particular but that doesn't make it universally valid, as there is no such thing as universally valid C code, because C leaves most definitions to the system, instead of defining it to the language. This is also true for plenty of other situations. E.g. what happens if a signed int overflows? Not defined in the C standard. What happens when you de-reference NULL? Not defined in the C standard. What happens when you shift a 32 bit integer right by 32? Not defined in the C standard. Of course, on every platform the behavior is defined but the definition varies by platform, that's why modern languages define it as part of the language. As for performance, I have a C code sample, that calculates a Mandelbrot set. It's as basic as this calculation can get (three for loops, an array of float values, some simple int and float calculations, one static function being called from within the main for loop). When I compile it with clang using -O3, the code runs slightly slower as when I take the code as is, convert it to Rust (which almost requires no adoption, except for the data types and the function definitions) and compile it with the Rust compiler. Reproducible on x86 and on ARM CPUs. If RU-vid would allow external links, I'd show you the code and I take any bet, you cannot make the C code run faster than than the Rust code, as there is nothing you could optimize about that code and there is no better optimization than -O3.
@@lepidoptera9337If I could post links here, I could show you a simple Mandelbrot calculation code that will run faster in Rust than in C and I bet that there is nothing you can do to make this code run faster in C, as this code is minimalistic and there is nothing you could optimize that the compiler cannot optimize 100 times better than you and still Rust always wins on x86 and ARM with both compilers set to maximum optimization. And C is unsafe because it does not define a memory model (only for atomics which only exists since 2011) and it also has tons of undefined behavior, where the C standard simply does not define what the outcome of an operation will be. This makes it very easy to port C to any platform but it also means that the same code will not behave the same on different platforms. Modern languages have a well defined memory model and well defined behavior and it is the task of the compiler to ensure this behavior on all supported platforms, no matter what is required to make that happen, so you can rely that the same code will produce the same results on any platform.
rust without llvm and gcc doesn't even exists and this people are morons XD all their code works with or thru c++ yet they don't like c++ and c cuz they are just bunch of looser typescript developers who never heard of memory managinG XD their brain cannot just process the new info about compuer science : D
It is trivial to avoid that. If it happens to you, it's basically just a feedback from the compiler that you don't understand what you are doing. Nothing to fear. You just have to start learning.
segmentation fault came from OS not from c lang kid . it has nothing to do with c . its comes when some morons code and they don't know what they are doing XD
@@amuldoodh556 True. It's a system error originating from the MMU that tells you that you are poking around in the wrong memory location. Ye shall not write random numbers into a pointer. No big deal. ;-)
3:40 In bigger coding projects you should always specify function parameters as they are intended to be used. For example making param1 in your div() function a pointer to a constant value. int div(const int *param1, ...) if it is read-only
The 'problems' C and C++ face are the problems Rust will also faze if it survives for that long. Compatibility with older versions is important. The performance/productivity graph dont have any proof behind it, it is subjective. Rust looks more like JavaScript then C/C++, ...
javascript with crapy syntax at least in js you aren't forced to use crap things you can use just variables and functions and never use class or anything like that X
This is what I hate about rust. say you want to make a function that takes an int, since it's 8 bytes or lower, it takes less time to copy than to allocate a pointer, (assuming references are pointers in rust) thus i'm either forced to copy memory twice or declare a pointer twice.
@@dynfoxx This is only the case for what I said in cpp, but it still applies to data in general. Otherwise everything would be refed. But you never seen an int referenced in a function, or any basic number.
I'm pretty sure C++ standard doesn't specify what algorithm should be used for a hashmap and afaik the implementation in GNU libstdc++ is faster than the one in Rust EDIT: I just tested it with 5000000 insertions, this is the time: C++ (g++): 309 ms C++ (clang): 249.406 milliseconds Rust (rustc): 394 milliseconds
agree 100% on this. i ported a lot of code over from c++ to rust. sure, there is a learning curve and you have to learn a lot more than porting to some random plastic language like python, swift, kotlin, dart and so on, but it's worth it.
RU-vid recommended this video to me again, and watching it a second time just shows more of the flaws in logic: Twitter developers re-writing something in Rust faster than refactoring C code doesn't tell us anything about whether the C code was good, readable, or idiomatic - It could, but it is more likely just telling us that these particular devs didn't understand it as well as they understood Rust. Then the video switches to "well the default hashmap library in rust is faster" without discussing why that is so - hashing algorithms can be as specific or generic as you can make them, and it is all about tradeoffs - maybe "cody's random hashmap" library is actually better for a particular use case than the standard Rust hashmap, but there is a performance cost that is worth it in the long run - the only way you'd know is reading the code or the documentation to find out - which is the same thing regardless of whether you use Rust or C for your implementation.
As far as I am concerned, you do not have to clone tha string over and over again. You can use &str (string slice) which basically creates a copy, however it deletes itself after the call, thus not overloading the memory, so the clone example is not right, imho.
In the 2nd C code example, whoever made that code should use const to denote when an argument in a function isn't changed. However, I do agree, that it's better in Rust to have a variable declared explicitly as mutable, instead of relying on a human to follow the C coding standard of using const whenever possible without error. Sometimes you really just forget and C doesn't raise an error for that (but maybe a warning?). There's also the fact that when using Lambdas in C++, the captures are constant by default, so you have to use the `mutable` keyword instead, which is the exact opposite of the existing standard of using const wherever possible. People say C++17. 20, 23 etc. come with great improvements, but honestly, it's getting weirder overall. Or there's std:forward, which finally lets you fix move semantics introduced in C++11 where std:move didn't always "move" your data as it implied, it just passed stuff as an rvalue ref, and then when you use it in a function argument, in the body of the function the rvalue ref becomes and lvalue object containing the rvalue ref, so you're invoking copy-constructors again, even though std:move itself was introduced specifically to reduce the amount of deep-copies. I could've just used a good old raw C pointer and simply reassign data pointers in the move constructor to move data. It's just 2 lines of code! But noooo, you're not supposed to use raw C pointers, those are scary and evil! While smart-pointers are a nice thing, all this bs could be avoided if people would just quit being plebs and learn proper pointer semantics and patterns, and then you don't have to spend years learning the weird nooks and crannies of the MASSIVE C++standard library. Again, I realize the issue here is that even though you know what you're doing, humans could just simply forget and C/C++ won't throw you an error for it, unless you use smart pointers. Iterators: god forbid you change the length of the container you're iterating on by inserting or removing, because that will wreck your iterator and get a runtime segmentation error. We're talking about the STL iterators, which are specifically designed to work with STL containers and the rest of the standard library, but actually they don't! This is trash! Again, I could use a classic loop with C pointer set-up and it would be both safer and faster for just 1 extra line of code! Modern C++ literally just introduces new points of failure and slower performance for the small, tiny payout of having slightly less boiler-plate code, but if you do actually use every modern C++ feature, then your code looks like Haskell and it's unreadable.
These attributes exist because the compiler can not know how you want to use a piece of memory... as a variable or as a constant. There are good reasons to store constants in a different area of the memory than the variables. C let's you chose that (and a lot more). Rust does not, as far as I understand. It makes educated guesses for you, which may or may not be correct.
Not convinced by the hashmap example. If the performance is so critical, I would go for gperf, not some random hashmap lib and definitly not c++ stl hashmap. And that's is just if I don't have time. Otherwise, I would implement it myself, and that's when C and inline ASM truly shines. Also comparing C to Rust is kind of like comparing apples to oranges. Comparing it to C++ is a bit more "fair".
