| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| ... | |
| |
|
|
| |
descent (aup's examples/json_tree.aup: value(d, i) -> Json, number giving the value and where it ends, each call's own let's lists, string's escapes joined by char(u), a depth-first walk passing items as values) against Python's reading walked so: JSONTestSuite's 95 y_ taken alike, no n_ taken, 2b's 6 i_ taken (a lone surrogate refused by char as encoding); 100,000 and 50,000 deep refused as memory (the frames fill the event's room, 0.2 s), 30,000 deep taken (past Python's json); 300 random documents alike; in make check (module_specs' digest now depth first, three paths); 142 lines against the same design's 105 in Python (json_rec.py; the bar missed: 24 lines of declarations, 23 of braces), 46 times cJSON's time and 1.6 times plain Python's (600 ns a byte, 248 Pure instructions; 71% in the steps, about 10% in calls, 66,000 calls a document, most of them small block fns like skip); characters against Python's ord in aup's check; probes: p5-chars compiles, p4-rec (a view calling itself) refused; instruction counts: the workloads' modules the same, batches within 0.001% of 2b (BFS -0.21%), the executor alone -0.001% to +0.30%, the bank's queries -0.30% to +0.11% (four runs each; bar 1%); json_rec_time.c (cJSON, a depth-first digest compared first); CHECKPOINT's direction row through 2c
|
| |
|
|
| |
batches within 0.001% of 2a (BFS +0.36%, within its own runs' spread), the executor alone -1.3% to +0.4% (step's four cases more, mixed signs; -1.31% to +0.59% from before stage 1), the bank's queries -0.66% to +0.05% (four runs each; bar 1%); CHECKPOINT's direction row through 027's 2b
|
| |
|
|
| |
examples/json_tree.aup: a variant, lists in records, match, appends into a field's list, number(t)) and walked for a digest, against Python's reading: JSONTestSuite's 95 y_ taken alike, no n_ taken, 6 i_ taken; 300 random nested documents alike; in make check (module_specs, the suite and 100 random documents, three paths); 167 lines against the same design's 133 in Python (the bar missed: the type declarations), 40 times cJSON's time and 1.3 times plain Python's (556 ns a byte, 525 instructions); json_tree.py, json_tree_time.c (cJSON linked, digests compared first)
|
| |
|
|
| |
executor alone within 0.14% of stage 1, the bank's queries +0.28% to +0.80% where they hold still and +0.17% to +0.45% on average where they do not (four runs each; bar 1%): step's four cases more, not the held slots emptied each event (left to modules that hold some, the counts the same)
|
| |
|
|
| |
examples/json.aup, 80 lines against the same design's 90 in Python): JSONTestSuite's 95 y_ cases taken and 188 n_ refused, 21 of the 35 i_ taken, the three paths alike, in make check (module_specs, the 316 small cases in tests/specs/json under their MIT license, the two large ones made and hashed); 116 times C's time and 1.2 times plain Python's (299 ns a byte, 339 instructions); && and || made to decide alone (writing it, i < n && d[i] read past the end) with AND and OR kept where the right side cannot fail, every other module byte for byte the same; SHA-256 again with formats and joined bytes, 42 lines and 159 times C
|
| |
|
|
| |
byte the same, the executor alone moved matmul +0.43% and BFS -0.34% (knapsack, roots, join within 0.03%; the bar of 0.1% missed, mixed signs: four cases more in step), the bank's queries -0.22% to 0.00% (bar 1%); the four cases out of line in a noinline function (b23) cost 6-15% of the executor's instructions (a call taking frame from step: the register cliff) and were taken back; CHECKPOINT's direction row through 027's stage 1
|
| |
|
|
| |
examples/sha256.aup) right for FIPS 180-2's examples and 138 more messages on every path, in make check against hashlib; 52 lines against Python's 28 (the bar missed: no formatting, no bytes joined or sliced, no lists as values, moved into stage 2), 176 times C's time and 0.43 of plain Python's (1,591 ns a byte; a block's 19,129 instructions, 39% of them the inlined fn's literals not folded); 044's check, time.c against the same algorithm in C (digests compared first) and the Python reference
|
| |
|
|
| |
inflate, JSON, UTF-8 and line breaking, relational queries and graphs, text editing, box layout, HTTP/1.1 by packets, retries and timeouts, constant-time crypto) with five criteria (written in aup and Pure alone, no workaround, lines against a Python reference, time against C, the spec's own vectors passing in Pure's checks on three machines); ten probes (044) show today's aup stops at a byte by position, bit operations, nesting, recursion, variants and reading a character; the core's minimal candidates and the rule against piling up (only what two specs need); SHA-256 and JSON first
|
| |
|
|
| |
spare_count they moved its large arrays and knapsack ran 7% slower at the same instructions (8.79 against 8.29 ms), at its end about 2% (8.45); research 139's afterword: 026 not taken heavily (the user's word), the one light cut made (a nested count loop's rounds sweeping only when few lanes are left: matmul 25.85 to 24.3 ms), the walk loops kept sweeping each round (held, BFS's batches ran out), and the stop; 041 runs of b21
|
| |
|
|
| |
a load would make, interpreted a step at a time (scalar steps by the executor's rules, kernel steps over four-byte lane registers fixed at load with two buffers each, a list's cells once a batch, a deferred set after its distance check), against the same kernels called straight and natural.h's C: matmul 10.36 ms (straight 7.17; the executor's 25.8 with 3.6 of making), knapsack 4.16 (straight 3.76; the executor's 8.19); 139's question, bars and b20's split (matmul's 11.1 ms of interpretation, knapsack's 1.9)
|
| |
|
|
| |
at once in integers (join 116.0 to 110.5 ms, short of 108: what is left is the same cells' memory, read, add and write again), decide's bit found once (BFS 23.2, short of 21.5: the tail's time was its loads more than its instructions), and the batch executor's loops aligned to 64-byte lines (the hot loops' placement had swung knapsack 6% at the same instructions; the lists' loops aligned too cost the bank's queries 1-2% more instructions, so not they); against b9 matmul -36%, knapsack -28%, roots -7.6%, join -6.2%, BFS -3.9%, the executor alone, the bank queries and TPC-C (+0.7%) as they were; 025's bars and what each stage measured; 024 and CHECKPOINT say so
|
| |
|
|
| |
comparisons counting their lanes): knapsack 10.07 to 8.25 ms (bar 8.6; b9 11.46, the compiled code 7.9), its instructions 12.2% below b9's; what is left of knapsack's gap is the per-batch interpretation (about 3 ms), not the kernels (ADD 1.7, GT 1.7, the masked set 0.55 ms); the others the same by instructions; make check's server_view_workers timed out once (the known flake), passed 3/3 alone and in a full rerun; bank queries' instructions within 0.1% of b9's, TPC-C -0.3%; the two large gaps left (matmul's nested rounds, BFS's candidate tail) the user's to choose
|
| |
|
|
| |
no lanes while every lane's e is the same, a list's cells once a batch): against b9, interleaved, matmul 40.01 to 25.97 ms, knapsack 11.47 to 10.07, roots 8.97 to 8.29, join 117.2 to 115.8, BFS and sort the same; sum0 8.69 to 1.01 (bar 1.5); matmul short of its bar (21): the nested rounds' interpretation (about 14 ms) and the matrices' making (4-5) were left out of the arithmetic; the executor alone and the bank queries' instructions as b9 (0.08%), TPC-C +0.7%; stage 4 next (knapsack's six passes to three)
|
| |
|
|
| |
no lanes while every lane's e is the same), interleaved with b11 and b12, and their counts: matmul 36.10 to 26.56 ms (instructions -20%), roots 8.82 to 8.31 (-6.1%), the executor alone as b9 on all five
|
| |
|
|
| |
interleaved): matmul 38.18 to 36.10 ms with 4.5% fewer instructions (segments in its nested rounds), knapsack's per-batch cost 0.68 to 0.63 us but knapsack 10.35 to 10.51 ms with 1% fewer instructions (its per-element loops placed elsewhere), sum0 1,743 instructions a batch: short of 025's stage-2 bars (9.2 ms, 0.45 us, 33 ms): 025 priced a segment's instruction at 50 cycles, the counts show about 25 instructions, and a batch's cost sits in finds, bounds, read records, lane setup, masks and the deferred store's check; a list's cells once a batch measured at 3% and not made; next, per element: stage 3's four-byte MUL (matmul 21 ms)
|
| |
|
|
| |
interleaved): knapsack's per-batch cost 0.90 to 0.68 us and knapsack 11.48 to 10.34 ms, short of 025's bars (0.60 us, 10.3 ms): 025 counted the pass's per-instruction head as lookups; sum0 2,330 to 1,822 instructions a batch (bar 1,550); matmul 40.0 to 38.2 ms with the same instructions and BFS 24.04 to 24.31 with 0.2% fewer (placement); sum0's 8.69 to 6.13 ms mostly the compiler now vectorizing the reductions' first loop; the executor alone the same instructions; what is left a batch is the pass's Val handling (stage 2); 041 runs.sh pairs, pairs and counts data
|
| |
|
|
| |
only values each batch: knapsack's per-batch cost measured at 0.90 us, 38% of its 11.5 ms (BATCH 1024 against 256 under a sampled profile: re-reading the block about 39%, value kinds 26%, list facts and dependence 22%, dispatch 14%), sum0's 0.33 us, matmul's inner-round dispatch about 13 ms and float-checked arithmetic about 22; five stages (facts at load, static kinds and list facts once a batch, typed kernels, fewer passes, the tails) with bars from those shares; 041 batch-costs data
|
| |
|
|
| |
executor's way (memory's order, ascending): clang -O2 1.87 ms, gcc -O3 2.11, gcc -O2 9.02 (C 6.2, the compiled code 7.9)
|
| |
|
|
| |
goto in one function (make.py: GCC spills every slot across the indirect branch) and threaded tail calls with the slots as vector arguments (make2.py: an operation its vector instructions, a load and a branch; clang's musttail, GCC's sibling calls); knapsack's inner loop, BFS's frontier and roots' Newton steps against tight passes and C: roots 5.8 ms (C 6.9, the compiled code 9.57), knapsack 29.4 (passes 2.9 with clang, 9.6 gcc; C 6.2; compiled 7.9), BFS 18.1 (passes 9.8; C 8.6; compiled 7.7); NEON gathers lane by lane cost the tiles what they gain in registers
|
| |
|
|
| |
passes through memory; a batch's fixed cost about 6,500 instructions, 1 us, measured by 1024 against 256 lanes: fewer lanes are slower, so 024's L1 sizing was the wrong lever; a candidate's tail about 250), what the database literature measured of the same shape (X100, Kersten 2018's cycles and instructions a tuple, Sompolski 2011, Gubner 2017's in-register aggregation, Photon, Ertl and Gregg), the ways judged by the philosophy (a batch program made once at load; register tiles with threaded dispatch as the one general way past the floor; a table of fused operations and AOT C out), and the deciding experiment with its bar first (three bodies in tiles of 4, 8, 16: within 1.3x the compiled code's cycles an element, or it is not the answer); 041 lanes data
|
| |
|
|
| |
batches BFS 24.0 ms, the compiled code 7.7, alone 92.7; knapsack 11.45 and matmul 40.0, up from b7's 10.3 and 36.5; the executor alone as before) and the search counts on b9 (BFS 112 instructions an edge, 57 cycles; the frontier sum 56 and 20; the compiled code 38.5 and 19, 35 and 15)
|
| |
|
|
| |
ms, the compiled code 7.66, alone 93.4; the others and the executor alone as b6's) and search/: the suite's graph loaded and one handler run again and again (frontier-run: each node's edges' to summed, 70 instructions an edge batched, 35 compiled; search-run: the BFS, 211 and 38.5), counted with icount (2026-10-08-search-counts.jsonl)
|
| |
|
|
| |
compiled code 7.93), matmul 36.41 (14.20), join 118.3 (78.7), sort 55.5 (35.6), roots 8.87 (9.57); the executor alone as many instructions as b4's; costs three ways on b5 and b6 (tagged by version, b4's too: adds 0.65, ops 4.00, recur 21.8, recur4 36.0); frontier.c: the suite's BFS as frontier batches (105,232 of 999,913 edges asked again in order, 99,997 added; walking a batch's edges together 2.17x the edges)
|
| |
|
|
| |
(a step's result, a recurrence's value, the loop's value, a number that stays) rather than a stack's pushes and pops, an operation computed twice in its statement once (x the same until it is done): 1,000,000 rounds of MINSTD 44.4 to 25.7 ms (the compiled code 18.5, the executor alone 73.0); costs/recur.aup
|
| |
|
|
| |
c67f988): batches join 161.2 ms (the compiled code 74.4, alone 423.4), matmul 46.1, knapsack 15.1, roots 9.22; costs/: small modules timed three ways (an instruction about 20 ns a batch, a sum's end about 4 ns a round, an append about 100 ns as the executor's, the nested rounds 10.2 ms against the compiled code's 23.1)
|
| |
|
|
| |
9.57, alone 130.6), knapsack 13.80, matmul 50.03 (14.27, 914.9); join and sort as many instructions with batches as without
|
| |
|
|
| |
batches, the executor alone) and icount.c's instructions and cycles; stage 1 at 10a50dd: knapsack 13.57 ms with batches (1,040.9 alone, 7.52 compiled, C 6.23), the others as they were; the executor's instructions as e2e56dd's or fewer (roots 2.756 to 2.760 billion, cycles alike), knapsack's 21.7 to 0.46 billion with batches
|
| |
|
|
| |
operations apart, interpreted, 57.8 ms (C 32.6; fused by hand 48.4, the tier 2.46x); bfs: a node with more edges than the lanes runs its round alone (tested with lanes of 16, LANES_TEST); runs again
|
| |
|
|
| |
four-byte lanes ascending in memory, 4.54 ms (C 6.38, the tier 7.5; fused 2.70): narrow lanes in memory's order are most of the gain, fusing the rest; runs again
|
| |
|
|
| |
made at build time (no code made at run time), on Pure's forms and checks, against C natural and C given the same restructuring: roots 6.79 ms (C 6.86), knapsack fused four-byte 2.70 (C 6.47, C in the batch's blocks 1.94), matmul lanes over j 6.67 (C 7.10, C swapped and vector 4.88), join 37 / 46 with its recurrence interpreted (C 30), BFS 10.3 (C 10.0, C read ahead 7.0); unfused interpreted operations 11.2 and 17.7-22.1
|
| |
|
|
| |
generic code's (steps 0.1%), what the tier needs for it (a list's count as a changing value); 023 cites words at e2e56dd
|
| |
|
|
| |
knapsack 1.19, sort 1.37, join 2.54, words 5.58, matmul 1.85, BFS 1.61; geometric mean 1.92, from 3-300x at 6b45806), what each change did, the forms measured in assembly, the apps unchanged, what is left (text in the executor, BFS's appends, spills); CHECKPOINT says so
|
| |
|
|
| |
off the number pipes the divisions and sums wait on: roots 10.9 to 9.6 ms (1.39x C). 040 newton.c: roots' loop in the forms the tier may make it (the check as numbers 9.7 ms, in integers 8.7, none 7.7; next in r's register as gcc keeps it 7.0)
|
| |
|
|
| |
20.7 ms, pointer with multiply-add 13.1, apart 10.0, with checks 10.2, a bit tested before each load 13.4): the position's multiply and the pre-load branch cost, the checks hardly; 023 section 5 says so and what comes first (pointer induction, then a full list's copy)
|
| |
|
|
| |
knapsack 1.18, sort 1.37, join 2.62, words 5.46, matmul 3.07, BFS without reading ahead 1.58 (geometric mean 2.09; 3-300x at 6b45806)
|
| |
|
|
| |
apps there are): six pairs in turns, TPC-C's median -1.2% (the pairs -5.2 to +1.4%), the queries' medians within 1% but in_credit's (0.84 to 0.815 ms); the queries' instructions +0.3 to +1.5% on 49b6196 (2026-10-05-counts-49b6196.jsonl), -0.1 to +0.5% after the list's tree paths left HASHED's checks (2026-10-05-counts.jsonl). runs.sh serve, pairs and counts
|
| |
|
|
| |
lists' representation, its meaning) bare, with the checks a compiler could hoist, and with every check where the meaning puts it: hoisted 0.64-1.02x C (0.90 by the geometric mean), naive up to 12x
|
| |
|
|
| |
(knapsack), 4.8x (sort), 22x (join), 12x (words), 304x (matmul), BFS 1.57x without reading ahead; only roots and BFS run as code
|
| |
|
|
| |
knapsack, sort, join, words, matmul, BFS), each against the C one would write, in one process with the same inputs and answers; PURE_AHEAD=0 to measure the code without reading ahead
|
| |
|
|
| |
opens it, read an item and find it in key bits as one, branch back once a round: BFS core 19.6 to 14.9 ms (022)
|
| |
|
|
| |
searched, narrow columns, a JIT with registers and loop guards, read ahead; criteria first
|
| |
|
|
| |
forms by hand beat C only packed, narrow and read ahead (123)
|
| |
|
|
| |
tree's seek, still seven times C's (021)
|
| |
|
|
| |
find a slice against C's 21 (021)
|
| |
|
|
| |
and a Mac (121); 019 points at 020's view workers
|
| |
|
|
| |
shared, two askers 1.95 times one (122)
|
| |
|
|
| |
fingers found and undone (121)
|
| |
|
|
| |
two, and a plain view's reads
|
| | |
|
| |
|
|
| |
criteria (020)
|
