有个程序员在GitHub扔了个叫fc的小工具，专治IEEE-754双精度浮点数的"肥胖症"。1.56版本，Apache协议，没融资没发布会，就一段冷冰冰的C代码——结果在17组测试数据里，有10组把zstd、fpzip、gorilla全按在地上摩擦。

核心玩法很暴力：把数据切成自适应大小的块，让几十种专用编解码器同台竞技，谁压得更小就选谁。压缩多线程跑POSIX线程，热点路径全用手撕的x86-64向量化（AVX2+SSE4.2+BMI+LZCNT）。解压更是自动多线程，聚合速度飙到1.28 GB/s，比压缩快10倍，比fpzip快10倍，比gorilla快30%。

打开网易新闻 查看精彩图片

什么场景能压出39,756倍？常量数据。抛物线、整数乘1000、分段函数、股票序列——这些"有规律"的浮点数，fc能把zstd-9的11,619倍再砍下去三分之二。低频正弦、音频混音、阻尼震荡这些周期信号，也能把fpzip和gorilla甩开1.3到2.7倍。

打开网易新闻 查看精彩图片

但别神化它。小数金额、16位字典、四级量化这种"字节友好型"数据，zstd能压到10,268倍，fc只有4,660倍——通用LZ能抓住的结构，fc没建模。随机游走、气候数据、地理坐标、带噪传感器这些"自然浮点"，fpzip略胜一筹。纯随机数据？大家都是1.000，fc只是不浪费头字节而已。

压缩速度是硬伤。聚合约120 MB/s，模式竞争换压缩率，CPU代价得认。如果编码是瓶颈，lz4的2.2 GB/s或zstd-3的530 MB/s才是答案。硬门槛也摆在这：只认无损，只认8字节对齐的IEEE-754双精度，只认带AVX2的x86-64。ARM？别的位宽？作者没空。

打开网易新闻 查看精彩图片

一句话：写一次读多次的时序数据库，fc可能是目前最优解。其他场景，该用zstd还用zstd。