Great post! Just to add on, as someone already mentioned, it's best to compare production-ready builds. On my machine, Rust in debug mode runs at 1.6s (similar to your results), but in release mode, it finishes in 0.2s-about 8x faster!
@@xep14_88 I tried the rust code with the release option and compiled the c++ code using the -o2 flag which enables speed optimizations. The result with the existing code was that the rust code was about 0.05 milliseconds faster. That said I changed all the ints to int32_t (which is the one that rust uses) in c++ and the speed differences were negligible. While testing the differences were linked more to the system's load at the moment than the code itself. I tested it with cl in windows and g++ in linux, same result on both. Maybe we should try to put the code on a loop for a million or more times and keep track of min/max/average execution time of each iteration.
rust debug mode is very slow because rust does far more checks in the run time, run rust with all optimizations enabled and in release mode then test the speed
@@97wowplayer I did watch it you used a different code there and not the same one here but I have tested that code locally as well and I have left a note under the video on my observations.
@@wassim-akkari I tried the rust code with the release option and compiled the c++ code using the -o2 flag which enables speed optimizations. The result with the existing code was that the rust code was about 0.05 milliseconds faster. That said I changed all the ints to int32_t (which is the one that rust uses) in c++ and the speed differences were negligible. While testing the differences were linked more to the system's load at the moment than the code itself. I tested it with cl in windows and g++ in linux, same result on both. Maybe we should try to put the code on a loop for a million or more times and keep track of min/max/average execution time of each iteration.
I tested the aglorhythm on PHP 8.3 on my laptop. In the range up to 100,000, the program execution time took 0.15 sec. In C++, a similar algorithm worked in 0.011 sec.
In cpp on M1 with -O3 level compilation the result is like > Primes: 9592 > Elapsed time: 1.54812 milliseconds the typescript equivalent running by BunJS is > Primes: 9592 > Elapsed time: 154.662083 milliseconds I guess TS result could be better if JIT would take an action but the code is not so heavy to involve it
@@97wowplayernot sure if debug mode is a good idea for perf testing. Different compilers have different optimizations enabled by default. For a fair comparison imo, you have to give both compilers their fair chance by enabling all safe optimizations. Especially, because rust sometimes has quite some intensive compile time.
@@97wowplayer why are you comparing the speed of 3 languages in debug mode? the compiler adds a lot of garbage to make the code debuggable, this same code in c++ with optimizations enabled, the compiler would remove the loop and simply show the final result
being c++ a stronger typed langague than the other two, your function isprime() should return 1or 0 instead of true or false being casted to int on return. this way you can add the results without any worries.
why not run cargo with --release flag? On my machine in debug mode it takes 2 seconds and in release mode it ran about 0.8 seconed. on the other hand C++ in -Ofast flag takes 0.851 second which is little slower than rust.
It's wrong to compare languages because of implementation. I can write python code that runs faster than C code. Python is C under the hood, it's like comparing the mass of a car to the mass of its engine.
Change algo to only count to sqrt the number, that is the highest factor. Save that to a variable for the check on the for loop. The compiler should optimise it, just double check.
I just tried to do this in Kotlin for fun and I got... "Found 9592 primes in 0.841438700 seconds". Can anyone tell me why so? I did similar tests with Java/Kotlin/C++ about a year ago and found that in some cases C++ is even slower than Java or Kotlin. Is the speed of low-level languages a conspiracy theory?
Java/Kotlin/C# will all compile to machine code before the execution. Either by AOT or JIT. Technically they should be able to produce a performant machine code specific to the machine they are running on, well as in C++ case as far as I know that is not the case. Although I can't think of a case where either one would perform better than the other. For example if Intel releases a new CPU with some instruction for some kind of mathematical function C++/C#/Java compilers will be updated to support that particular instruction anyways. The difference is that you would have to recompile the C++ program with the new compiler.
Nice, but you've lost the great opportunity of running Rust and C++ in release mode afterward, with all optimizations enabled, and actually comparing the speed of both compiled languages in this case.
Great post! Just to add on, as someone already mentioned, it's best to compare production-ready builds. On my machine, Rust in debug mode runs at 1.6s (similar to your results), but in release mode, it finishes in 0.2s-about 8x faster!
Thank you, you can check if you're interested the release mode comparison video I made, however it's using a different algorithm for testing.
@@97wowplayer you made the mistake, delete this video
@@xep14_88 I tried the rust code with the release option and compiled the c++ code using the -o2 flag which enables speed optimizations. The result with the existing code was that the rust code was about 0.05 milliseconds faster. That said I changed all the ints to int32_t (which is the one that rust uses) in c++ and the speed differences were negligible. While testing the differences were linked more to the system's load at the moment than the code itself. I tested it with cl in windows and g++ in linux, same result on both. Maybe we should try to put the code on a loop for a million or more times and keep track of min/max/average execution time of each iteration.
rust debug mode is very slow because rust does far more checks in the run time, run rust with all optimizations enabled and in release mode then test the speed
I have another video which compares release mode rust vs c++
@@97wowplayer I did watch it you used a different code there and not the same one here but I have tested that code locally as well and I have left a note under the video on my observations.
@@wassim-akkari I tried the rust code with the release option and compiled the c++ code using the -o2 flag which enables speed optimizations. The result with the existing code was that the rust code was about 0.05 milliseconds faster. That said I changed all the ints to int32_t (which is the one that rust uses) in c++ and the speed differences were negligible. While testing the differences were linked more to the system's load at the moment than the code itself. I tested it with cl in windows and g++ in linux, same result on both. Maybe we should try to put the code on a loop for a million or more times and keep track of min/max/average execution time of each iteration.
I tested the aglorhythm on PHP 8.3 on my laptop. In the range up to 100,000, the program execution time took 0.15 sec.
In C++, a similar algorithm worked in 0.011 sec.
How fast you can type out the code is a useless metric.
É verdade para isso existe o copie e cole. A métrica está no tempo de execução.
Not really if he's typing out at a constant speed
More time is spent optimizing the code, business rules and refactoring than just typing the first version of the code.
C++ is the best of all times
phyton and java are for dummies
Learn C/CPP from top to bottom, from inner to out and you will solve 90% of the tasks.
Suggestion: to completely remove the impacts (if any) of time measurement across languages, I would measure the execution time in the shell instead.
but python need to load much more things, is already slow yet
C++ performance depends on settings, optimization and compilers. If you twist the C++ ear or bite the tail, then see what happens?. 🌹🌹👌👌
Ok can you further explain this?
In cpp on M1 with -O3 level compilation the result is like
> Primes: 9592
> Elapsed time: 1.54812 milliseconds
the typescript equivalent running by BunJS is
> Primes: 9592
> Elapsed time: 154.662083 milliseconds
I guess TS result could be better if JIT would take an action but the code is not so heavy to involve it
rust release mode?
nope, all 3 are on debug
@@97wowplayernot sure if debug mode is a good idea for perf testing. Different compilers have different optimizations enabled by default. For a fair comparison imo, you have to give both compilers their fair chance by enabling all safe optimizations. Especially, because rust sometimes has quite some intensive compile time.
I'm planning on making a video with release mode and showing the speed differences
@@97wowplayer why are you comparing the speed of 3 languages in debug mode? the compiler adds a lot of garbage to make the code debuggable, this same code in c++ with optimizations enabled, the compiler would remove the loop and simply show the final result
@@ensuretime I am planning on making a release mode version to compare the 2 types of modes
being c++ a stronger typed langague than the other two, your function isprime() should return 1or 0 instead of true or false being casted to int on return. this way you can add the results without any worries.
Azar tens que querer três
Estou a ver 3 quadros deveriam serem ovais ou redondos quais?
why n/2 ? should be sqrt(n)
n/2 is probably easier to understand for those who don't know about sqrt(n).
why not run cargo with --release flag?
On my machine in debug mode it takes 2 seconds and in release mode it ran about 0.8 seconed. on the other hand C++ in -Ofast flag takes 0.851 second which is little slower than rust.
blazing fast🚀🚀🚀🚀😎
Thanks @urparvezali After watching this video i feel demotivated that again wasting my time in slow language like one more golang
Do the same for C++ also in release mode and you will see the difference.
What the hell kind of comparison are you making? Python is an interpreted language, while Rust and C++ are compiled languages!
and?
and how does that mean you can't compare them? ofc python will obviously be slower but that doesn't mean it's wrong to compare the languages
It's wrong to compare languages because of implementation. I can write python code that runs faster than C code. Python is C under the hood, it's like comparing the mass of a car to the mass of its engine.
@@AndrewI-n5l you mean you can not write phyton code that runs faster than c.
python can be faster near to c if dont rely on pure python coding, use cython to optimize heavy computation
0:13 Typing time is different from program running time. so it is useless to compare these two
Hi! Enable multithreading in Python 3.13 and do a speed comparison Python 3.12 vs Python 3.13.
Great idea!
Will do it in the future! Thank you!
Hey, the requested video is up, you can check it out!
@@97wowplayer Hi, thanks!
Develop by python
Transfer C by AI
Run in C
C++ Rules!
Change algo to only count to sqrt the number, that is the highest factor. Save that to a variable for the check on the for loop. The compiler should optimise it, just double check.
in rust build --release
To see accurate results, try getting N from stdin. I think it’s obvious that C++ can't be slower!
How about pypy? I know it is faster than python.
The C++ code turned out to be cumbersome, it must be done in C, the printf function is simpler.
What abaout php?)
3 times faster than Python.
It's wrong result. Why did you use UNOPTIMALIZED builds for the speed test?
python
for i in range(1, 100001):
cpp flexes with its speed
and at runtime? hehe
C?
What are using IDEs?
CLion for C++, RustRover for Rust and PyCharm for Python
Yup python takes least human time. Python is most performant.
I just tried to do this in Kotlin for fun and I got...
"Found 9592 primes in 0.841438700 seconds".
Can anyone tell me why so? I did similar tests with Java/Kotlin/C++ about a year ago and found that in some cases C++ is even slower than Java or Kotlin. Is the speed of low-level languages a conspiracy theory?
Java/Kotlin/C# will all compile to machine code before the execution. Either by AOT or JIT. Technically they should be able to produce a performant machine code specific to the machine they are running on, well as in C++ case as far as I know that is not the case.
Although I can't think of a case where either one would perform better than the other. For example if Intel releases a new CPU with some instruction for some kind of mathematical function C++/C#/Java compilers will be updated to support that particular instruction anyways. The difference is that you would have to recompile the C++ program with the new compiler.
Nice, but you've lost the great opportunity of running Rust and C++ in release mode afterward, with all optimizations enabled, and actually comparing the speed of both compiled languages in this case.
That's true, but thanks
rust without iterators and debug mode :(
I wanna be programmer ❤
You forgot to plug in name space std; to shorten the program. C++
Before space:
Std::cout
I heard on the grapevine that pypy is faster, that its speed is comparable with c++
Господи, чел сравнивает скорость написания кода
Man, i really hate the FAKE KEYBOARD SOUND, use instead some music idk but man, that sound is awful cringe
You don’t have to watch
@@joel9909 bro, if i put play on this video is because their main topic was interesting
Point taken
Se calhar são 2 mais engano
с++.........UB
What a joke of a video, I thought they were about to compare the execution speed, who the f cares about this
Compare with vlang)
thanks for the suggestion, I will look into it
vlang transpile to c. of course, faster then go/rust. 😂
@@onyvid9557 😂