-
Try putting objects into two linked lists in C using sys/queue.h and C++ using the STL. Try sorting the linked lists. You will find C outperforms C++. That is because C’s data structures are intrusive, such that you do not have external nodes pointing to the objects to cause an extra random memory access. The C++ STL requires an externally allocated node that points to the object in at least one of the data structures. This is the downside of having a container manage your object lifetimes. At the same time, if you wish to avoid that, things will become even slower, because not just 1 data structure will have an extra random memory access for every object, but both data structures will have an extra random memory access for every object.
That said, external comparators are a weakness of generic C library functions. I once manually inlined them in some performance critical code using the C preprocessor:
https://github.com/openzfs/zfs/commit/677c6f8457943fe5b56d7a...
-
InfluxDB
InfluxDB – Built for High-Performance Time Series Workloads. InfluxDB 3 OSS is now GA. Transform, enrich, and act on time series data directly in the database. Automate critical tasks and eliminate the need to move data externally. Download now.
-
Sorry but this engine had(s) problems rendenring a rectangle with alpha channel 3 months ago (I'm assuming it was fixed).
Is it normal for Rust ecosystem to use software of this level of maturity?
https://github.com/FyroxEngine/Fyrox/discussions/725
-
> I failed to fairly evaluate my options at the start of the project.
The more projects I do, the more time I find that I dedicate to just planning things up front. Sometimes it's fun to just open a game engine and start playing with it (I too have an unfair bias in this area, but towards Godot [https://godotengine.org/]), but if I ever want to build something to release, I start with a spreadsheet.
-
> Rust can not represent the vast majority of allocations
Do you mean cyclic types?
Rust being low-level, nobody prevents one from implementing garbage-collected types, and I've been looking into this myself: https://github.com/Manishearth/rust-gc
It's "Simple tracing (mark and sweep) garbage collector for Rust", which allows cyclic allocations with simple `Gc` objects. Can't vouch for that implementation, but something like this would be good for many cases.
-
I completely understand, and it's not the first time I've heard of people switching from Bevy to Unity. btw Bevy 0.16 just came out in case you missed the discussion:
https://news.ycombinator.com/item?id=43787012
In my personal opinion, a paradox of truly open-source projects (meaning community projects, not pseudo-open-source from commercial companies) is that development seems to constantly branch out, lacking a unified roadmap. While this leads to more and more cool things appearing, there always needs to be a balance with sustainable development.
Commercial projects, at least, always have a clear goal: to sell. For this goal, they can hold off on doing really cool things. Or they think about differentiated competition. Perhaps if the purpose is commercial, an editor would be the primary goal (let me know if this is alreay on the roadmap).
---
I don't think the language itself is the problem. The situation where you have to use mature solutions for efficiency is more common in games and apps.
For example, I've seen many people who have had to give up Bevy, Dioxus, and Tauri.
But I believe for servers, audio, CLI tools, and even agent systems, Rust is absolutely my first choice.
I've recently been rewriting Glicol (https://glicol.org) after 2 years. I start from embedded devices, switching to crates like Chumsky, and I feel the ecosystem has improved a lot compared to before.
So I still have 100% confidence in Rust.
-
In the Java universe, there is OpenRewrite for this: https://github.com/openrewrite/rewrite
eg: https://docs.openrewrite.org/recipes/java/migrate/joda/jodat...
I occasionally notice libraries or frameworks including OpenRewrite rules in their releases. I've never tried it, though!
-
Nice catch. I had goofed by omitting optimization when checking this.
That said, this brings me to my original reason for checking this, which is to say that it did not use a cmov instruction to eliminate unnecessary branching from the loop, so it is probably slower than a binary search that does:
https://en.algorithmica.org/hpc/data-structures/binary-searc...
That had been the entire motivation behind this commit to OpenZFS:
https://github.com/openzfs/zfs/commit/677c6f8457943fe5b56d7a...
It should be possible to adapt this to benchmark both the inlined bsearch() against an implementation designed to encourage the compiler to emit a conditional move to skip a branch to see which is faster:
https://github.com/scandum/binary_search
My guess is the cmov version will win.
-
SaaSHub
SaaSHub - Software Alternatives and Reviews. SaaSHub helps you find the best software and product alternatives
-
It is indeed great for creating a prototype. After that, one can gradually migrate to Rust go benefit from faster execution times. The Rust bindings are in a pretty decent shape by now
https://godot-rust.github.io/
-
Stuff that hooked me:
you integrate it tightly with the engine so it only does game logic, making files small and very quick and easy to read.
platform independent, no compiling, so can modify it in place on a release build of the game.
the "everything is a table" approach is very easy to concept mentally means even very inexperienced coders can get up and running quickly.
great exception handling, which makes most release time bugs very easy to diagnose and fix.
All of which means you spend far more time building game logic and much, much less time fighting the programming language.
Heres my example of a 744 flight data recorder (the rest of the 744 logic is in the containing folders)
https://github.com/mSparks43/747-400/blob/master/plugins/xtl...
All asynchronously multithreaded, 100% OS independent.
-
-
It has been proposed, but since there is all the process on how features get added into the standard.
https://github.com/tc39/proposal-pattern-matching
-
-
v
Simple, fast, safe, compiled language for developing maintainable software. Compiles itself in <1s with zero library dependencies. Supports automatic C => V translation. https://vlang.io
Another language with such features, including sumtypes, is V (Vlang)[1].
[1] https://github.com/vlang/v/blob/master/doc/docs.md#sum-types
-
https://github.com/clj-commons/rewrite-clj is an absolute superpower for this kind of thing, if you were using Clojure. It always saddened me it doesn't get more exposure.
As good as Rust is, I still feel there needs to be a "high-low" strategy for most biz/game code. You want to be able to depend on your low level abstractions, while constantly changing up how you fit them together.
-
SaaSHub
SaaSHub - Software Alternatives and Reviews. SaaSHub helps you find the best software and product alternatives
