Rust Implementation is Significantly Slower Than C: Reintroduce the C Version and Remove the "Deprecated" Marker.

[EndrII]

Hi, I am a game developer, and performance (speed) has always been of critical importance for my tasks. I noticed that you have transitioned to Rust, which I find to be a perfectly reasonable step. However, this does not mean that the C implementation is now obsolete.

To confirm this, I conducted a small benchmark and verified that when handling large datasets, the speed difference is highly critical (significant), which currently prevents me from using Rust as my primary foundation.

Please review the test results. The C implementation is not outdated; it is simply the fastest available implementation, and as such, it deserves full support and continued development.

Rust cannot be a replacement for C; Rust is an excellent complement.

[Cleroth]

Deprecating the most used language in game development doesn't seem logical. I assume this was a mistake.

[qarmin]

Rust cannot be a replacement for C; Rust is an excellent complement.

Rust can, and often does, serve as an excellent replacement for C — especially in cases where safety and maintainability matter.

Deprecating the most used language in game development doesn't seem logical. I assume this was a mistake.

This isn’t about deprecating a language; it’s about the specific implementation. The Rust version still exposes an FFI-compatible C interface, so in practice there should be almost no difference in how it’s used from a C or C++ project.

For this project, the main issue was not fully testing the Rust version. The deprecation of the C version should have occurred only after both versions had been thoroughly tested in multiple ways and it was almost certain that it wouldn’t cause regressions e.g., performance related, which was lacking here.

I’ve also written a patch that improves performance in the Rust implementation. You might want to check it out and see how it performs on your end:

#29

[Cleroth]

The Rust version still exposes an FFI-compatible C interface, so in practice there should be almost no difference in how it’s used from a C or C++ project

You can't seriously expect game devs in C++ to bring in some tiny noise generator from Rust. The C and C++ implementations are there, and since port from 2 years ago, pretty much nothing seems to have changed in regard to implementations, so why bother deprecating them?

[qarmin]

Yeah, I know—it’s much more convenient to have all dependencies in one language, which is why I think the library should provide precompiled DLL/SO files, to avoid problems with integrating multiple languages

As for the deprecation, I mainly understand it as meaning that the Rust version is now the official one where changes can be made, while the C/C++ version has been set aside and won’t be actively developed.

I don’t find that strange, because from what I can see, the C/C++ version is almost feature-complete, and I doubt the library’s author would have any objections if someone else wanted to make improvements to it.

[Cleroth]

the C/C++ version is almost feature-complete

I'd imagine most people unfamiliar with the project will see the top files, read the readme, and assume there's no C/C++ implementation.

[EndrII]

I'd imagine most people unfamiliar with the project will see the top files, read the readme, and assume there's no C/C++ implementation.

i will prepare PR with CMakeList.txt to integrate it with C++, i already finished integrate this library with my game, all works correctly, and little faster of C implementation, so i think is greet news for all.

[EndrII]

@Cleroth done, you can see my PR #30
now you can choose C or Rust back end easy.