01 / Classification
NAICS Code Finder
Describe a business activity in plain language and get the closest six-digit 2022 NAICS industries, ranked by semantic similarity. It also handles batch lookups for less playful work.
Find a NAICS codeProof from open source
Software built close to the machine.
I am a Python and C++ systems programmer focused on finance, high-performance computing, compact data structures, and the parts of software where latency and memory become product constraints.
You know the camping joke where one person puts on running shoes and the other says, "You can't outrun the bear"? That's right. I make the shoes. Now run.
| Project | What it is |
|---|---|
| Goblin Core |
Goblin Core is my C++23 answer to two Redis-shaped problems: hot
state that consumes too much RAM, and latency-sensitive state
that spends too long crossing the kernel. It keeps familiar
operations for strings, sets, sorted sets, hashes, lists, sparse
arrays, and Pub/Sub, then replaces the general-purpose internals
with compact layouts and purpose-built transports. Applications
can keep RESP or opt into typed SBE across TLS-capable TCP,
native XLIO Ultra, Unix-domain sockets, shared-memory rings, and
polled RDMA.
Version 0.10 makes that engine operational beyond a single process: broker-acknowledged Kafka writes use bounded backpressure, firehose replication streams live canonical writes, and a native whole-database stream bootstraps replicas without translating the data through Redis commands. Snapshots, Kafka replay, and the live stream form the recovery path; Kafka still owns durable history. The published results span memory, local latency, and real networking. A one-million-member set uses 28.65 RSS bytes/member, 36.2% less than the leanest compared server. A synchronous shared-memory HSET or ZADD round trip takes about 220 ns; across six operations, it is 33-40x faster at the median than the fastest RESP Unix-domain-socket result. Native XLIO Ultra runs seven Redis commands at 4.98-8.37 microseconds median over 100 GbE. On 40 Gb/s InfiniBand between two old R820s, its polled one-sided RDMA ring completes an SBE PING at 2.495 microseconds p50 and RESP2 at 2.673 microseconds, only about 0.6 microseconds beyond the same server's two-hop QPI path. And after 14.3 billion real Lichess updates, Goblin Core matched Redis exactly while using less memory than Redis 7.2.4, Redis 8.8, Valkey 9.1, and Dragonfly. |
| Goblin Store |
A C++23 NUMA-aware large-object cache, HTTP server, and streaming
caching proxy for values from 256 KiB into the multi-MiB range.
It speaks memcache over TCP or native InfiniBand/RoCE and serves
HTTP/HTTPS with ranges, ETags, and origin-mirror operation. The
latency-sensitive head stays in RAM while the warm middle streams
from SSD and the cold tail is read ahead from optional HDD.
HugeTLB-backed heads, fixed pools, backpressure, O_DIRECT, Linux
io_uring, and core-local data paths keep memory bounded as
objects grow.
On the published network benchmark, Goblin Store matched memcached's large-object latency while using 7.4x less RAM. With a disk-sized working set on the same HDD, its three-tier configuration delivered 118 QPS versus 70 for memcached extstore, a 68% throughput lead, while retaining the full working set that extstore shed under write load. A separate native InfiniBand path reaches 38.2 Gbit/s. This is intentionally a large-object engine; memcached remains the better tool for tiny values. |
| stride-align | stride-align is a SIMD-accelerated Python/C++ library
for fuzzy string matching, sequence alignment, edit
distance, phonetic encoding, and time-series distance. It
implements Smith-Waterman and Needleman-Wunsch with fast
native kernels, Unicode/CJK support, all-pairs scoring,
top-k search, Dynamic Time Warping, and runtime CPU
dispatch across x86, ARM, LoongArch, and POWER.
It also includes compatibility shims for rapidfuzz and parasail-python, so existing code can move onto STRIDE-ALIGN’s native SIMD backend by changing one import. Benchmarks show it beating Parasail on AVX-512 and AVX2, with especially strong LoongArch LASX results, including workloads where it is over 22× faster. |
| massive-speedup | High-performance Massive.com flatfile parser, data store, and market microstructure simulator. Flatfile iteration is 5x faster than using Python's gzip and csv modules. Its tick-forward iterative design with an integrated latency-aware market simulator, coupled with rtta's tick-driven indicators makes backtesting resistant to common causes of "crystal balling" that can happen in traditional Pandas and bulk-data strategy development. |
| rtta | Looking for a good technical analysis library? Tired
of having to rewrite your Pandas models to work with
real-time tick data? What if you could work with a
technical-analysis library built from the ground up to
be tick-forward?
rtta is a low-latency incremental technical-analysis toolkit. It includes a rich collection of technical-analysis functions, including traditional indicators, Kalman-filter-based indicators, and several experimental indicators based on recent research. The library supports both batch processing and efficient real-time tick-based interfaces. Coupled with massive-speedup, it encourages tick-by-tick strategy design that resists "crystal balling" and makes future live deployment of test code easier. |
| negcycle |
negcycle finds profitable FX cycles, identifying the
most profitable in 1.8μs on an 11th-gen Intel i7.
negcycle is a carefully constructed, SIMD-optimized Python library for finding profitable execution chains in currency markets. Internally, negcycle implements dense Bellman-Ford search with SIMD optimization for Intel, Arm, and Loongson. Gone are the days of triple-nested Python loops and watching old results crawl onto the screen. Plug these shoes into your Massive.com WebSocket feed and be the first to seize new opportunities. |
| fast-kalman | An insanely fast and friendly Kalman filter
implementation for C++ and Python that is 125×
faster than OpenCV's Kalman filter on a typical
single-price tracker, with peaks of 235× on
harder filters.
This filter library supports a wide variety of Kalman filter types, non-uniform update times, custom certainty values per update, and, coolest of all: Ever put together a Kalman filter and had no idea what to do about the tuning parameters? Give fast-kalman a chunk of your data and it will generate tuning parameters for you. My C++ Kalman filters run 7×–235× faster than OpenCV's across the full range of filter types. At the Python level, my Kalman filters are 5× faster, and it's only "that low" because the Python bindings themselves are the bulk of the cost. That's right: times, not percent. My goblins can run. |
| DragonArray |
DragonArray is my Loongson optimization lab for installable
LoongArch64 wheels, source patches, benchmarks, and low-level
utilities. Its first release completed the missing pieces needed to
enable NumPy's 256-bit LASX SIMD path, achieving a
geometric-mean speedup of 3.3x over the LSX-targeted
code in NumPy 2.5.0.dev0 on a 3A6000 processor.
This work builds on NumPy's existing LoongArch SIMD infrastructure. My part included implementing LASX detection, wiring the 8 remaining LASX primitives needed to enable the 256-bit path, and creating vectorized implementations of transcendental functions. I'm particularly proud of my float16 version of tanh: its LASX throughput is 26x higher than the scalar implementation it replaced. DragonArray now also ships a BLAKE3 LoongArch SIMD port from its public loongarch-simd source branch, with TensorFlow wheels as
the next track.
|
| bsort | This project started with beer. I was sharing beers
after work with friends,
reading sortbenchmark.org,
and thought "I bet I can beat that with my company
laptop." Instead of competing, we only
published the
drunk-coded version and built a startup around
it. bsort is a fast fixed-record sort library for large data files. It's now both a C++ executable and a Python library. It has good locality-of-reference properties, plays nicely with LRU memory eviction, can sort files orders of magnitude larger than RAM without turning your hard drive into a thrashfest, and is the basis of my 2026 sort benchmark submission. |
| mosh patches |
Anyone who has tried to run SSH over Wi-Fi or a cell
phone with one bar knows how awesome mosh is. Except mosh
doesn't support a lot of things modern developers need,
like ssh-agent forwarding, sockets, SOCKS, X11, and scp -
until now. My mosh patches make it possible to work
from that cruise ship or mountaintop. My mosh work adds the missing features to the mobile shell that SSH users take for granted: SSH-like stream forwarding for local, remote, dynamic SOCKS, and agent use cases through familiar flags such as -L, -R, -D, and -A. The patch series carries the protocol, frontend, and state-sync changes needed to move those streams through mosh's roaming terminal session. It also includes a highly efficient, forward-error-corrected bulk file copy, giving mosh users scp-like capabilities on poor links. Finally, it has a trained-compressor mode for highly constrained links such as satellite phones. Testing against an Iridium Go at 2.8 kbps in late May 2026. |
| CPython SIMD experiment | This CPython 3.14 technology demo speeds up Python. Some string operations improve by double-digit factors - again, times, not percent.
It adds a runtime SIMD dispatch layer and applies it across everyday interpreter hot paths rather than treating SIMD as a narrow extension module trick. The branch accelerates base64 and hex codecs, UTF-8 and ASCII scanning, bytes translation and case folding, JSON loads and dumps string handling, csv.reader field scanning, urllib parsing helpers, and a new C accelerator for html.escape. It also includes an experimental Swiss-table-backed set implementation as a benchmark vehicle for probing whether SIMD metadata scans can compete with CPython's existing set design. The useful lesson is pragmatic: the largest wins come from bulk text and codec work where per-call overhead is amortized, while short-string cases are mostly limited by object setup and call overhead. The branch includes benchmark and optimization notes alongside the code so the results are reproducible instead of being a one-off microbenchmark story. |
| NumPy LASX experiment |
Loongson's processors are real hardware in roughly the
same weight class as AMD and Intel. They have two SIMD
modes: 128-bit-wide LSX for embedded devices and 256-bit-wide
LASX for real computers. NumPy supports LSX but not LASX, leaving a lot of performance on the table in the same way implementing only SSE4.2 does now that the world is on AVX2 and AVX-512. I picked up a 3A6000 when I was last in China and have been busy with a proof-of-concept port to LASX. I'm seeing 80% gains over LSX and a lot more for places that have no vectorization at all. Keep an eye on this project - it is going to become real NumPy patches. |
| goblin-cannon | New York is 29 ms from London on the EXA Express.
That's 29 ms from POP to POP; they advertise a 60 ms
round-trip. Maybe more to your actual trading server. The
speed of light on a great-circle route is 19 ms. That's
11 ms faster, if you had the magic radio to read from the
exchange, sort out competing messages, encrypt, apply CRC and
error coding, build a waveform, send the data, unpack,
run error correction, check CRCs, and decrypt, all
while leaving enough time for a trader to actually do
something with the advance knowledge.
goblin-cannon is a 2.5 ms end-to-end SDR radio implementation built with AES, Viterbi decoding, CRC frame checking, QCI encoding, and oversample-based decoding with AVX2 and AVX-512 support. This isn't just a radio - it supports the business side as well - both market and custom messages with transmission-slot bidding, shadow bids for market data based on volatility, budgets, and accounting, lost-message credits - basically everything you need to build a HFT-adjacent cross-Atlantic market data business except for the spectrum license and the actual hardware. Cross-Atlantic testing is anticipated for fall 2026, gated on an experimental license. |