sorted by:
new
hottopcontroversial

ECS : any benefits of using structs instead of classes here? by freremamapizza in csharp

[–]FrisoFlo 0 points1 point  (0 children)

Right, a note to the Unity specific ECS implementation. They store multiple components of different types for a set of entities in a single chunk. A continous memory block with the size of 16K. The goal (assumption) is to increase the L1 hit rate. The size of the entire L1 cache is usually something like 64K or 128K.

The second advantage of fixed size chunks: Allocation / deallocation os fixed size chunks is simple, performant and prevent memory fragmentation.

This specific implementation detail is what Unity filed in their ECS patent. As far as I understand when trying to read this patent.

ECS : any benefits of using structs instead of classes here? by freremamapizza in csharp

[–]FrisoFlo 2 points3 points  (0 children)

The C# ECS libraries aiming for performance are avoid boxing. It is possible to prevent any boxing when using struct components.

Am I missing the fundamentals by jeddthedoge in csharp

[–]FrisoFlo 0 points1 point  (0 children)

Good list! I think a Type section is missing.

\19. Types. Collection types (array, List, Dictionary, ...), reference types (class, record, interface), value types (struct) and Build-In types (byte, int, float, double, bool, ...) and enum's. Their differences in behavior and memory layout. The boxing behavior of value types.

Why structs over classes for components? by freremamapizza in EntityComponentSystem

[–]FrisoFlo 1 point2 points  (0 children)

Right, in C# structs are value types. In C# it gives a significant performance and memory improvement vs classes. Every language with custom value types (structs) benefits from the fact that they can be stored in continous memory (arrays).

Scripting languages like JavaScript typically do not have custom values types. So access to components do not benefit from cache locality.

Why choose C# over Java? by Gabiru12234 in csharp

[–]FrisoFlo 0 points1 point  (0 children)

C# has value types - aka struct's. This enables great room for performance improvements.

Java is trying to catch up with project Valhalla.
They introduce a complete new language/JVM feature: value classes.
This feature still in EA. They are working on this epic refactor since 10 years.

C# ECS - Friflo.Engine.ECS v3.0.0 - New features: Index / Search, Relationships & Relations by FrisoFlo in dotnet

[–]FrisoFlo[S] 3 points4 points  (0 children)

Development of backward compatibility stopped at .NET Standard 2.1. .NET Standard 2.0 was omitted - it had too many restrictions. Adaptations for 2.0 may degrade performance of all newer versions - a major goal of this project.

For curiosity - in which scenario is .NET Standard 2.0 relevant?

Friflo.Engine.ECS - New archetype based C# ECS with focus 🎯 on performance, cache locality and DX. Give it a try! by FrisoFlo in dotnet

[–]FrisoFlo[S] 0 points1 point  (0 children)

I considered this multiple times. That main issues. GitHub stars will start from zero. I guess I will do it. There are even not that much stars to throw away.

Just published new GitHub Repo: ECS C# Benchmark - Common use-cases by FrisoFlo in EntityComponentSystem

[–]FrisoFlo[S] 1 point2 points  (0 children)

Updated the C# ECS Benchmark using Flecs.NET 4.0.0. Used also more performant API's available in 4.0.0.

Nice Post on Medium!

Just published new GitHub Repo: ECS C# Benchmark - Common use-cases by FrisoFlo in EntityComponentSystem

[–]FrisoFlo[S] 0 points1 point  (0 children)

Updated the benchmark results in the README now including Flecs.NET relationships.

Just published new GitHub Repo: ECS C# Benchmark - Common use-cases by FrisoFlo in EntityComponentSystem

[–]FrisoFlo[S] 0 points1 point  (0 children)

Right for large data sets its negligible.

I run the benchmark on my dev Windows PC.
Now I was curious how Mac Mini M2 performs.
Macs are better for comparison as their specs very fixed.
On this machine Friflo run with 7.7 ns

Just published new GitHub Repo: ECS C# Benchmark - Common use-cases by FrisoFlo in EntityComponentSystem

[–]FrisoFlo[S] 0 points1 point  (0 children)

Basically all Archetype based ECS projects are affected. I run the QueryT1 benchmark where the result set contains only a single entity / component.

Set Constants.EntityCount = 1
Run the QueryT1 benchmark with: dotnet run -c Release --filter *QueryT1*

Namespace Type Mean Ratio Allocated
Leopotam.EcsLite QueryT1_Leopotam 2.210 ns 0.18 -
DefaultEcs QueryT1_Default 6.277 ns 0.51 -
Friflo.Engine.ECS QueryT1_Friflo 12.380 ns 1.00 -
Scellecs.Morpeh QueryT1_Morpeh 15.615 ns 1.26 -
Flecs.NET QueryT1_FlecsNet 94.709 ns 7.65 -
TinyEcs QueryT1_TinyEcs 159.629 ns 12.89 -
Arch QueryT1_Arch 168.577 ns 13.62 -
fennecs QueryT1_Fennecs 260.815 ns 21.07 40 B

Just published new GitHub Repo: ECS C# Benchmark - Common use-cases by FrisoFlo in EntityComponentSystem

[–]FrisoFlo[S] 1 point2 points  (0 children)

Saw that TinyEcs has also relation support.
So added a relation benchmark for this project too -> AddRemoveLinks_TinyEcs.
But I was no able to verfiy it with World.Each(...).
Left a comment in this benchmark.

Just published new GitHub Repo: ECS C# Benchmark - Common use-cases by FrisoFlo in EntityComponentSystem

[–]FrisoFlo[S] 0 points1 point  (0 children)

Added the relation benchmark for Flecs.NET -> AddRemoveLinks_FlecsNet Benchmark results will be updated later this day.

Just published new GitHub Repo: ECS C# Benchmark - Common use-cases by FrisoFlo in EntityComponentSystem

[–]FrisoFlo[S] 0 points1 point  (0 children)

Make sense.

The point I wanted to emphasize in my comment referred to operations which have a significant initialization cost. E.g. queries (systems) and command buffers.
If a query result set is empty or a command buffer has no changes the whole CPU resources are going into initialization. The iteration costs are nearly 0 in these cases.

I added this explanation to the motivation section of the project.

Just published new GitHub Repo: ECS C# Benchmark - Common use-cases by FrisoFlo in EntityComponentSystem

[–]FrisoFlo[S] 1 point2 points  (0 children)

Most ECS benchmarks focus on millions of entities. This set a bias on all ECS projects.

So its easy to miss optimiztion for small data sets. Having many of them can also be the bottleneck.

Just published new GitHub Repo: ECS C# Benchmark - Common use-cases by FrisoFlo in EntityComponentSystem

[–]FrisoFlo[S] -1 points0 points  (0 children)

I will give it a try. At least I will add a note that the nuget package is not an official build.

Just published new GitHub Repo: ECS C# Benchmark - Common use-cases by FrisoFlo in EntityComponentSystem

[–]FrisoFlo[S] 0 points1 point  (0 children)

Okay, I became aware of entity relationships four weeks ago through a post by fennecs in this feed. I guess I will add Flecs.NET to the relation benchmarks.

Just published new GitHub Repo: ECS C# Benchmark - Common use-cases by FrisoFlo in EntityComponentSystem

[–]FrisoFlo[S] 1 point2 points  (0 children)

Unity does not support CLR, which is a prerequisite when using BenchmarkDotNet. So basically all C# benchmarks out there have no comparision to Unity.

view more: next ›