Repository navigation
Replies: 3 comments 2 replies
|
Hello, To answer your questions: I'm being cautious with the whole development timeline, I've already experienced projects like this, and I know once people are going to start using it that a non-negligible part of my time will be about helping/communicating. It's a trade-off I'm making, I've designed full Span library with the Tomate project, pointer allow an extra speed boost over Span, I'm using it at targeted places and I'm being very cautious about making it local (I have almost none pointer escape and to me that's the most dangerous thing). The beauty of .net is the JIT adapt to the SIMD capabilities of the CPU, so SIMD loop are always optimal. AOT is indeed not a priority right now, but usually reflection is the biggest blocker and I don't rely too much on it. The effort to make the whole thing AOT is medium/safe. That is what the Workbench is about, please check this post and the YouTube video. Yes, there is a handler you can pass, if you dont then last one wins, if you do then you have access to the three versions (yours, the other, the final), you can take a look at the unit tests here The solver looks something like this: tx.Commit((ref ConcurrencyConflictSolver s) =>
{
ref var read = ref s.ReadData<Balance>();
ref var committed = ref s.CommittedData<Balance>();
ref var mine = ref s.CommittingData<Balance>();
s.ToCommitData<Balance>().Amount = committed.Amount + (mine.Amount - read.Amount);
}); |
|
Looks like I just need to wait for September to come haha. I saw the AntHill demo you mentioned, in demo/AntHill. Is it made with Godot? Are there more detailed explanations? How should I run them? I also noticed test/Typhon.ARPG.Schema and test/Typhon.ARPG.Shell, but they aren't any test code. What are they for? Thanks! |
|
For Anthill, best way is to install godot somewhere then do something like this:
If you want something more elaborate, there's a more advanced solution in the workbench. Here you have like 10 archetypes and 20 components that are used to simulate a crafting/mmo game database. There is a complete/complexe database creation method that I use to test things with multi gigabyte database and it was designed to use most of the feature of the engine. |
|
Reopening: your fourth question, the one about First, a correction to the premise: I've now done it as a POC and measured it. The trade-off, measured (20k entities, 6-system DAG):
AOT costs ~13% of steady-state throughput — not from inlining, but because it compiles without profile feedback, so there's no dynamic PGO. Careful: a short run makes AOT look better at everything; that's just JIT warm-up. This is a POC on a branch, So: why do you want AOT? What's the actual constraint? For the long-lived sandbox server you described here, the numbers say stay on the JIT — you'd trade 13% of simulation headroom to save 80 ms you pay once. So either your motivation is something I haven't guessed, or AOT isn't what you need. Deployment without a runtime? Cold start? A platform that forbids JIT? Or the p99 warm-up cliff mattering more than peak throughput? That last one is a genuinely good argument and a different trade — tell me which, and I'll aim the work at the real constraint rather than the acronym. |
|
I only just noticed this reply... In my mind, AOT has significant performance advantages in many scenarios. Its output is also generally harder to reverse-engineer into the complete source code and original design, it doesn't require users to have the .NET runtime installed. That's why I asked you about it. BTW I usually ask agents to write AOT-compatible code, even though I don't necessarily end up publishing an actual AOT build, haha. |
Uh oh!
There was an error while loading. Please reload this page.
I came across references to your blog post online, and after reading it, I believe Typhon could be an excellent solution to the performance bottlenecks plaguing open-world sandbox games such as Minecraft:
My reasoning is as follows: Typhon leverages an ECS-based architecture, tiered storage and persistence at the component granularity, indexing, incremental updates, and MVCC-powered parallel read-write capabilities. All these features are engineered to cut down both the volume of data updated per logic frame and the execution time of individual operations. Conventional non-sandbox games heavily restrict player terrain modification and do not spawn large volumes of mutable entities, resulting in far less update workload that can be pre-optimized upfront. Even non-open-world sandbox titles limit player-modifiable zones to a manageable scope that CPUs can handle without extensive optimization. Only open-world sandbox games face the unique challenge of processing massive datasets within a single logic frame.
To my knowledge, no comparable solution exists on the market. Treating the entire game world as a database and borrowing performance optimization techniques from database engineering is a groundbreaking, almost unprecedented innovation. I am convinced this architecture can unlock performance gains of dozens of times over existing approaches.
I have several questions and look forward to your response:
The README states the project is not yet stable. Is there a clear development timeline available? I am eager to begin building projects atop Typhon.
Your codebase makes extensive use of unsafe constructs, such as manual stack memory allocation. However, .NET provides safe alternatives including Span and Memory, and the C# compiler lacks the rigorous memory safety checks implemented by Rust’s compiler. Ensuring memory safety is notoriously difficult—what informed your design decision here? As an intrusive database that requires games to be built around its architecture from the ground up, Typhon’s stability and correctness are critical.
Hot-path data structures appear optimized for the cache hierarchy of AMD Zen4 x86 CPUs, with fixed widths of 64-bit, 128-bit or 256-bit alongside AVX2 instruction set usage. Does this create performance penalties on other x86 CPUs or non-x86 architectures? This concern is especially relevant amid today’s prevalence of heterogeneous core designs—Zen4 itself ships in distinct variants for desktop CPUs and APUs: the Ryzen 7950X CCD features 32MB of L3 cache, while the Ryzen 7840HS only carries 16MB of L3 cache.
Numerous methods are annotated with
[MethodImpl(MethodImplOptions.AggressiveInlining)]to force aggressive JIT inlining. Does this indicate you intend for users to avoid AOT compilation entirely?Typhon functions as an embedded database rather than a standalone database service, and its internal data formats diverge drastically from standard SQL databases (simple migration to Postgres appears unfeasible). Are there existing tooling solutions for database administration, such as permission control and backup workflows?
Write conflicts are inevitable under an MVCC design, and you have opted for optimistic conflict detection. When a transaction hits a conflict during commit, does Typhon delegate the decision to retry or discard the transaction to the caller, or does it handle this logic internally?
Thank you!
All reactions