I use GDScript to design and test the Architecture (or build a prototype). Once I'm satisfied with the result, I convert it to C++. GDScript performs well, and for most developers, it makes only sense to do a C++ conversion if you are creating something computationally heavy, for example, AI that will be used by over 1000 NPCs so they can interact with each other.
That is where I am at. I plan to use it only for very expensive tasks. I went threw this exercise to learn how to do C++ GDExtensions. It is good to know I have options in Godot once you hit performance limitations.
Keep in mind that this is very specific example, and that GDScript actually performs well in real world examples. C++ GDExtension calls are expensive and if you have many calls per frame/per node the performance gains using C++ via extensions becomes less.
Also, GDExtensions are a pain to work with and troubleshoot, don't forget about that part. Made a GDExtension for video playback in Godot, GoZen GDE, and it was/is a nightmare XD
@@JustVoylin I agree. It took me 2 hours to setup my C++ GDExtensions environment for the 1st time. That being said, its good to know I can code a very expensive algorithm in C++ as an extension if needed now.
So this prime number test is like the worst possible test for GDScript (and most likely Python). I used it specifically to expose the weakness of GDScript in code loops. I would take the results with a grain of salt. GDScript actually does pretty well in real world rendering examples. The official Godot benchmarks can be run here: github.com/godotengine/godot-benchmarks
I wonder if this test is comparing stack in C++ with heap in the C#, and C# in the editor without the released build, cause I tried it and got 3ms in the release build and around 12-16ms in the editor.
To add some context to your original comment and also this edited comment. So this algorithm is very bad in terms of space, and yes, 2 million is very big stack, even for C++. Time Complexity: O(N*log(log(N))) Auxiliary Space: O(N) I may redo the test using the test using the Segmented-Sieve algorithm: www.geeksforgeeks.org/segmented-sieve/ Which reduces the space needed for the algo to the square root of 2million (which is only 1414), shown below: Time Complexity : O(n * ln(sqrt(n))) Auxiliary Space: O(sqrt(n)) Also, I should also redo the tests using the release build as you suggested. Also I may add both Rust and Java/Kotlin GDExtension times, as many people have requested it.
Hiya, interesting comparison! I'm currently working on a numpy-like math API and came across this, so I wanted to have a go at this myself. My 2c, I'd be surprised if GDScript was actually 100x slower than c++, or 27x slower than C#, in the real world. C# may have some edge by being JIT'd and its the compiler having a better implementation than GDScript, but it's also possible the compilers even vectorized your calls automatically, elevating their speeds beyond what's expected from the benchmark designer. But it's hard to say what really happened without actually opening the guts of the binaries. Benchmarks are hard! Anyway, my gdscript implementation got comparable results to yours (about 160ms), while it took about 9ms with the vectorized calls (~16x decrease). That doesn't quite bring it to C# or C++ levels according to your test, but it brings it a lot closer! The library (NumDot) does use SIMD vectorization to speed up assignments, but it's somewhat handicapped in comparison to C++ plain because of the many abstraction layers between logic and assignment.
In a real world game example with a complex scene graph, GDScript performs much better, and many C++ GDExtension calls becomes more expensive. However, a highly computational and/or any algo that requires loops severely impacts GDScript. Also I think you might want to edit your statement >>> I'd be surprised if C# was actually 100x slower than c++, or 27x slower than C# I know you meant GDScript at the beginning.
C++ GDExtensions can be compiled using Emscription to produce a Web Assembly module (WASM) and run on the web, as I explain in the video. This is done automatically on export. Here is another example: www.reddit.com/r/godot/comments/1atvz4z/gdextensionc_game_on_the_web_with_wasm_sand_slide/
So this older Godot3 repo did some rust + GDNative (which is now GDExtensions): github.com/extrawurst/godot-rust-benchmark I would assume a rust shared library GDExtension to be relatively the same speed as a shared library C++ GDExtension.
![Chris Langan - The Interview THEY Didn't Want You To See - CTMU [Full Version; Timestamps]](/img/1.gif)
I use GDScript to design and test the Architecture (or build a prototype). Once I'm satisfied with the result, I convert it to C++. GDScript performs well, and for most developers, it makes only sense to do a C++ conversion if you are creating something computationally heavy, for example, AI that will be used by over 1000 NPCs so they can interact with each other.
That is where I am at. I plan to use it only for very expensive tasks. I went threw this exercise to learn how to do C++ GDExtensions. It is good to know I have options in Godot once you hit performance limitations.
Keep in mind that this is very specific example, and that GDScript actually performs well in real world examples. C++ GDExtension calls are expensive and if you have many calls per frame/per node the performance gains using C++ via extensions becomes less.
Also, GDExtensions are a pain to work with and troubleshoot, don't forget about that part. Made a GDExtension for video playback in Godot, GoZen GDE, and it was/is a nightmare XD
@@JustVoylin I agree. It took me 2 hours to setup my C++ GDExtensions environment for the 1st time. That being said, its good to know I can code a very expensive algorithm in C++ as an extension if needed now.
yes please do a rust version of this Video.
gicven how much gd script borrows from python idl ike to see python vs godot test.
So this prime number test is like the worst possible test for GDScript (and most likely Python). I used it specifically to expose the weakness of GDScript in code loops. I would take the results with a grain of salt. GDScript actually does pretty well in real world rendering examples.
The official Godot benchmarks can be run here: github.com/godotengine/godot-benchmarks
I wonder if this test is comparing stack in C++ with heap in the C#, and C# in the editor without the released build, cause I tried it and got 3ms in the release build and around 12-16ms in the editor.
To add some context to your original comment and also this edited comment.
So this algorithm is very bad in terms of space, and yes, 2 million is very big stack, even for C++.
Time Complexity: O(N*log(log(N)))
Auxiliary Space: O(N)
I may redo the test using the test using the Segmented-Sieve algorithm: www.geeksforgeeks.org/segmented-sieve/
Which reduces the space needed for the algo to the square root of 2million (which is only 1414), shown below:
Time Complexity : O(n * ln(sqrt(n)))
Auxiliary Space: O(sqrt(n))
Also, I should also redo the tests using the release build as you suggested. Also I may add both Rust and Java/Kotlin GDExtension times, as many people have requested it.
Hiya, interesting comparison! I'm currently working on a numpy-like math API and came across this, so I wanted to have a go at this myself. My 2c, I'd be surprised if GDScript was actually 100x slower than c++, or 27x slower than C#, in the real world. C# may have some edge by being JIT'd and its the compiler having a better implementation than GDScript, but it's also possible the compilers even vectorized your calls automatically, elevating their speeds beyond what's expected from the benchmark designer. But it's hard to say what really happened without actually opening the guts of the binaries. Benchmarks are hard!
Anyway, my gdscript implementation got comparable results to yours (about 160ms), while it took about 9ms with the vectorized calls (~16x decrease). That doesn't quite bring it to C# or C++ levels according to your test, but it brings it a lot closer! The library (NumDot) does use SIMD vectorization to speed up assignments, but it's somewhat handicapped in comparison to C++ plain because of the many abstraction layers between logic and assignment.
In a real world game example with a complex scene graph, GDScript performs much better, and many C++ GDExtension calls becomes more expensive. However, a highly computational and/or any algo that requires loops severely impacts GDScript.
Also I think you might want to edit your statement >>> I'd be surprised if C# was actually 100x slower than c++, or 27x slower than C#
I know you meant GDScript at the beginning.
@@AntzGames you got it right, i meant GDscript there :) statement is edited.
I thought GDExtension did not work with HTML5 target? How do you have c++/html5 results?
C++ GDExtensions can be compiled using Emscription to produce a Web Assembly module (WASM) and run on the web, as I explain in the video. This is done automatically on export.
Here is another example: www.reddit.com/r/godot/comments/1atvz4z/gdextensionc_game_on_the_web_with_wasm_sand_slide/
So I added a GitHub repository so you can run the GDExtension on an HTML export yourself: github.com/antzGames/GDExtensions_VS_GDScript_Test
Benchmark Java with Godot
Check out: ruclips.net/video/oiuECV23lP0/видео.html for benchmarks of using Java with Godot. It is basically at C++ speeds.
What version of .NET were you using in these tests?
Hello. V8.0.303
C:\Users\antho>dotnet --list-sdks
8.0.303 [C:\Program Files\dotnet\sdk]
Please see my updated video: ruclips.net/video/qDXomV7Ojko/видео.html
Rust + godot ?
So this older Godot3 repo did some rust + GDNative (which is now GDExtensions): github.com/extrawurst/godot-rust-benchmark
I would assume a rust shared library GDExtension to be relatively the same speed as a shared library C++ GDExtension.