aboutsummaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
* Research 140, 027's stage 2b measured: JSON read into a tree (aup's ↵eunhhu7 days6-1/+397
| | | | 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)
* Module format and executor: 027's stage 2b, lists in records: a record field ↵eunhhu7 days7-21/+368
| | | | of type LIST (its items' record in its default) holds a list the event made, its number an i64 in the cell (0 an empty one), so lists keep their inside, batches and the JIT as they were (the JIT's append fast path leaves such records alone); LIST_VALUE (a copy of an event's list, nothing made for an empty one), LIST_BIND (a register, an event's list flagged PURE_LIST_BOUND, read and walked, never changed by code), APPEND_IN (an item into the list in a field of an event's list's item, copied first when another value shares it or a register is bound to it), sharing counted where cells take them; such records only in event lists (no stored, transient or message list, no key); the event's lists go as each event or view's body begins, registers given back their own; record field names may be paths (at.x: records in records, flattened by aup); NUM_PARSE (a text written as a JSON number, its nearest double, core's pure_parse_number); unit tests (values copied, shared then appended, a bound register seeing what it was bound to, three events alike, 6 refused; under ASan and UBSan too, which found the record kinds' missing LIST)
* Research 140: 2a's instruction counts: the workloads' modules the same, the ↵eunhhu7 days5-0/+44
| | | | 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)
* Module executor: events and views empty the values held by name only in a ↵eunhhu7 days2-2/+4
| | | | module that holds some (PureModule.held, set at load): the bank's queries had paid for the 32 slots each (field +0.80%, found +0.50%, large +0.54% from s22 to s24)
* Research 140, 027's stage 2a measured: whether bytes are JSON (aup's ↵eunhhu7 days324-18/+709
| | | | 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
* Module format and executor: 027's stage 2a: BYTES_SLICE (bytes from a up to ↵eunhhu7 days5-21/+313
| | | | before c, whole positions inside, numbers or i64s), BYTE (one byte of an i64 0-255), BYTES_LOAD and BYTES_STORE (an event's 32 values held by name, 0-15 bytes and 16-31 texts so a text's hold UTF-8 alone, emptied as an event or a view's body begins, appended to in place, counted in the room: MEMORY past it), CONCAT of bytes, NUM_TEXT in a format (a width padded with spaces or with zeros after the sign, d x X b o of an i64 or a whole number, f with 0-30 digits; -0 as 0), a reply of a held value kept by value, LEN wherever a value is read (it had been for handlers alone); pure-run's message NAME @PATH (the file's bytes, of any size); unit tests (16 formats, 9 slices, held values set, appended, set to a part of themselves, emptied each event, a doubling stopped by the room, a reply kept, 7 refused)
* Research 140: stage 1's instruction counts: the workloads' modules byte for ↵eunhhu7 days4-2/+60
| | | | 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
* Research 140, 027's stage 1 measured: SHA-256 written in aup (its ↵eunhhu8 days7-0/+306
| | | | 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
* Module format: bits and bytes (design 027's stage 1): I64_BITS (and, or, ↵eunhhu8 days4-5/+210
| | | | xor, a left shift as a times 2^b failing as overflow past the range, a right shift as floor(a / 2^b), a count outside 0-63 failing as limit: integers in two's complement without end), BYTE_AT (the byte of any bytes value at a whole position, a number or an i64, else limit), BYTES_OF (a list of one i64 field as bytes, a value outside 0-255 failing as limit) and INDEX_AT (a list's item at a position, not_found where there is none); the fold-shape and batch analyses count their arity and the lists they read; unit tests of the ends (27 bit cases, 11 reads of a constant's and a text state's bytes, 7 refused)
* Design 027: the computation core inside 026's contract: an app's state one ↵eunhhu8 days1-0/+189
| | | | typed value built of bool, i64, number, bytes (text the UTF-8 ones), records, variants and lists of anything (an unkeyed list keyed by position), anchors for cursors and indexes; functions that may recur and while, ending by the budget as EVM's gas (the module the unit of determinism); bit operations on integers as infinite two's complement within i64; folds left folds in meaning, reordered by the implementation only for the same answer; meaning apart from representation; answers to 026's suspects; five stages (bytes, bits and lists of numbers for SHA-256; nesting, variants, recursion and characters for JSON; nested state stored; patterns gathered; the number model) with bars
* Research 140: a suite of eleven specs from different fields (DNS, SHA-256, ↵eunhhu8 days14-0/+205
| | | | 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
* Design 026: the app contract written as mathematics, the part to freeze at ↵eunhhu8 days1-0/+185
| | | | 1.0: an event a total, atomic, deterministic function step(S, E) -> (S, Out*) or a fault (budgets in instructions and bytes), time an input, views pure functions of the committed snapshot, the history seen a prefix of commits, delivery in order and once with the transport's state in the store, values the same on every path, replacement joined by names; the layers it removes; its own suspects (input and view kinds, cursors and indexes, keyed documents, the number model, the budget's unit, fixed limits); the computation language rebuilt before 1.0, no compatibility kept before it (the user's word)
* Batch executor: the round's fewest-left marks at the end of Batch: put after ↵eunhhu9 days4-1/+77
| | | | 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
* Batch executor: a nested count loop's rounds sweep their lanes and masks ↵eunhhu9 days1-5/+42
| | | | back only when fewer are left than the most a round has taken and one (fresh and new_mask keep the fewest left; nested rounds' marks given back to the rounds around), else once after the loop as the last round did; matmul 3.6% fewer instructions, 4.5% fewer cycles (a sweep a k-round); a walk's rounds and a spread walk's chunks still sweep each: so held, BFS's batches ran out of lanes and went back to the executor (36.9 ms, the answers the same), what their filters and selections take not told by a round's fewest left; seeds 1 2 3 5 23 (default and PURE_SELECT=all), the fixed sources (also sanitized), the unit tests and ASan's pass
* chore: add Apache 2.0 licenseeunhhu10 days1-0/+202
|
* Research 139: what a program made at load per batch loop would take (the ↵eunhhu11 days1-2/+49
| | | | deciding prototype 043): the executor's extra over 041 is interpretation, not semantics (matmul 11.1 ms of it, checks 0.2); the program interpreted a step at a time, with the executor's checks, ran matmul's loop in 10.36 ms and knapsack's in 4.16 (straight kernels 7.17 and 3.76; the executor about 22.2 and 7.3), about 14 and 5.4 ms with the making (bars 15 and 6.5; the compiled code 14.2 and 7.9); the buffer rule it found (registers at load, two buffers each so a result never lands on its operand, 24 lanes apart); the suite's five bodies sorted (matmul, knapsack, join's order loop straight-line; roots and BFS not); 026's scope as straight-line programs with the pass for the rest, and its risk
* 043 programs (research 139, in progress): a batch loop's body as the program ↵eunhhu11 days3-0/+457
| | | | 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)
* Research 138: the batch executor's stage 5, design 025 made: sums into cells ↵eunhhu11 days34-5/+489
| | | | 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
* Makefile: loops aligned in the batch executor alone (BATCH_OPTIMIZE): the ↵eunhhu11 days1-6/+8
| | | | lists' loops so aligned cost the bank's queries 0.8-2.0% more instructions (the padding) with their cycles mixed
* Makefile: the lists' and the batch executor's loops each start at a 64-byte ↵eunhhu11 days1-1/+4
| | | | line (-falign-loops=64 in LIST_OPTIMIZE): a change anywhere in module-batch.c moved knapsack's hot loops and it ran 8.26, 8.74 and 8.20 ms with the same instructions; aligned, every batched work's cycles fell (knapsack 6%, matmul 1.8%, BFS 1.1%) and the executor alone stayed within its noise, at 0.7-2.3% more instructions (the padding)
* Batch executor, stage 5 of design 025: decide finds a kept round's bit once ↵eunhhu11 days1-18/+15
| | | | (an add of the key it asked, as a filter's is, takes the place found) and clears only the words of the bits it set (their places kept as it sets them): BFS 0.4% fewer instructions; seeds 1 2 3 5 23 (default and PURE_SELECT=all), the fixed sources (GRAPH's exists, memory and work faults where they were) and the unit tests pass
* Batch executor, stage 5 of design 025: the sums into cells at once from ↵eunhhu11 days2-2/+145
| | | | round 0 (sums_in_words): the rows and e's in four bytes first (vector code) up to the first round whose e is not a whole number below 2^32, then each round's sums in turn in integers for a one- or four-byte cell while it stays in its bytes, as a number for an eight-byte cell while finite; where one is not so the executor's way goes on from that round and sum (nothing faulted or widened before it); join 4.9% fewer cycles; SUMS_SOURCE in check.py (sixteen rows met again and again, a one-byte column widened mid-batch, a four-byte one past 2^32, a masked fraction), 7,912 rounds at once and 3,228 the other way, the same three ways; seeds 1 2 3 5 23 (default and PURE_SELECT=all), the fixed sources (also sanitized) and the unit tests pass
* Design 025: stage 5's bars measured again on b16: BFS's candidate tail about ↵eunhhu11 days1-2/+8
| | | | 5.7 ms of 24.1 (decide, keep_filtered, apply_filters and the list side), halved 21.5 ms; join's sums into cells about 17 ns a round, a chain through the same cells, in four-byte integers with the width once a batch about 5 ns, 108 ms; neither moves BFS from about 2.7x the compiled code, and join's recurrence (about 40 ms) stays outside
* Design 024: its header says stages 1-4 of 025 are made (134-137)eunhhu12 days1-1/+1
|
* Research 137: the batch executor's stage 4 (columns read in place, ↵eunhhu12 days31-2/+333
| | | | 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
* Batch executor, stage 4 of design 025: a four-byte comparison counts its 1s ↵eunhhu12 days1-14/+28
| | | | in its own loop (TEST, a vector add in the same loop) and its value carries the count (ones), so the branch after it in every running lane needs not count them; seeds 1 2 3 5 23 (default and PURE_SELECT=all), the fixed sources and the unit tests pass
* Design 025: stage 4's knapsack bar by arithmetic (8.6 ms: two 4 KB copies ↵eunhhu12 days1-2/+5
| | | | and the branch's counting pass a batch, about 0.35 us), and the general way's floor at 1024 lanes (about 8.3 ms, ADD and GT apart) against the compiled code's 7.9
* Batch executor, stage 4 of design 025: a column read at affine rows in ↵eunhhu12 days2-4/+86
| | | | memory's order in four or eight bytes is a view of the column itself (cells_at), no copy, read only while the pass runs; what outlives the pass (a local, a set's rows and value, an append's cells, a sum's rows and e, a filter's key, a read's rows) copies it (own); knapsack 4.0% fewer instructions, 6.6% fewer cycles; VIEW_SOURCE in check.py (a local holding a field the batch sets, a set from the same column in the order that overwrites what it reads, a set widening the column under a view), which differs and trips ASan's memcpy overlap when the copies are left out; seeds 1 2 3 5 23 (default and PURE_SELECT=all), the fixed sources (also sanitized) and the unit tests pass
* Research 136: the batch executor's stage 3 (four-byte MUL, reductions with ↵eunhhu12 days31-2/+272
| | | | 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)
* Batch executor: a list's cells once a batch (cells_of, the first four lists ↵eunhhu12 days1-11/+27
| | | | its pass reads): no list changes while the pass runs (sets, appends and filters wait for its end, which reads its own); find and item_get read them there; matmul 2.3% fewer instructions (two finds a nested round), knapsack and BFS 0.4%; seeds 1 2 3 5 23 (default and PURE_SELECT=all), the fixed sources and the unit tests pass
* check.py: REDUCE_SOURCE, reductions that start with no lanes (a count, ↵eunhhu12 days1-0/+68
| | | | uniform max and min, a fraction, a sum past 2^53, a count in a nested loop, the same e then a masked or a lane's own and the other way), against the rounds one by one and the compiled code; it makes lanes from the one number 56 times and folds the one number 77 times
* 041 runs of b12 = d371271 (four-byte MUL) and b13 = 38f54ac (reductions with ↵eunhhu12 days2-0/+120
| | | | 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
* Batch executor, stage 3 of design 025: a reduction starts with no lanes: ↵eunhhu12 days1-8/+57
| | | | while every step adds (or takes the least or most of) the same e in every lane, every lane's partial is one number and its count one count, made as each lane would make them; the first step that differs makes the lanes from them; fold takes n times the one number (whole numbers below 2^53, as the lanes' sums) or folds it in the rounds' order; sum0 6.09 to 1.01 ms; seeds 1 2 3 5 23 (default and PURE_SELECT=all), the fixed sources and the unit tests pass
* Design 025: stage 3's matmul bar against what the four-byte MUL gave (26.57 ↵eunhhu12 days1-2/+3
| | | | ms against 21): the arithmetic left out the nested rounds' interpretation (about 15 ms) and the matrices' making (4-5 ms)
* Batch executor: select and deselect named select_arm and deselect_arm ↵eunhhu12 days1-6/+6
| | | | (POSIX's select in a build without -std=c17 refused the file)
* Batch executor, stage 3 of design 025: four-byte MUL (words_op): a product ↵eunhhu12 days1-1/+6
| | | | below 2^32 of whole numbers below it in four-byte lanes, past it the product's high half sends the lanes back to numbers as ADD's sum does (umull and umull2 over four lanes); matmul's products and sums stay in four bytes; seeds 1 2 3 5 23 (default and PURE_SELECT=all), the fixed sources and the unit tests pass
* Research 135: batch plans' stage 2 measured (b11 = 7959885 against b10, ↵eunhhu12 days5-2/+172
| | | | 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)
* Batch plans: stage 2's check let go (segments run as made); with it gone the ↵eunhhu12 days1-38/+5
| | | | unit tests in three modes and under ASan (executor mode too), the sanitized pure-run's fixed sources and seed 23 (both modes), make check and aup's checks in both modes pass
* Batch plans, stage 2 of design 025: segments, runs of a batch loop's ↵eunhhu12 days1-5/+232
| | | | instructions that make one uniform or affine value (constants, fields, LOADs, a walk's item, locals the block does not set, the loop's value, a nested count loop's, a local a segment set once before; a field at a uniform row; arithmetic and comparisons) and their LOCAL_STORE, planned at load and run at once in scalars by the pass's rules when the batch runs plainly, the pass's own way when a value is not as planned; the check (PURE_BATCH_CHECK) runs each dry and compares with the pass's own: seeds 1 2 3 5 23 (default and PURE_SELECT=all), the fixed sources and the unit tests pass, seed 23's programs checking 312,249 segments in 213 of 650 runs
* Design 025: stage 2 reshaped after stage 1 (134): scalar segments planned at ↵eunhhu12 days1-10/+22
| | | | load, run by the same rules with the per-instruction pass as fallback, and a list's cells once a batch; bars by arithmetic: knapsack's inner block has 10-12 of 24 instructions in segments, so 0.45 us a batch and 9.2 ms (the compiled code's 7.9 needs stage 4's passes), matmul 33 ms, sum0 1,300 instructions a batch
* Research 134: batch plans' stage 1 measured (b10 = a6fabf0 against b9, ↵eunhhu12 days7-3/+227
| | | | 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
* Batch plans: the check (PURE_BATCH_CHECK) let go, stage 1 made; with it gone ↵eunhhu12 days1-122/+0
| | | | the unit tests in three modes and under ASan (executor mode too), the sanitized pure-run's fixed sources and seed 23 (both modes), make check and aup's checks in both modes pass
* Batch plans: the recurrences read once at load too (design 025, stage 1): ↵eunhhu12 days1-98/+227
| | | | their locals, updates and steps, records and a round's actions in the plan, a number that stays planned by its source (a constant, field, LOAD or local the block does not set: the same source one number, two sources of the same value two) and filled in as a batch opens, the pass finding an update or a record by its instruction's role; the check compares updates, records and whether the batch holds them with the block read again each batch: seeds 1 2 3 5 23 (default and PURE_SELECT=all), the fixed sources and the unit tests pass
* Batch plans, stage 1 of design 025: each batch loop's block read once at ↵eunhhu12 days4-30/+150
| | | | load (pure_batch_plans, after its instructions' plans are final): the locals it sets and whether it sets items, its sums into cells, and at each instruction a role (a sum's again, add or set) and how far on a LOCAL_LOAD's x = x op e is; batch_run, pass and local_load read the plan instead of scanning the block each batch; PURE_BATCH_LANES to build other lane counts; PURE_BATCH_CHECK (a build flag, while the stage is made) reads the block again each batch and stops if the plan differs; seeds 1 2 3 5 23 (default and PURE_SELECT=all), the fixed sources and the unit tests pass with it
* Research 132 and 133 corrected: the per-batch cost was icount's three rounds ↵eunhhu12 days2-10/+14
| | | | over one round's batches, 3x too high; about 2,300 instructions (0.33 us) in a small block, 0.90 us in knapsack's (38% of its time, not 20%)
* Design 025: batch programs (132's A), the block's facts once at load and ↵eunhhu12 days5-3/+271
| | | | 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
* 042 tiles: knapsack's two passes with the lanes numbered the batch ↵eunhhu12 days2-3/+32
| | | | 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)
* PURE_REUSE_KEPT a define: as an enum constant UINT32_MAX is past int, which ↵eunhhu12 days1-1/+1
| | | | clang -Wpedantic refuses
* Research 133: register tiles measured (132's deciding experiment): past the ↵eunhhu12 days4-3/+91
| | | | bar on roots (0.71x the compiled code's cycles a step), not on knapsack (4x) or BFS (2.4x), as NEON has no gather and a tile's lanes go out and in one by one; tight passes of the batch executor's own shape in the same run at 1.2x (BFS) and 0.4x (knapsack, clang): the shape is right and the 3x is implementation, so 132's A (a batch program made once at load, loops tight by type, width and stride, fewer passes) is the way; tiles kept aside for chains of arithmetic; 132, 024 and CHECKPOINT say so
* 042 tiles (research 133): a register-tile interpreter in two forms, computed ↵eunhhu12 days3-0/+794
| | | | 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