SIECS and EnTT for C++.

Two different storage models

SIECS provides a typed C++ interface over a C runtime. EnTT provides a header-only modern C++ library centered on a registry and sparse-set component pools.

The practical differences start with data placement: SIECS groups equal component sets into tables, while EnTT keeps component types in separate pools.

Compare the API boundary

SIECS maps complete shapes to tables

SIECS stores every entity with the same component set in one table. Components occupy contiguous columns, and systems process matching rows in batches.

EnTT stores components in sparse-set pools. Registry views and groups select the component combinations required by the application.

SIECS retains matching tables

A persistent SIECS query retains the archetype tables that satisfy its access terms. Each iterator step exposes aligned component columns for one table batch.

EnTT views and groups operate across registry pools. A useful comparison uses the real entity shapes, component sizes, and access patterns of the target project.

Use one SIECS world across C and C++

SIECS keeps archetype queries, systems, observers, relations, resources, and reflection in one world shared by its C and C++ interfaces.

Its standalone distribution is one header and one C source file. Compile the source once and link it with the C++ application.

Benchmark the operation that matters

1. Define the real entity shapes and component sizes.
2. Measure repeated iteration separately from component insertion.
3. Use equivalent ownership and query semantics.
4. Include system, event, reflection, and language-boundary needs.
5. Publish the source and compiler configuration with every result.

Start with the SIECS archetype guide and the EnTT ECS documentation before implementing a comparison workload.