Multithreading is way easier to implement in C# than all of those other languages because you can just use Task.Run() with async and await and then the TaskScheduler does all of the thread management for you automatically. To me that's way more important than how fast I can calculate prime numbers. Also. I dont know why C# cant be compiled to WASM in GODOT but it certainly can run in the browser when using other C# enabled platforms like UNO Platform and Unity so maybe they just havent got around to implementing it yet.
I like the C# option a lot, but it cannot do HTML builds which is a show stopper for me. If and when C# can produce HTML builds on Godot 4, I am going to switch to C# in an instant.
So you lose access to Performance data in release builds, and I needed debug to see differences in the amount of memory being used, which also provided some interesting results. I would not focus on the actual numbers too much. C# performs well, and even if it performs closer to C++ with release builds, it still cannot be used in HTML builds. C++ is the clear choice if you want speed in your HTML builds.
I reran the all tests on release build: - C++ and Java had the same performance: 44ms and 54ms respectively - C# indeed improved: From 178ms to 68ms - GDScript improved: 4538ms to 3058ms
@@AntzGames Great, it looks like both C# and Java looking great, I wonder when is html for c# comming maybe in .net 9, There is also a Godot for Javascript/TypeScript but it's on 4.1version which is supposed to export to html.
The numbers of Java are pretty impressive. But I guess that makes sense when you compare an algorithm which only deals with numbers and you utilize an ArrayList. So there's very little interaction with the heap doing allocations and utilizing the garbage collector. I would imagine the more complex your application gets (using many classes, objects and relations) the more Java will fall off in terms of performance in comparison to C++. However implementing the same thing in C++ will cause much more headache (choosing between references, smart-pointers, applying rule of 5 and such).
In the context of Godot game development, a C++ call threw a GDExtension is not free, and there is an inherent cost to this. Therefore the more nodes that make C++ calls you have, the less a C++ solution performs, and the better GDScript performance gets relative to C++. The same for Java, the calls between the Godot engine and the JVM are not free.
Good to know. This algo needs to add values to the end of the array during the execution, and technically does not know the final size of the array, but does know the maximum possible size.
@@guillaumemagniadas2472 Technically you can also call reserve() of std::vector which allows reducing the amounts of allocations to only one and forcing it to the beginning of the algorithm. That way the only difference between std::vector and std::array should be whether you access memory in heap or stack. So I guess it depends on the OS whether that makes a reasonable impact.
gdscrip needs more work i do know it was written in C# or ++ its so bad optimize construct 2 visual scrip auto export as an XML when you save theme as files
Multithreading is way easier to implement in C# than all of those other languages because you can just use Task.Run() with async and await and then the TaskScheduler does all of the thread management for you automatically.
To me that's way more important than how fast I can calculate prime numbers.
Also. I dont know why C# cant be compiled to WASM in GODOT but it certainly can run in the browser when using other C# enabled platforms like UNO Platform and Unity so maybe they just havent got around to implementing it yet.
I like the C# option a lot, but it cannot do HTML builds which is a show stopper for me. If and when C# can produce HTML builds on Godot 4, I am going to switch to C# in an instant.
Yeah and for your use case that is correct. But who knows what use use case other people can have.
Thanks for thee comparisons.
Release build in C# is always faster than Debug, godot particularly allow AOT compilations which makes C# closer to C++
So you lose access to Performance data in release builds, and I needed debug to see differences in the amount of memory being used, which also provided some interesting results.
I would not focus on the actual numbers too much. C# performs well, and even if it performs closer to C++ with release builds, it still cannot be used in HTML builds.
C++ is the clear choice if you want speed in your HTML builds.
@@AntzGames Yeah, for html5 sure, if at least there was an 3d engine with a high level language like C# that support html5, that would be nice.
I reran the all tests on release build:
- C++ and Java had the same performance: 44ms and 54ms respectively
- C# indeed improved: From 178ms to 68ms
- GDScript improved: 4538ms to 3058ms
@@AntzGames Great, it looks like both C# and Java looking great, I wonder when is html for c# comming maybe in .net 9, There is also a Godot for Javascript/TypeScript but it's on 4.1version which is supposed to export to html.
@@everythingcouldbesimplify818 unity
amazing test!
The numbers of Java are pretty impressive. But I guess that makes sense when you compare an algorithm which only deals with numbers and you utilize an ArrayList. So there's very little interaction with the heap doing allocations and utilizing the garbage collector.
I would imagine the more complex your application gets (using many classes, objects and relations) the more Java will fall off in terms of performance in comparison to C++. However implementing the same thing in C++ will cause much more headache (choosing between references, smart-pointers, applying rule of 5 and such).
In the context of Godot game development, a C++ call threw a GDExtension is not free, and there is an inherent cost to this. Therefore the more nodes that make C++ calls you have, the less a C++ solution performs, and the better GDScript performance gets relative to C++.
The same for Java, the calls between the Godot engine and the JVM are not free.
@@AntzGames Very interesting. I have only used GDScript in Godot so far but wanted to develop a GDExtension in the future. I'll keep this in mind.
The GH repo link is 404. Did you forget to make it public? :) I would love to try it with Zig bindings.
Indeed it was private. Set to public now. Thanks.
std::array should be faster than a vector in C++ if you know your maximum size
Good to know. This algo needs to add values to the end of the array during the execution, and technically does not know the final size of the array, but does know the maximum possible size.
@@AntzGames yes, that’s what I meant, utilizing the knowledge of the maximum possible size (if it’s not a problem)
@@guillaumemagniadas2472 Technically you can also call reserve() of std::vector which allows reducing the amounts of allocations to only one and forcing it to the beginning of the algorithm. That way the only difference between std::vector and std::array should be whether you access memory in heap or stack. So I guess it depends on the OS whether that makes a reasonable impact.
brother i am targeting android (which one seems optimal) like do a test for that. I am comfortable with all the languages.
gdscrip needs more work
i do know it was written in C# or ++
its so bad optimize
construct 2 visual scrip auto export as an XML when you save theme as files
gdscript runs a lot better if you use static typing, still a lot slower than the others but it's a big improvement
@@AshliBlattgold yeah i know about the static scrip