rts gbps perf drop
  • C 44.2%
  • Haskell 39.3%
  • Shell 16.5%
Find a file
Repository files (latest commit first)
Filename Latest commit message Latest commit date
2026-03-30 10:52:06 +02:00
app Add standalone GHC RTS-way TCP repro 2026-03-30 10:52:06 +02:00
cbits Add standalone GHC RTS-way TCP repro 2026-03-30 10:52:06 +02:00
docs Add standalone GHC RTS-way TCP repro 2026-03-30 10:52:06 +02:00
scripts Add standalone GHC RTS-way TCP repro 2026-03-30 10:52:06 +02:00
cabal.project Add standalone GHC RTS-way TCP repro 2026-03-30 10:52:06 +02:00
README.md Add standalone GHC RTS-way TCP repro 2026-03-30 10:52:06 +02:00
rts-way-tcp.cabal Add standalone GHC RTS-way TCP repro 2026-03-30 10:52:06 +02:00

rts-way-tcp Repro

Self-contained repro for a large throughput gap between:

  • non-profiled threaded RTS: rts_thr
  • profiled threaded RTS: rts_thr_p

on the same Haskell TCP sink server code.

What It Tests

  • Haskell server: accept loop + per-connection recvBuf drain loop.
  • C client: multi-thread sender to avoid Haskell-client effects.
  • Same workload for both binaries:
    • connections=12
    • buf=262144
    • seconds=2

Run

cd repro/rts-way-tcp
bash scripts/repro.sh

Expected output shape:

thr rts_way=rts_thr
TCP_SINK_CLIENT ... gbps=<lower>
thrp rts_way=rts_thr_p
TCP_SINK_CLIENT ... gbps=<much higher>

Current Observed Behavior (host-dependent)

  • rts_thr: about ~116-121 Gbit/s
  • rts_thr_p: about ~222-226 Gbit/s

Why This Matters

This is a large performance split with identical app logic and identical external load generator. It points to RTS-way-specific behavior (or codegen/runtime interaction), not business logic.

Notes

  • Server logs are written to /tmp/rts_way_thr.log and /tmp/rts_way_thrp.log.
  • Build logs:
    • /tmp/rts_way_build_thr.log
    • /tmp/rts_way_build_thrp.log