From d416c5b2392da7b2dc365e646ab5423292f770ce Mon Sep 17 00:00:00 2001 From: eunhhu Date: Mon, 28 Sep 2026 11:12:37 +0100 Subject: Check TPC-C's consistency from one snapshot a side, and measure TPC-C on RAM and an SD card --- README.md | 14 ++++++++++---- 1 file changed, 10 insertions(+), 4 deletions(-) (limited to 'README.md') diff --git a/README.md b/README.md index 4fbb74a..79a350b 100644 --- a/README.md +++ b/README.md @@ -2,10 +2,12 @@ **Current app model (2026-09-27).** Apps are written in [aup](/srv/git/aup.git) and run as Pure modules ([format v5](docs/design/008-module-format.md)), verified completely before they execute: declared states persist -in Pure's tree store, every event is a transaction, views are pure functions of state. The same spec becomes a +in Pure's store (lists as images and a log of their changes, the rest in its tree), every event is a transaction, +views are pure functions of state. The same spec becomes a terminal UI, a CLI, spoken sentences and a web page through [Vega](/srv/git/vega.git), and an HTTP service through `pure-serve`: views are GETs and inputs are POSTs, with JSON bodies (groups included) read in place; answers are -durable, a commit being one contiguous write and one sync; views are read from a snapshot of the last save, so +durable, a save being one log entry (and a tree commit when more than lists changed), each one write and one sync; +views are read from a snapshot of the last save, so reads never wait for a sync. What an app sends is saved with its event and delivered over HTTP in order and in batches, and a receiving app applies each message once; sealed to the receiver's key (HPKE, one session a wire, authenticated by the sender's key), no relay between them can read or change it, at the speed of unsealed sends. @@ -14,13 +16,17 @@ shows a line on the other node's screen in about a millisecond). Queries are mod their own (`aup query`), verified when registered and shown from snapshots. Folds run a leaf of a list at a time and a fold in a table's column is answered for every row from one pass over its list, so on pgbench's tables of 100,000 accounts a group-by, a join and a correlated rank run 3–420x faster than on SQLite, and faster than SQLite given a -DBA's indexes but for one count, with no index declared. Measurements against axum and drogon on a Raspberry Pi 5 +DBA's indexes but for one count, with no index declared. TPC-C's five transactions, written as one aup app, leave +SQLite's state row for row from the same inputs, and run 4x faster than SQLite in RAM (39,449 against 9,493 a +second, HTTP and JSON included) and 56x faster on an SD card (3,073 against 55), both syncing each commit +([092](docs/research/092-tpcc.md)). Measurements against axum and drogon on a Raspberry Pi 5 are in [075](docs/research/075-http-host-against-axum.md), [077](docs/research/077-apps-as-http-services.md), [080](docs/research/080-snapshot-reads.md), [081](docs/research/081-tail-records.md), [082](docs/research/082-json-in-place.md), [083](docs/research/083-delivery-over-http.md), [086](docs/research/086-sealed-sends.md), [087](docs/research/087-small-reads-and-idle-memory.md), [088](docs/research/088-sealed-sessions.md), [089](docs/research/089-messenger.md), -[090](docs/research/090-tables.md) and [091](docs/research/091-queries.md); the status table is +[090](docs/research/090-tables.md), [091](docs/research/091-queries.md) and [092](docs/research/092-tpcc.md); the +status table is [CHECKPOINT.md](CHECKPOINT.md). The source follows the principle below, a small core with the rest selected around it -- cgit v1.2.3