LCM — the Logos Compute Model

Data dominates. If you’ve chosen the right data structures and organized things well, the algorithms will almost always be self-evident. Data structures, not algorithms, are central to programming.

— Rob Pike, Notes on Programming in C, 1989.

LCM is the compute model Logos targets. It is not a description of any one machine. It is the abstract substrate the language is designed for: a set of small cores (xPUs) exchanging messages over a hardware-accelerated transport (HRPC), placed as physically close to the data they touch as the platform allows.

LCM is the physical grounding of the Hest dataflow model — where Hest asks “what is the unit of composition above fn?”, LCM answers “a small core close to its data, reachable only by message.” This page describes LCM as a compute model and a target class for Logos.

x86_64/Linux is, from this point of view, just one of the targets — a particularly large and well-supported one, and currently the only target the toolchain produces native binaries for. It is not the architectural centre. Logos does not yet have language-level features for declaring which functionality is available on which target; that will come later, alongside richer cross-target tooling.

LCM is the architectural inheritance from the Memoria Framework, reframed: the substrate moves into Logos, while Memoria continues as a separate framework and becomes, over time, something like an operating system for LCM — the data layer, processing layer, and structured-storage layer that runs on top.

Why LCM looks this way #

Processing can be compute-intensive, IO-intensive, or hybrid. It is compute-intensive when each element of data is processed many times (sorting, matrix multiplication); otherwise it is IO-intensive (hash tables, random-access structured queries). Hybrid workloads contain both, but in clearly separable stages — JOIN is IO-intensive, SORT is compute-intensive, and an SQL query may go through both.

Compute/IO-intensity is not an intrinsic property of an algorithm; it is a property of an algorithm against a memory architecture. By IO we mean off-die traffic, which is typically 100–1000× slower than intra-die traffic. Each algorithm has an access pattern — predictable, random, or mixed — and good performance comes from arranging data so most access stays intra-die.

Mainstream CPUs lean almost entirely on caching and prefetching to bridge this gap. It works well in many cases, and it is not going away. But it has well-known costs:

• Caching is not free. A miss costs dozens of cycles; a hit still pays for tag lookup. Raw scratchpad SRAM can be much faster in the best case.
• Caching interacts badly with virtual memory: address translation, TLB misses, context-switch invalidation.
• Caching of mutable data does not scale well across cores — coherency traffic dominates.
• To extract performance under irregular memory latency, cores grow into large, hot, expensive out-of-order machines.

Raw DDR5 latency is around 25–40 ns; full system latency is roughly 75 ns; under TLB pressure, several times that. Inter-core latency on modern multi-socket systems ranges from a few ns (SMT siblings) to hundreds of ns across sockets, with the average on the order of dozens of ns — and worse when many cores talk at once. This makes general-purpose multicore CPUs poor at fine-grained dynamic parallelism, even though they are still the best hosts for latency-sensitive workloads like databases, symbolic reasoners, and constraint solvers.

LCM is a response to this. It assumes a different tradeoff: lots of small cores close to the memory, communicating by message rather than by coherent shared state.

Persistent data structures as the default #

LCM expects persistent data structures (PDS) — committed versions are immutable, and immutable data shares freely across parallel processing units without coordination. PDS need garbage collection (atomic reference counting or generational), which in turn needs strongly-ordered, exactly-once delivery — practical at rack and (modest) DC scale.

PDS pay a cost on single-threaded sequential access — O(1) becomes O(log N). Functional languages amortise some of this. The benefits start dominating around 10+ cores; below that, the overhead is real. LCM is designed for the regime where that tradeoff pays.

Accelerating PDS asks the platform for hardware-assisted atomic counters, similar concurrency primitives, and a fabric that supports robust exactly-once delivery (which reduces to bounded-history idempotent counters). This is the same immutable-shared-memory substrate Hest’s operator state and Writ stand on.

High-level architecture #

LCM is inherently heterogeneous and explicitly supports three computation domains — the same three Logos itself plans as first-class language layers (see Language Overview):

1. Generic mixed dataflow and control flow. Most practical compute- and IO-intensive code, runnable on CPUs or specialised hardware.
2. Integrated circuits — fixed (ASIC) and reconfigurable (FPGA, structured ASIC). High performance and low power for stream/mixed-signal stages, with nanosecond-scale event resolution.
3. Rule- and search-based — forward chaining (CEP, streaming) and backward chaining (SQL/Datalog).

Domains connect through HRPC — Hest’s first wire member, a unified hardware-accelerated RPC + streaming protocol. HRPC is conceptually similar to gRPC, but designed for direct hardware implementation, not for an HTTP/2 software stack. Within LCM, HRPC is the universal transport: intra- and cross-domain communication, including kernel-level traffic, all flow over it.

When HRPC is in hardware, the OS shrinks. There is no longer a single fully-featured kernel mediating every operation; what remains is a nano-kernel — only the parts of HRPC that, on a given target, must run as software. A Logos kernel running on a CPU core inside an accelerator can listen to a stream produced by an FPGA, call into smart-storage, or invoke near-memory compute on a CXL device — all through the same protocol.

OS-kernel functionality decomposes into services running on whichever device is closest to the data. Storage — historically the largest piece of OS surface — is owned by ‘smart-storage’ devices able to evaluate complex queries in streaming and batching modes.

Memory is no longer a single shared address space. It is a set of buffers with different affinity to compute. Programming this directly is harder than programming a flat-memory CPU — but it is also the same kind of work distributed-systems engineers already do at larger scales every day.

LCM does not guarantee cross-environment portability. Different accelerators provide different default runtimes, memory hierarchies, and cluster topologies. Some Logos code will need substantive rewrites to move between environments. Logos’s job is to keep the unavoidable cost as low as possible — through metaprogramming, metafunction-driven specialisation, and the build/type system as a data platform — not to pretend the cost isn’t there.

xPU — the processing element #

The reconfigurable extensible processing unit (xPU) is LCM’s structural unit. The defining property: HRPC is the only way it talks to the outside world. From outside, an xPU is a set of HRPC endpoints described in the usual HRPC tooling (IDL, schema, codegen). That includes all external memory traffic (cache transfers, DMA), debug and observability traffic, runtime exception signalling, and application-level HRPC.

HRPC and the system-level endpoint specs are open, so independent vendors can contribute specialised cores and middleware. Logos code can have deep call chains and substantial code size, so an instruction cache is essential; a “stack cache” — a dedicated data cache for thread stacks — is also load-bearing when the internal data memory is used as a scratchpad rather than a D$.

What an xPU does not carry is cache coherency. LCM relies on PDS: mutable data is private to a writer; readers see only immutable data. Where shared structured mutable access is required (atomic ref counting, etc.), it is done through explicit HRPC messages to hardware-accelerated services rather than through coherent shared memory.

Containers and memory parallelism #

A container is the structured-data unit Memoria contributes to LCM. Containers are block-based and represented as B+Trees, ephemeral or persistent (multi-version). Anything that can be efficiently represented as an array can be efficiently represented as a container. There are five basic building blocks, all supporting fixed- and variable-length elements: an unsorted array, a sorted array, an array-packed prefix-sums tree, an array-packed searchable sequence, and an array-packed compressed symbol sequence.

Embedding logic into a DRAM die is hard but possible — Processing-In-Memory (PIM). The cheaper alternative is to put logic on the memory module or in the CXL controller — Processing-Near-Memory (PNM): lower throughput and parallelism, slightly higher latency, but built on existing process nodes. Either way the point is the same: accelerating containers wants as much memory parallelism as possible, with xPUs placed as close to the physical memory as the platform allows. Existing accelerators — designed for matrix multiplication on neural networks — do not optimise for this, because GEMM is latency-insensitive. LCM workloads need a different class of accelerator: maximised effective memory parallelism.

Accelerator module #

The whole point of LCM is to maximise memory parallelism by bringing processing to the data — primarily for latency, secondarily for throughput. Beyond PNM/PIM, HRPC, and PDS, LCM does not pin a specific hardware architecture. The figure below is one instance of an accelerator the toolchain will support.

Essential components: xPUs (RISC-V cores with hardware support for HRPC and core LCM data-structure operations); a network-on-chip (2D mesh, or an N-dimensional hypercube for better latency in the general case); a main HRPC service gateway and many local routers; service endpoints for hardware-implemented primitives (atomic ref counting and other shared concurrency primitives); shared on-die SRAM used as scratchpad / cache / rings; a smart DRAM controller with embedded PNM xPUs; and external connectivity. The result is scalable (no full-chip coherence), scales down and up (MCU to wafer), composable, and extensible — the only requirement is that everything talk HRPC over published interfaces.

Matrices and tensors #

Many data structures are arrays; dense graphs are square matrices, and many graph algorithms reduce to matrix operations. LCM needs efficient matrix support, but the GEMM-for-NN space is being explored aggressively elsewhere and is close to its local optimum. Logos’s primary focus is sparse data structures via PIM/PNM with low memory-access latency. GEMM can be fused in three reasonable ways — systolic processors / CGRAs attached to xPUs as HRPC devices; a separate GEMM-optimised xPU or accelerator module; or outsourcing to external projects — and in all three, hardware HRPC is foundational. The whole HRPC story is to generate IP from semantically-rich IDL, the way SOA codegen does in distributed software today.

CPU mode #

Multicore MMU-enabled CPUs are not the best LCM substrate — MMU overhead, the memory hierarchy, and OS scheduling all work against the model. They are also, by an enormous margin, the largest deployment base, and the only target Logos compiles to today. So Logos treats CPU mode as a first-class member of the target family. As specialised hardware becomes available, it joins the family incrementally — without dethroning CPU support.

Where Logos fits #

LCM is the architectural target; Logos is the language and toolchain aimed at it.

• Writ — the relocatable tagged data substrate — is the on-disk, in-memory, and on-the-wire shape of structured data across LCM. There is no FFI between values and data; a document is just a value.
• HRPC is the transport for everything that crosses an xPU boundary, from an await in user code to a debug event — Hest’s first wire member.
• Metafunctions — ordinary Logos code that runs at compile time — are how LCM-specific specialisations (containers, layouts, scheduling, codegen variants per xPU class) are expressed, instead of through C++-style templates.
• The build system is itself a data platform (Datalog query engine, layered abstractions, large-data support), not a cc driver — because per-target specialisation, design-space exploration, and cross-domain codegen are first-class operations in LCM.
• Convergent computation models. Control flow is one model; production systems and dataflow (Hest) are slated for first-class language integration, mirroring the three compute domains LCM supports natively.

Memoria’s role #

Memoria and Logos are co-developed. Some of Memoria moves into Logos and stays there — Writ (already done, as the data substrate), LCM (this document), metafunctions and the frameworks built on them, and build / type-checking infrastructure as Logos’s own build system grows up. The rest stays as an external framework. On top of LCM, Memoria becomes the data-platform layer — containers, persistent storage, query engines, structured runtime services — closest to what an OS would be: the layer between LCM-as-substrate and the application. Splitting it this way decouples Logos’s release cycle from Memoria’s, while keeping the architectural pieces that must be in the language inside the language.

Implementation strategy and status #

LCM is a substantial technical and organisational undertaking. The early roadmap, in stages: a configurable RISC-V emulator with LCM-specific ISA extensions and HRPC machinery, so core data structures and algorithms can be ported and benchmarked before any hardware exists; reference HDL IP — Writ operations as RV ISA extensions, HRPC core protocol/transport/routing, a configurable RISC-V xPU — enough for hardware developers to experiment with (early experiments target an open-toolchain FPGA board such as a Xilinx Alveo U50); and integration into the Logos build system / data platform, so design-space exploration, codegen variants, and per-target specialisation become ordinary toolchain operations.

LCM is a target description, not a delivered product. Today, Logos compiles to x86_64/Linux. The xPU emulator, the HDL reference IP, and the build-system integration are roadmap items, not current capabilities. What is in place today is the part of LCM that lives inside Logos itself: Writ as the data substrate, metafunctions as the specialisation mechanism, HRPC as the planned transport, and a language design that does not bake assumptions about coherent flat memory or a single fully-featured OS kernel into the surface.

Related #

• Hest: dataflow as a language feature — the dataflow aspect LCM physically grounds; HRPC is Hest’s first wire member.
• Writ: the data substrate — the relocatable immutable structures that are LCM’s shared-memory model.
• Language Overview — the three compute domains as first-class language layers.