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
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.
@@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
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.
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.
Naah, slowness. C++ /w SSE intrinsics should be here as well, possibly C++ /w DXC but that is an overkill (huge time to code, which is not a problem as everyone also has their own wrappers for the longer stuff, and bullet-fast execution).
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.
Although the above isn't a good example, in the real world, with expertly written c++ code, the compiler can do far more precomputation at compile time.
Ok aunque tardas más escribiendo es más rápido corriendo imaginó porque es un lenguaje de bajo nivel y se ejecuta más rápido en el procesador felicidades
Inicio la guerra de los lenguajes 😂😂😂, hay al menos 6000 lenguajes y toda la vida salen con estos temas, que va a morir c++ o Python y que ahora es Rust, 😂😂😂
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.
If two languages has the same features to use the underlying hardware like multi core, multithreading programming usage comparing languages in regard of Speed is bullshit, it depends on the programmer and the compiler or interpreter. The computer does not RUN Phyton or c or c++ code it only runs machine code. Please author dont waste your time and our time with this kind of crap
You should be mega lamer to make binary on rust working slower that on C++. First next time make program on VIM and tests on Linux and yeah... publish -march parameters.
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.
It depends on the vary of applications thus we chose the correct language! Thanks for your cool video!
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.
Learn C/CPP from top to bottom, from inner to out and you will solve 90% of the tasks.
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
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.
This video has no use, you can't compare Rust when it's not in release mode ...
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
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
Didn't know I was messing around with such a fast language
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?
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.
Unoptimized speed comparsion? Why?
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
C++ Rules!
could you also test Mojo?
Sure
What should I compare it with?
@97wowplayer I'd say C++ and Rust
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.
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.
why n/2 ? should be sqrt(n)
n/2 is probably easier to understand for those who don't know about sqrt(n).
sqrt is expensive lol it should be *0.5 its faster than divide
To see accurate results, try getting N from stdin. I think it’s obvious that C++ can't be slower!
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
You only need to iterate up to sqrt(n) (inclusive) for the prime check algorithm.
What abaout php?)
3 times faster than Python.
Naah, slowness. C++ /w SSE intrinsics should be here as well, possibly C++ /w DXC but that is an overkill (huge time to code, which is not a problem as everyone also has their own wrappers for the longer stuff, and bullet-fast execution).
can someone suggest where to practice c++ for begineers
Leetcode or Codewars
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!
What are using IDEs?
CLion for C++, RustRover for Rust and PyCharm for Python
can you try this in assembly
@@Perceptron-bz4nl I will.
Do you want me to compare all 4 languages or just assembly with one of these?
cpp flexes with its speed
Azar tens que querer três
Estou a ver 3 quadros deveriam serem ovais ou redondos quais?
in rust build --release
The C++ code turned out to be cumbersome, it must be done in C, the printf function is simpler.
We have std::print now. Though if you test on godbolt this bumps up compile times a bit compared to printf
python
for i in range(1, 100001):
Yup python takes least human time. Python is most performant.
Depends on how often you need to run the code. Are your users waiting longer?
Develop by python
Transfer C by AI
Run in C
How about pypy? I know it is faster than python.
But compare the code consumption in the programming language..
C++ propaganda (I just love python and this is a meme, please respectable c++ developers; don't beat me up...)
I choose c#
I have tested the code in python ,its executing less than 1 s
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
How is rust even slower than C++? They're both compiled languages.
Although the above isn't a good example, in the real world, with expertly written c++ code, the compiler can do far more precomputation at compile time.
rust compiled in debug
Ok aunque tardas más escribiendo es más rápido corriendo imaginó porque es un lenguaje de bajo nivel y se ejecuta más rápido en el procesador felicidades
kaka just for fun.
C?
Because iam python dev that's wy python is winner 😁
It's wrong result. Why did you use UNOPTIMALIZED builds for the speed test?
Fun fact: you can make this faster for all three languages by only checking up to sqrt(n).
Python with regex:
import re
def is_prime(n):
return not re.match(r'^.?$|^(..+?)\1+$', '1'*n)
print(is_prime(8))
C++ is the best
and at runtime? hehe
rust without iterators and debug mode :(
Inicio la guerra de los lenguajes 😂😂😂, hay al menos 6000 lenguajes y toda la vida salen con estos temas, que va a morir c++ o Python y que ahora es Rust, 😂😂😂
Well, rust tried
Fortran 😉
I heard on the grapevine that pypy is faster, that its speed is comparable with c++
Господи, чел сравнивает скорость написания кода
Cpp like so easy.
с++.........UB
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.
Se calhar são 2 mais engano
bro its not about how fast the output is , its actually about how easy it is to learn and do python ....... remember ~!
What a joke of a video, I thought they were about to compare the execution speed, who the f cares about this
Спс кэп
If two languages has the same features to use the underlying hardware like multi core, multithreading programming usage comparing languages in regard of Speed is bullshit, it depends on the programmer and the compiler or interpreter. The computer does not RUN Phyton or c or c++ code it only runs machine code. Please author dont waste your time and our time with this kind of crap
Compare with vlang)
thanks for the suggestion, I will look into it
vlang transpile to c. of course, faster then go/rust. 😂
@@onyvid9557 😂
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
C++ is a lenguage very ugly.
You should be mega lamer to make binary on rust working slower that on C++. First next time make program on VIM and tests on Linux and yeah... publish -march parameters.