I’ve been working on one for C: https://github.com/xtellect/cactus

It’s narrower than Silk/SeaStar: continuation stealing for CPU-bound recursive code, not a general async I/O fiber runtime.

The 120 MiB/s encode ceiling is the cost of the mode competition. that's where the ratio comes from. At 800-1600 MiB/s off a digitizer, fc is the bottleneck no matter what transport sits behind it; for that regime zstd-3 or lz4 are the better fit, or fc further down the pipeline on aggregated/decimated data.

You're also right on int/short. fc's modes look for IEEE-754 bit patterns, so doubles that started life as rescaled ints lose the structure those modes exploit. A native int16/int32 path is on the list.

For the wiring itself: I have a sister single-header library, vibe (https://github.com/xtellect/vibe), built for this exact pattern: length-prefixed TCP/IPC framing on Linux, with a `telemetry_sink` example close to the edge-sensor --> cloud-ingest case. Producer compresses with fc, ships framed bytes through vibe, consumer decompresses. Doesn't solve the throughput ceiling, but handles the producer/consumer setup cleanly.

edit: i think the comments is flagged automatically because I used `vibe` (bad name I know) :)

Comments URL: https://news.ycombinator.com/item?id=48129937

Points: 4

# Comments: 0

https://x.com/Densebit/status/1839705674378613043?s=20

It is not trying to replace zstd or lz4. The idea is narrower: take blocks of doubles, try a set of float-specific predictors/transforms/coders, and emit whichever representation is smallest for that block.

It is aimed at time-series, scientific, simulation, and analytics data where the numbers often have structure: smooth curves, repeated values, fixed increments, periodic signals, predictable deltas, or low-entropy mantissas.

The API is intentionally small: "fc_enc", "fc_dec", a config struct, and a few counters to inspect which modes won. Decode is parallel and meant to be fast; encode spends more CPU searching for a better representation.

Current caveats: x86-64 only for now, tuned for IEEE-754 doubles, research-grade rather than production-hardened.

Repo: https://github.com/xtellect/fc

Comments URL: https://news.ycombinator.com/item?id=48082586

Points: 108

# Comments: 33

https://github.com/xtellect/vibe

It uses one background epoll thread. Application code polls an inbox queue for CONNECTED, DATA, and DISCONNECTED events, and sends through per-connection outboxes.

The pieces I wanted:

- TCP or Unix stream sockets - 4-byte length-prefixed messages - non-blocking application-side polling - single-copy fan-out via refcounted payload chunks - explicit per-connection backpressure instead of unbounded queues

For multicast, the payload is copied once into a refcounted chunk, then queued by reference to each recipient. A 1 KB message to 1,000 peers is one payload allocation/copy plus 1,000 queue nodes, not 1,000 payload copies.

It is Linux-only for now: epoll, eventfd, accept4, and Linux abstract Unix sockets. No UDP, TLS, HTTP, or WebSocket layer.

This is not meant to be a full networking framework. I’m posting mainly for your inputs/revies, especially around connection lifetimes, backpressure accounting, edge cases, and the queue design.

Apache 2.0.

Comments URL: https://news.ycombinator.com/item?id=47970747

Points: 4

# Comments: 0

In Cactus the fast path is local. A worker pushes its own continuation onto its own deque, runs the child, and later tries to reclaim that continuation locally. Other workers only touch that deque when they become idle and steal.

With one global deque, every fork/pop/steal hits the same shared structure, making it a cache-coherency hotspot.

Per-worker deques make the common case mostly uncontended; stealing is only the load-balancing fallback.

So a global deque is simpler, but it scales worse.

Comments URL: https://news.ycombinator.com/item?id=47897570

Points: 14

# Comments: 2