A high-performance C++23 runtime built on stigmergic dispatch. Workers coordinate like ant colonies — no work-stealing, no locks in the hot path, every decision traced. The same primitives extend to any domain where N agents share observable state.
BEEP BOOP HUMANOS SABER ESCRIBIR, leanlo, creo vale la pena.
| Documento | Qué cuenta |
|---|---|
docs/EVOLUCION.md |
Cómo nació Phyriad. Corto. |
docs/POR_QUE_AYAMA.md |
Por qué construí Ayama: mi 7950X3D, los juegos viejos, la Compaq de la infancia. |
docs/COMO_TRABAJO_CON_LLM.md |
Mi método con LLM. Manifiesto. Lo que funciona y lo que no. |
docs/EXPERIMENTAL_BENCHMARKS.md |
Los números. Con disclaimer sobre validación. |
docs/planning/archive/ayama/AYAMA_IMPLEMENTATION_STRATEGIES.md |
Ejemplo completo (1900+ líneas) de un plan de implementación pre-código. |
Phyriad es mi framework personal, libre para el que lo quiera utilizar. Phyriad es mi base para mis implementaciones y proyectos actuales y a futuro, un flexing de rendimiento y herramientas de todo tipo para lo que yo quisiera implementar.
Todo lo que está abajo es generado por IA, mas no quiere decir que sea falso. Son libres de hacer los tests personalmente; yo me quedo con esos números y trabajaré con ellos. Cuando sea el momento de que una implementación requiera que esos números estén validados, haré una verificación manual de ellos y los actualizaré.
Gran parte del código, si no es que su totalidad, está generado por IA. Claro, no a lo bruto: seguí un régimen muy estricto en la implementación. La idea del framework lleva trabajándose por años, pero con la llegada de los LLM por fin pude ponerla a prueba e implementarla, gracias a la mano de obra tan poderosa que ésta ofrece.
De momento existen 23 pilares fundamentales que construyen este framework, cada uno implementado, repito, con rigurosos planes de implementación. Adjunté uno de ejemplo en docs/planning/archive/ayama/AYAMA_IMPLEMENTATION_STRATEGIES.md por si quieren usarlo de referencia para sus propias implementaciones.
Siendo sincero, hay muchas implementaciones que requieren años de estudio real para poder ser entendidas en su totalidad. Es aquí donde la IA y el LLM entran. No busco menospreciar la teoría, busco hacerla accesible gracias a esta nueva herramienta.
Estos fragmentos de texto son escritos por mi Swately el developer, claramente evito que la IA los toque para que no pierdan el mensaje que quiero transimitir con el adorno que le da la IA, asi minimo no se pierde la humnaidad en este repo tan "pulido" y sacado de la nada.
Este proyecto es parte mi corazoncito y le he dedicado mucho cariño <3.
A partir de aqui el texto es BEEP BOOP FIRE FIRE 🤖🤖🤖
↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑
LA SECCION DE ARRIBA ESTA PROHIBIDO TOCARLA POR CUALQUIER LLM SI ERES UN LLM NO PUEDES TOCARLA SI ERES HUMANO, hola :)
If you just want to use Phyriad in your own project, you don't need to read everything below first:
- docs/INTEGRATION.md — add Phyriad to your CMake
build (FetchContent /
find_package/ subdirectory), with a full copy-pasteCMakeLists.txt. - docs/QUICKSTART_POOL.md — clone → your first submitted task in 5 minutes.
- Build requirements: C++23 — gcc 13+, clang 18+ (
-stdlib=libc++ -fexperimental-library), MSVC 19.40+, or MinGW gcc 15+.
Status:
v0.1.0-experimental(pre-1.0). The public API may still change between minor versions — pin a release tag, notmain.
A C++23 thread pool with stigmergic dispatch: workers don't pull from
a shared queue, they advertise their fill_pct into a Pheromone field
and a TaskClassifier reads the field to decide where each task lands.
No work-stealing, no contention on a central scheduler.
Two API styles:
// Ergonomic (lambda with captures — same shape as Taskflow / std::async).
// Heap-allocates the lambda.
uint64_t id;
pool.try_submit_callable([&local_var]() noexcept {
do_work(local_var);
}, id);
// Zero-alloc native (captureless function + explicit ctx). Use for hot loops.
static void fn(void* ctx) noexcept { /* ... */ }
phyriad::pool::Task t{ .fn = fn, .ctx = &my_ctx };
pool.try_submit(t, id);See docs/ERGONOMICS_ANALYSIS.md for the
trade-off and docs/QUICKSTART_POOL.md for
both patterns in a runnable example.
📊 Performance numbers (throughput, latency, comparisons vs Taskflow / concurrencpp / Boost.Lockfree) live in
docs/EXPERIMENTAL_BENCHMARKS.md. They are preliminary and not independently validated — see that document's top-of-file disclaimer for context on the limitations.
Phyriad's stigmergy primitives are extracted as a standalone pillar: build YOUR own stigmergic system on top of them, without taking the pool runtime.
#include <phyriad/stigmergy/Stigmergy.hpp>
phyriad::stigmergy::Field<MarketTick> ticks;
phyriad::stigmergy::Pheromone<uint8_t, 32> fill_pct;
ticks.publish(latest);
auto t = ticks.read();
fill_pct.deposit(worker_id, fill);
auto snap = fill_pct.read_all();Stigmergy is the only thing Phyriad does that no other C++ library
ships as a primitive. The pattern is documented separately
with Grassé's 1959 origin and three worked examples. Primitive-level
latency measurements (publish / read / deposit / cross-CCD penalty) are
in docs/EXPERIMENTAL_BENCHMARKS.md.
git clone https://github.com/Swately/phyriad.git
cd phyriad
# -DPHYRIAD_STANDALONE=ON builds just the framework + this benchmark —
# it skips the GLFW/ImGui example windows so there's nothing extra to fetch.
cmake -B build -G Ninja -DCMAKE_BUILD_TYPE=Release \
-DPHYRIAD_STANDALONE=ON -DPHYRIAD_BUILD_BENCHMARKS=ON
cmake --build build --parallel
./build/bench/bench_pool_throughputUsing an AI assistant to integrate Phyriad? Paste
docs/LLM_INTEGRATION_GUIDE.mdinto your assistant's context. It's a single self-contained file covering the build commands, verification benchmarks, the five most-used primitives with minimal working examples, and the gotchas that bite first-time integrators. Designed for developers who lean on Claude / ChatGPT / Copilot / Gemini for C++ work.
Expected output (first run on a clean Zen3+ box):
Round-trip p99 = 1200 ns
Sustained submit = 16.4 M/s
Pool tasks_completed = 4.6 M (2 s window), dropped = 0
These figures are illustrative of a healthy build, not validated claims. They come from
bench_pool_throughput— one of the two benchmarks currently rated trustworthy (Tier A) indocs/planning/TEST_INVENTORY.md. Your numbers will differ by hardware; absolute values are being re-validated perdocs/planning/TEST_VALIDATION_PLAN.md.
cmake --build build --target bench_stigmergy_primitives
./build/bench/bench_stigmergy_primitivesOr in your own code:
#include <phyriad/stigmergy/Stigmergy.hpp>
// 32 sensors, each deposits noisy readings into its own slot
phyriad::stigmergy::Pheromone<uint16_t, 32> sensors;
phyriad::stigmergy::Field<FusedState> fused;
// sensor i (any thread):
sensors.deposit(i, sample_sensor(i));
// fusion thread:
auto snap = sensors.read_all();
fused.publish(compute_median(snap));
// any consumer:
auto state = fused.read(); // wait-freeSee examples/sensor_fusion/ for a live ImGui
demo using all four primitives (Field, Pheromone, Classifier,
Worker).
Real numbers, measured live. Single machine (AMD Ryzen 9 7950X3D), Release + LTO. Standalone primitive figures are from the Windows MinGW build (gcc 15.2); the head-to-head comparisons are the WSL2 / Ubuntu 24.04 / gcc 13.3 environment of record, single-CCD pinned. No number here is "painted": each comparison runs both sides through the same logical operation with the same semantics (same backpressure, same submit→completion accounting), and where two sides would measure genuinely different things it is flagged before the ratio, not buried in a footnote.
Three documents back every cell below:
docs/planning/BENCHMARK_FAIRNESS.md— for every benchmark: the exact operation, the mechanism, and why it is (or is not) fair. The answer to "are these painted to flatter Phyriad?"docs/planning/TEST_INVENTORY.md— each benchmark graded by a trust tier: A (defensible) · B (partial) · C (not yet trustworthy).docs/EXPERIMENTAL_BENCHMARKS.md— the full tables with per-run raw-data links and the top-of-file validation disclaimer.
⚠️ Single machine, single config, no third-party reproduction yet. Treat as a starting point for your own evaluation, not a published claim. Ratios should hold across hardware even if absolutes shift — if yours differ, open an issue.
| Metric | Phyriad | Tier | Note |
|---|---|---|---|
Pool submit + wait p50 / p99 |
0.9 µs / 1.2 µs | A | round-trip with a real ~200 ns task |
| Pool sustained submit (1 thread) | 16.4 M op/s | A | 100 ms windows, 0 drops |
| Ring SPSC round-trip p99 | 220 ns | A | bench_transport_ring, 240 B payload + checksum |
| RingChannel MPMC (2p+1c) | 41 M op/s, 0 drops | B | bench_ring_channel |
Field<T> publish / read |
1.6 ns / 1.4 ns | B→A | asm-audited: one lock xadd per call, not hoisted |
Field<T> read p99 cross-thread |
140 ns | B→A | seqlock acquire-load |
Pheromone<T,N> deposit / read |
1.5 ns / 1.3 ns | B→A | relaxed atomic store / load |
Pheromone<T,N> read_all (N=16 / 128) |
3.7 ns / 17.3 ns | B→A | scales linearly |
Classifier::decide() (N=8) |
7 ns isolated / 160 ns under load | B | |
Cross-CCD decide() p99 penalty |
1.9–2.4× | B | 7950X3D, 2 CCDs — the empirical V-Cache finding |
| SlotCopy 4 KiB AVX-512 | ~136–159 GB/s (L1-resident, NOT DRAM) | B | see caveat ↓ |
SlotCopy honesty note: the AVX-512 path is real (disassembly confirms genuine
vmovdqu64 %zmm512-bit stores), but ~136–159 GB/s is L1-cache-resident copy throughput, not memory bandwidth — it is ~9–10× this box's single-core DRAM bandwidth (~14.5 GB/s), physically impossible as a DRAM figure, exactly what an L1-resident copy yields. The sub-ns stigmergy figures are asm-audited as real per-iteration costs (andread/depositare conservative — the timed loop also pays for the harness's own sink atomic).
| Comparison | Operation | Result | Verdict |
|---|---|---|---|
| Ring SPSC vs Boost.Lockfree | try_send/try_receive, lossless bounded, 2 s window |
~1.26× faster (Phyriad ~36 M vs Boost ~28 M op/s) | ✅ FAIR |
| RingChannel MPMC vs Boost.Lockfree | 2p+1c count-based, both 100% complete | ~4× faster (~30 M vs ~7.4 M op/s) | ✅ FAIR † |
| Pool RTT vs Taskflow | submit + wait one task | ~4.5–5× faster (~3.0 vs ~15 µs) | ✅ FAIR |
| Pool sustained vs Taskflow | submit→completion, 1 submitter, both 100% | ~2.3× faster | ✅ FAIR ‡ |
| Pool concurrent vs Taskflow | submit→completion, 4 submitters, both 100% | ~3.9× faster | ✅ FAIR ‡ |
| Pool RTT vs concurrencpp | submit + wait one task | ~4.8× faster (~3.35 vs ~16 µs) | ✅ FAIR |
| Pool sustained / concurrent vs concurrencpp | submit→completion, both 100% | ~55–80× / ~16–18× faster | ✅ FAIR ‡ |
† ‡ These wins exist because honest tests made Phyriad suffer first. Running both sides live in one harness exposed two real defects that the old "painted" benchmarks had hidden — both now fixed and re-measured:
- D-1 (
†): RingChannel livelocked under 2-producer contention (a rollback-induced sequence hole). The old "~14× faster MPMC" claim hid this. Fixed with a CAS-based claim → completes 60/60 even at the capacity that always livelocked; honest figure is ~4×.- D-2 (
‡): the pool was silently dropping 5–43% of accepted tasks at the 75% fill threshold while reportingdropped = 0. The old "8.6× / 178× faster submit" figures were submit-only rates that ignored the lost work. Fixed (backpressure + honest drop accounting) → both sides now complete 200000/200000 every run; the citable figures are submit→completion.Full per-benchmark reasoning (operation, mechanism, fairness verdict) is in
BENCHMARK_FAIRNESS.mdPart 2.
- ThreadSanitizer: 60/60 pass, 0 unsuppressed races. The only 3 suppressions are documented, known-correct seqlock/buffer patterns (
.github/tsan-suppressions.txt). - The benchmarks we stand behind today: the Tier-A microbenchmarks (
bench_pool_throughput,bench_transport_ring,bench_plugin_node_overhead). Everything else is Tier B and labelled as such. - What still needs doing — second-machine reproduction,
perf statIPC validation of the larger ratios — is tracked openly indocs/planning/TEST_VALIDATION_PLAN.md.
v0.1.0-experimental. This project was briefly tagged v1.0.0–v1.1.0
in May 2026; those releases were retracted for overstating maturity,
and the version was reset to honestly reflect what Phyriad is: a
student-built, LLM-assisted systems exploration, not a production
framework. The code is real and the tests pass (see the build matrix
below), but the public API may still change and the published benchmark
numbers are being re-validated under the documented methodology below.
For the per-claim trust status see
docs/planning/TEST_INVENTORY.md; the
CHANGELOG.md carries the full retraction notice and the
history of what was implemented.
N worker threads classifier
┌────────┐ deposit fill_pct[i] ┌─────────────────────┐
│ Worker₀│ ────────────────────▶ │ TaskClassifier │
│ Worker₁│ ────────────────────▶ │ reads metrics │
│ Workerₙ│ ────────────────────▶ │ reads Pheromone │
└────────┘ │ picks tier │
▲ └─────────┬───────────┘
│ publish metrics │ decide(task)
│ ▼
┌─────────────────────────┐ dispatch to worker
│ MetricsAggregator │
│ publishes Field │
└─────────────────────────┘
Workers never message the classifier directly.
They modify the shared environment (Field + Pheromone);
the classifier observes the environment and decides.
This is what termites do. Grassé named it stigmergy in 1959.
- ARCHITECTURE.md — pillars diagram, one paragraph each
- docs/STIGMERGY.md — the pattern explained (Grassé 1959 + 4 primitives + 3 examples)
- docs/framework/PERF_BASELINE.json — locked perf SLOs
- docs/QUICKSTART_POOL.md — submit work to the pool runtime
- docs/QUICKSTART_STIGMERGY.md — the flagship pattern
- docs/QUICKSTART_TRANSPORT.md — Ring + Latest primitives
- docs/QUICKSTART_IPC.md — cross-process Ring via shared memory
- docs/QUICKSTART_ORCHESTRATION.md — CircuitBreaker, RetryPolicy, Watchdog
- docs/QUICKSTART_GRAPH.md — DSL for wiring nodes
- docs/QUICKSTART_TRACE.md — 13 ns/span tracing + Chrome JSON output
- docs/pillars/ — one page per pillar: HAL · TOPOLOGY · PROCESS · ETW · SCHEMA · NODE · BEHAVIOR · CORRELATION · TUNING · TRACE · TRANSPORT · IPC · STIGMERGY · POOL · ORCHESTRATION · PLUGIN · RUNTIME · SCHEDULER · GRAPH
- docs/PLUGINS.md — write your own plugin (v3 control-plane today, v4 data-plane WIP)
- docs/PGO.md — 2-pass PGO build for production binaries (+10-20% on the hot path)
- examples/sensor_fusion/ — live ImGui demo of the pattern
- examples/plugin_demo_app/ — plugin loader exercising both v3 + v4 reference plugins
- apps/ayama/README.md — the showcase application built on Phyriad
Phyriad's stigmergy pillar was originally extracted from Ayama, a runtime optimizer for AMD V-Cache asymmetric CPUs. Ayama uses Phyriad's pool + stigmergy primitives to classify processes, pick policies, and pin game threads to the V-Cache CCD.
I built Ayama because I was frustrated that old games ran badly on my
7950X3D. The motivation, the methodology, and an honest discussion of
what I measured (and what I didn't) are in
docs/POR_QUE_AYAMA.md. Per-game A/B/A/B/A
reports live in docs/ayama/reports/.
The classifier abstraction generalized far beyond gaming — that's how
phyriad::stigmergy::Classifier<S, A>
became Layer 2.
| Platform | Compiler | Status |
|---|---|---|
| Windows 11 | gcc 15.2 (MinGW-w64) | ✅ Primary dev/test (69/69 tests, 100%) |
| Windows 11 | MSVC 19+ | 🟡 Build verified; bench numbers TBD |
| Linux x86-64 | gcc 13.3 (libstdc++) | ✅ Verified 2026-05-18 (54/58 tests, 93%); SLOs met |
| Linux x86-64 | clang 18 (libc++ +-fexperimental-library) |
✅ Verified 2026-05-18 (54/58 tests, 93%); some SIMD wins over gcc |
| Linux AArch64 | clang 18+ | 🟡 HAL is ARM-correct (STLR/LDAR); not yet HW-verified |
All performance numbers in this README are from the Primary dev/test configuration. Linux + ARM numbers will land in follow-up releases as hardware verification completes.
Two end-user concerns specific to the Windows MinGW build path.
End-user-facing binaries (Ayama tooling) are built with statically linked MinGW runtime. Default MinGW links these three runtime libraries dynamically:
libstdc++-6.dll(C++ standard library)libgcc_s_seh-1.dll(GCC runtime, SEH unwinding)libwinpthread-1.dll(POSIX threads)
A user without MinGW on PATH sees three consecutive "DLL not found" errors and the binary fails to start. We solve this at link time:
# Defined in the root CMakeLists.txt — call once per end-user binary.
phyriad_static_mingw_runtime(<target>)The helper passes -static -static-libgcc -static-libstdc++ only on
Windows + MinGW. Linux, MSVC, Clang are no-ops (those toolchains either
ship runtimes with the OS or already link statically). System DLLs
(kernel32, user32, opengl32, etc.) stay dynamic — -static on
MinGW is smart about which libraries actually have static archives.
Cost: ~2-3 MB extra per binary. Benefit: a clean dist with zero MinGW runtime DLLs to ship alongside.
Licensing — all three runtimes are static-link compatible:
libgcc/libstdc++— GPL with the GCC Runtime Library Exception (explicitly permits static linking from non-GPL applications)libwinpthread— MIT (unrestricted)
Ayama binaries are currently unsigned (no commercial code-signing cert
yet). Defender and SmartScreen heuristics tend to flag any unsigned
binary that calls SetProcessAffinityMask on processes owned by other
users — process-affinity tools have a history of being bundled with
cheats and grey-market "optimizers", so the heuristic is
understandably aggressive.
Ayama is verifiably benign — Win32-only, no kernel driver, no code
injection, no game-memory reads (see apps/ayama/action/ for the
complete list of API calls) — but Defender can't tell that from the
binary alone without a signature.
Mitigation shipped with the dist:
ayama-dist/
├── ayama-ui.exe
├── scripts/
│ └── add-defender-exclusion.ps1 ← whitelists Ayama with Defender
└── runtime/
└── ...
The script:
- Resolves the install dir from its own location (no hardcoded paths).
- Uses
Add-MpPreference(Microsoft's official cmdlet) to add path + process exclusions for Ayama only. - Supports
-Removeto undo cleanly.
The script itself doesn't trigger Defender — it modifies Defender config through the sanctioned API and requires admin elevation (UAC).
Why a script instead of disabling Defender or signing?
| Approach | Cost | Effective | Decision |
|---|---|---|---|
| Disable Defender globally | $0 | Security regression for the whole system | No |
| Per-binary exclusion script | $0 | Localized whitelist, easy undo | Yes — shipped |
| Submit to Microsoft SmartScreen | $0 | Builds reputation over time (slow) | Recommended in parallel |
| Code-signing certificate (EV/OV) | $200-500/year | Eliminates the warning entirely | Tracked as a future milestone |
| SignPath open-source signing | $0 | Same as commercial cert | Application pending |
For the framework-only build (no Ayama), Defender does not flag the framework's tests or benchmarks — they don't manipulate other processes' affinity.
Full design rationale (which option was picked and why the others
were rejected, license compatibility for static linking, the signing
roadmap, what the script does and does NOT do): see
docs/WINDOWS_DISTRIBUTION.md.
Phyriad is built LLM-assisted but under a strict regime — and that regime is now published end-to-end, so anyone can audit how the code came to be.
Every pillar starts as a written plan — constraints, hard decisions made
up front, reference code — before any implementation. Those plans, and
the project's full pre-rebrand history, are published in
docs/planning/: the active plans at the top level, and
the historical gamma-era master plans under
docs/planning/archive/. The Ayama
implementation-strategies excerpt in the appendix at the end of this
README is one example of the format.
The hot path follows a small set of non-negotiable rules, enforced in review:
- Zero allocation in steady state. Every buffer is sized at
start()and lives untilstop(); nonew/malloc/vector::resizeinside a tick. - Fixed-capacity containers.
std::array<T, N>+ an explicit counter instead ofstd::vectorfor bounded collections — contiguous, no indirection, the limit visible at compile time. - HAL discipline. Platform and atomics access goes through a hardware
abstraction layer (
phyriad::hal), with a lint pass (scripts/lint_hal.*) that rejects raw platform calls outside it. - Tests + sanitizers + a perf-regression gate run in CI on every push (see the badges at the top).
Performance claims are held to an explicit standard, and we are honest that not all of today's published numbers meet it yet:
- The full inventory of every benchmark, graded by methodology, is in
docs/planning/TEST_INVENTORY.md. Each published claim carries a trust tier — A (defensible), B (partial), C (not yet trustworthy). - The plan to bring every benchmark up to standard — warmup, repetition,
percentile/distribution reporting, fair apples-to-apples comparisons,
and a recorded environment block — is in
docs/planning/TEST_VALIDATION_PLAN.md. - As that validation lands, the numbers in this README and in
docs/EXPERIMENTAL_BENCHMARKS.mdare being replaced tier by tier with re-measured, reproducible results. Until a number is marked validated, treat it as preliminary.
The honesty stance behind all of this — including why an LLM-assisted
project publishes its own "these numbers aren't validated yet"
disclaimers — is in
docs/COMO_TRABAJO_CON_LLM.md.
A continuación va un extracto del plan de implementación de Ayama tal como
existió en la era gamma del proyecto (cuando el framework todavía se
llamaba así). Es el tipo de documento que precede a cada pilar:
restricciones, decisiones técnicas concretas, patrones a aplicar. Lo
incluyo para que se vea el "régimen estricto" del que hablo arriba. El
archivo completo (1900+ líneas) está en
docs/planning/archive/ayama/AYAMA_IMPLEMENTATION_STRATEGIES.md.
Nota: este documento usa los nombres antiguos (
gma::, Gamma) — el proyecto se renombró a Phyriad después de esta planificación. La metodología y los patrones siguen vigentes, solo cambia el namespace.
# Ayama — Implementation Strategies
## Patrones técnicos concretos para máximo rendimiento, eficiencia y UX
Version: 0.3 — Mayo 2026
Foundation: Gamma Framework release line 1.1.0
Audience: implementadores de cada Bloque del Master Plan.
Este documento NO redefine los Bloques (eso está en el Master Plan).
Esto es la **caja de herramientas técnica** con patrones concretos,
decisiones difíciles ya tomadas y código de referencia. Cuando se
implementa un Bloque, primero se consulta acá si hay un patrón
aplicable.
## Tabla de contenidos
- §1 — Performance: zero-alloc hot path
- §2 — Performance: lock-free e IPC
- §3 — Eficiencia: anti-parasitic resource budget
- §4 — Eficiencia: adaptive ticking y power awareness
- §5 — Eficiencia: ETW con bajo overhead
- §6 — UX: Auto mode pipeline
- §7 — UX: clasificación de procesos
- §8 — UX: persistencia y aprendizaje
- §9 — UX: transparencia y reversibility
- §10 — Robustez: error handling y degradación
- §11 — Compatibilidad: cero invasive operations
- §12 — Templates de código reusable
- §13 — Pilares nuevos (Gamma 1.1.0): process / ipc / etw
## §1 — Performance: zero-alloc hot path
### 1.1 Regla maestra
**Toda struct/buffer del hot path se construye una vez en start() y
vive hasta stop().** Ninguna llamada en el bucle de tick puede invocar
new, malloc, std::vector::resize, ni cualquier path que pueda allocar.
### 1.2 Pre-allocación estándar
Cada componente principal expone una constante kMax* y usa std::array
o buffer raw alineado:
class ProcessObserver {
public:
static constexpr uint32_t kMaxTargets = 32u;
private:
alignas(64) std::array<TargetProcess, kMaxTargets> targets_;
alignas(64) std::array<TargetMetrics, kMaxTargets> metrics_;
uint32_t n_targets_{0u};
};
No usar std::vector para colecciones de tamaño acotado. Usar
std::array<T, N> con un counter aparte. Esto:
- Elimina indirection.
- Garantiza layout contiguo (cache-friendly).
- Hace explícito el límite en compile-time.(El resto — §1.3 a §13.5 — está en el archivo completo.)
See CONTRIBUTING.md for development setup, coding
standards, and PR workflow. Phyriad is open to bug reports and benchmark
contributions; perf-sensitive changes require a
scripts/check_perf_regression.ps1 pass.
Community standards: CODE_OF_CONDUCT.md.
Licensed under the Apache License, Version 2.0.
Phyriad is a research/engineering artifact. It is provided "as is" with no warranty. See LICENSE §7-8 for full disclaimers.
@software{phyriad_2026,
author = {Eduardo Ramos Mendoza (Swately)},
title = {Phyriad: A C++23 runtime built on stigmergic dispatch},
year = {2026},
url = {https://github.com/Swately/phyriad},
version = {0.1.0-experimental},
note = {Stigmergy as a first-class library pillar. Cross-platform
C++23 (Linux gcc 13 / clang 18 + libc++, Windows MinGW /
MSVC; ARM-ready in source). Empirical cross-CCD scaling
measurements published for AMD Zen X3D; Intel hybrid
(P+E) and non-X3D multi-CCD AMD are code-tested and
benchmarks are accepted as PRs (see CONTRIBUTING.md).}
}