<feed xmlns='http://www.w3.org/2005/Atom'>
<title>pure/.gitignore, branch master</title>
<subtitle>Verified execution runtime unifying state, persistence, and replication.
</subtitle>
<id>http://git.yeowoo.org/pure/atom?h=master</id>
<link rel='self' href='http://git.yeowoo.org/pure/atom?h=master'/>
<link rel='alternate' type='text/html' href='http://git.yeowoo.org/pure/'/>
<updated>2026-10-04T14:36:51Z</updated>
<entry>
<title>Watch a subscriber for writing only while it keeps output, and measure freshness by push and polling (019)</title>
<updated>2026-10-04T14:36:51Z</updated>
<author>
<name>eunhhu</name>
<email>necpition205@gmail.com</email>
</author>
<published>2026-10-04T14:36:51Z</published>
<link rel='alternate' type='text/html' href='http://git.yeowoo.org/pure/commit/?id=90c8edece941f26cd280686c7063a7c9149a2212'/>
<id>urn:sha1:90c8edece941f26cd280686c7063a7c9149a2212</id>
<content type='text'>
</content>
</entry>
<entry>
<title>Measure a link at rest: 132 bytes against a QUIC connection's 38,106 (094)</title>
<updated>2026-09-28T18:41:08Z</updated>
<author>
<name>eunhhu</name>
<email>necpition205@gmail.com</email>
</author>
<published>2026-09-28T18:41:08Z</published>
<link rel='alternate' type='text/html' href='http://git.yeowoo.org/pure/commit/?id=63cc9554f2cd93e46d0413a21cbce05014e2f2b3'/>
<id>urn:sha1:63cc9554f2cd93e46d0413a21cbce05014e2f2b3</id>
<content type='text'>
M1 of design 011. A Pure node allows 1,000 to 1,000,000 senders; each
sends one order and, once told it is stored, rests. At rest a link costs
the node 132 bytes (the sender allowed, 73; its number heard, about 60)
and no transport state; with a million the node runs in 139 MB. A quinn
0.11 service holding the same exchange's clients connected at rest costs
38,106 bytes a connection: 289 times as much, past the design's 1/100.
A link at rest takes its next record in 0.56 ms to stored, one X25519 on
the node included; a new QUIC connection takes 1.06 ms and 2.8 times the
receiver's CPU, without storing.

research/experiments/019-idle-links: links.c, many senders written from
serve/link.h's packet format alone (a second implementation), and the
quinn service and clients (quic/, built offline); run.py makes both
measurements.
</content>
</entry>
<entry>
<title>Run pgbench's transaction on a bank of 100,000 accounts, beside SQLite (090)</title>
<updated>2026-09-27T22:39:29Z</updated>
<author>
<name>eunhhu</name>
<email>necpition205@gmail.com</email>
</author>
<published>2026-09-27T22:39:29Z</published>
<link rel='alternate' type='text/html' href='http://git.yeowoo.org/pure/commit/?id=44740eb93a69a052ee7b4c46f2ccac384c9d4f36'/>
<id>urn:sha1:44740eb93a69a052ee7b4c46f2ccac384c9d4f36</id>
<content type='text'>
benchmarks/bank/bank.aup keeps accounts, tellers and branches as keyed
lists and a history list; a transfer changes a row of each and appends a
history row in one event, as pgbench's TPC-B-like transaction does in
SQL. run.py makes a scale's rows and drives transfers through the load
generator's new transfer kind; sqlite-bank.c runs the same tables and
SQL on SQLite 3.46.1, a connection a thread, WAL.

With lists as trees, transfers run at 30.5k a second on 1,000 accounts
and 24.5k on 100,000 (RAM store, one connection thread, HTTP and JSON
included), where they ran at 3.2k on 30,000 before. Durable on the SD
card, Pure makes 1,339 a second and SQLite with synchronous=FULL 84 to
153. SQLite in process with no HTTP makes about 40k in RAM: recorded as
it is, with the write amplification of 100,000-row tables on the card
and ad hoc queries as what comes next.
</content>
</entry>
<entry>
<title>Add a sampling profiler for machines without perf</title>
<updated>2026-09-27T17:47:05Z</updated>
<author>
<name>eunhhu</name>
<email>necpition205@gmail.com</email>
</author>
<published>2026-09-27T17:47:05Z</published>
<link rel='alternate' type='text/html' href='http://git.yeowoo.org/pure/commit/?id=76f5edb2bcc227c2be743873753792dbc5af1f48'/>
<id>urn:sha1:76f5edb2bcc227c2be743873753792dbc5af1f48</id>
<content type='text'>
benchmarks/sample.c runs a command and samples where its threads spend
user time (the task clock every 50 us, one perf_event_open event a CPU,
since the kernel maps no ring for an inherited per-task event), then
names the samples from the ELF symbol tables of the files the command had
mapped: a stripped library from its debug file by build id. On arm64 it
also takes the link register, so time in a library's leaf (memcpy,
strcmp) is shown again by its caller. The command's user and system time
head the report.

</content>
</entry>
<entry>
<title>Lay Pure out as a core with the parts selected around it</title>
<updated>2026-09-27T12:14:38Z</updated>
<author>
<name>eunhhu</name>
<email>necpition205@gmail.com</email>
</author>
<published>2026-09-27T12:14:38Z</published>
<link rel='alternate' type='text/html' href='http://git.yeowoo.org/pure/commit/?id=37d3a1e152707d2da587440c4cea8601b9ef0fd2'/>
<id>urn:sha1:37d3a1e152707d2da587440c4cea8601b9ef0fd2</id>
<content type='text'>
The app model, the tree store and the HTTP host lived in
prototypes/connections among the earlier document runtime, the store was
known only by its format's name, and Vega compiled six Pure sources by path.
Now, as the README's principle has it:

  core/   runtime, flow and the app model (module*.c), with what the core
          asks of storage (state.h, store.h)
  store/  the tree store (PURETRE3, PUREREC1)
  serve/  pure-serve: HTTP host, outbound delivery, JSON in place
  cli/    pure-run, pure-edit-module

A top-level make builds libpure.a (app model and store, for hosts to link)
and the hosts; make check runs the store's and the app model's tests. The
earlier runtime still builds from prototypes/connections against core/ and
store/ (check, check-tree and check-core pass). Design 009 records the rule:
parts by role behind libraries; git repositories split by coupling, so the
store stays here while its contract moves with the core, and Vega stays apart.

</content>
</entry>
<entry>
<title>Benchmark an app served by its views and inputs</title>
<updated>2026-09-26T15:56:08Z</updated>
<author>
<name>eunhhu</name>
<email>necpition205@gmail.com</email>
</author>
<published>2026-09-26T15:56:08Z</published>
<link rel='alternate' type='text/html' href='http://git.yeowoo.org/pure/commit/?id=768317d789a01d722fe7455d792fed11e6579b5c'/>
<id>urn:sha1:768317d789a01d722fe7455d792fed11e6579b5c</id>
<content type='text'>
run.py --suite app serves the scoreboard of scores.aup (22 lines of aup)
with pure-serve against the same scoreboard written by hand in axum and
drogon: POST /inputs/score?points=N with a name as the body, GET
/views/total and a page of 20 rows as JSON. Durable, the baselines append
each score to a log and fdatasync it before answering (replayed at
start); the load generator learns the three requests.

</content>
</entry>
<entry>
<title>Benchmark the HTTP hosts against axum</title>
<updated>2026-09-26T04:29:48Z</updated>
<author>
<name>eunhhu</name>
<email>necpition205@gmail.com</email>
</author>
<published>2026-09-26T04:29:44Z</published>
<link rel='alternate' type='text/html' href='http://git.yeowoo.org/pure/commit/?id=f0bec42645aa845d1c1d71c6e18ac1521e808fcc'/>
<id>urn:sha1:f0bec42645aa845d1c1d71c6e18ac1521e808fcc</id>
<content type='text'>
A C load generator, an axum service with the same document contract (in
memory, fdatasync, and crash-safe replacement), and a runner that pins the
servers and the load to separate CPUs. On the Pi 5, Pure uses about 40%
less memory, wins with a new connection per request and with eight durable
writers (3.2x the crash-safe axum), but loses 5x on keep-alive reads and
1.5x on 64 durable writers: no persistent connections, one thread, eight
connection slots and two fsyncs per commit. Note 075 records the numbers
and the targets.

</content>
</entry>
<entry>
<title>Establish native micro runtime checkpoint</title>
<updated>2026-09-24T16:14:54Z</updated>
<author>
<name>eunhhu</name>
<email>necpition205@gmail.com</email>
</author>
<published>2026-09-24T16:14:54Z</published>
<link rel='alternate' type='text/html' href='http://git.yeowoo.org/pure/commit/?id=b1ce1927022d374198441afafeb27199fc8a052a'/>
<id>urn:sha1:b1ce1927022d374198441afafeb27199fc8a052a</id>
<content type='text'>
</content>
</entry>
</feed>
