TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

Zlib-rs is faster than C

341 点作者 dochtman2 个月前

16 条评论

brianpane2 个月前
I contributed a number of performance patches to this release of zlib-rs. This was my first time doing perf work on a Rust project, so here are some things I learned: Even in a project that uses `unsafe` for SIMD and internal buffers, Rust still provided guardrails that made it easier to iterate on optimizations. Abstraction boundaries helped here: a common idiom in the codebase is to cast a raw buffer to a Rust slice for processing, to enable more compile-time checking of lifetimes and array bounds. The compiler pleasantly surprised me by doing optimizations I thought I’d have to do myself, such as optimizing away bounds checks for array accesses that could be proven correct at compile time. It also inlined functions aggressively, which enabled it to do common subexpression elimination across functions. Many times, I had an idea for a micro-optimization, but when I looked at the generated assembly I found the compiler had already done it. Some of the performance improvements came from better cache locality. I had to use C-style structure declarations in one place to force fields that were commonly used together to inhabit the same cache line. For the rare cases where this is needed, it was helpful that Rust enabled it. SIMD code is arch-specific and requires unsafe APIs. Hopefully this will get better in the future. Memory-safety in the language was a piece of the project’s overall solution for shipping correct code. Test coverage and auditing were two other critical pieces.
评论 #43387098 未加载
YZF2 个月前
I found out I already know Rust:<p><pre><code> unsafe { let x_tmp0 = _mm_clmulepi64_si128(xmm_crc0, crc_fold, 0x10); xmm_crc0 = _mm_clmulepi64_si128(xmm_crc0, crc_fold, 0x01); xmm_crc1 = _mm_xor_si128(xmm_crc1, x_tmp0); xmm_crc1 = _mm_xor_si128(xmm_crc1, xmm_crc0); </code></pre> Kidding aside, I thought the purpose of Rust was for safety but the keyword unsafe is sprinkled liberally throughout this library. At what point does it really stop mattering if this is C or Rust?<p>Presumably with inline assembly both languages can emit what is effectively the same machine code. Is the Rust compiler a better optimizing compiler than C compilers?
评论 #43381931 未加载
评论 #43381934 未加载
评论 #43383033 未加载
评论 #43381922 未加载
评论 #43384867 未加载
评论 #43382028 未加载
评论 #43381925 未加载
评论 #43386389 未加载
评论 #43381907 未加载
评论 #43381928 未加载
评论 #43386151 未加载
评论 #43382503 未加载
评论 #43388529 未加载
评论 #43385577 未加载
评论 #43381952 未加载
评论 #43382110 未加载
评论 #43381985 未加载
评论 #43382805 未加载
评论 #43387043 未加载
评论 #43392530 未加载
评论 #43383480 未加载
评论 #43382004 未加载
评论 #43383096 未加载
评论 #43381895 未加载
评论 #43385039 未加载
评论 #43386256 未加载
评论 #43385521 未加载
评论 #43382166 未加载
评论 #43382836 未加载
评论 #43381971 未加载
johnisgood2 个月前
&quot;faster than C&quot; almost always boils down to different designs, implementations, algorithms, etc.<p>Perhaps it is faster than already-existing implementations, sure, but not &quot;faster than C&quot;, and it is odd to make such claims.
评论 #43386202 未加载
评论 #43381820 未加载
评论 #43381959 未加载
评论 #43385171 未加载
评论 #43382267 未加载
评论 #43382108 未加载
评论 #43381813 未加载
评论 #43392542 未加载
评论 #43381810 未加载
评论 #43382124 未加载
cb3212 个月前
I think this <i>may</i> not be a very high bar. zippy in Nim claims to be about 1.5x to 2.0x faster than zlib: <a href="https:&#x2F;&#x2F;github.com&#x2F;guzba&#x2F;zippy" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;guzba&#x2F;zippy</a> I think there are also faster zlib&#x27;s around in C than the standard install one, such as <a href="https:&#x2F;&#x2F;github.com&#x2F;ebiggers&#x2F;libdeflate" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;ebiggers&#x2F;libdeflate</a> (EDIT: also mentioned elsethread <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=43381768">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=43381768</a> by mananaysiempre)<p>zlib itself seems pretty antiquated&#x2F;outdated these days, but it does remain popular, even as a basis for newer parallel-friendly formats such as <a href="https:&#x2F;&#x2F;www.htslib.org&#x2F;doc&#x2F;bgzip.html" rel="nofollow">https:&#x2F;&#x2F;www.htslib.org&#x2F;doc&#x2F;bgzip.html</a>
评论 #43382516 未加载
评论 #43382506 未加载
评论 #43382513 未加载
评论 #43382328 未加载
jrockway2 个月前
Chromium is kind of stuck with zlib because it&#x27;s the algorithm that&#x27;s in the standards, but if you&#x27;re making your own protocol, you can do even better than this by picking a better algorithm. Zstandard is faster and compresses better. LZ4 is much faster, but not quite as small.<p>Some reading: <a href="https:&#x2F;&#x2F;jolynch.github.io&#x2F;posts&#x2F;use_fast_data_algorithms&#x2F;" rel="nofollow">https:&#x2F;&#x2F;jolynch.github.io&#x2F;posts&#x2F;use_fast_data_algorithms&#x2F;</a><p>(As an aside, at my last job container pushes &#x2F; pulls were in the development critical path for a lot of workflows. It turns out that sha256 and gzip are responsible for a lot of the time spent during container startup. Fortunately, Zstandard is allowed, and blake3 digests will be allowed soon.)
评论 #43383456 未加载
评论 #43392411 未加载
评论 #43383191 未加载
评论 #43385563 未加载
IshKebab2 个月前
It&#x27;s <i>barely</i> faster. I would say it&#x27;s more accurate to say it&#x27;s as fast as C, which is still a great achievement.
评论 #43381791 未加载
评论 #43381694 未加载
评论 #43381776 未加载
1vuio0pswjnm72 个月前
Which library compiles faster.<p>Which library has fewer dependencies.<p>Is each library the same size. Which one is smaller.
评论 #43386695 未加载
评论 #43391462 未加载
评论 #43398856 未加载
miki1232112 个月前
I think performance is an underappreciated benefit of safe languages that compile to machine code.<p>If you&#x27;re writing your program in C, you&#x27;re afraid of shooting yourself in the foot and introducing security vulnerabilities, so you&#x27;ll naturally tend to avoid significant refactorings or complicated multithreading unless necessary. If you have Rust&#x27;s memory safety guarantees, Go&#x27;s channels and lightweight goroutines, or the access to a test runner from either of those languages, that&#x27;s suddenly a lot less of a problem.<p>The compiler guarantees you get won&#x27;t hurt either. Just to give a simple example, if your Rust function receives an immutable reference to a struct, it can rely on the fact that a member of that struct won&#x27;t magically be mutated by a call to some random function through spooky action at a distance. It can just keep it on the stack &#x2F; in a callee-saved register instead of fetching it from memory at every loop iteration, if that&#x27;s more optimal.<p>Then there&#x27;s the easy access to package ecosystems and extensive standard libraries. If there&#x27;s a super popular do_foo package, you can almost guarantee that it was a bottleneck for somebody at some point, so it&#x27;s probably optimized to hell and back. It&#x27;s certainly more optimized than your simple 10-line do_foo function that you would have written in C, because that&#x27;s easier than dealing with yet another third-party library and whatever build system it uses.
throwaway20372 个月前
Does this performance have anything to do with Rust itself, or is it just more optimized than the other C-language versions (more SIMD instructions &#x2F; raw assembly code)? I ask because there is a canonical use case where C++ can consistently outperform C -- sorting, because the comparison operator in C++ allows for more compiler optimization compared to the C version: qsort(). I am wondering if there is something similar here for Rust vs C.
评论 #43385064 未加载
up2isomorphism2 个月前
Rust folks love compare rust to C but C folks seldom compare C to rust.
评论 #43385649 未加载
Georgelemental2 个月前
&gt; The C code is able to use switch implicit fallthroughs to generate very efficient code. Rust does not have an equivalent of this mechanism<p>Rust very much can emulate this, with `break` + nested blocks. But not if you also add in `goto` to previous branches
CyberDildonics2 个月前
If you&#x27;re dealing with a compiled system language the language is going to make almost no difference in speed, especially if they are all being optimized by LLVM.<p>An optimized version that controls allocations, has good memory access patterns, uses SIMD and uses multi-threading can easily be 100x faster or more. Better memory access alone can speed a program up 20x or more.
quotemstr2 个月前
New native code implementation of zlib faster than old native code version. So what? Rust has a lot of recommend it, but it&#x27;s not automatically faster than C.
randomNumber72 个月前
Finally, now is the day - today - where rust is faster than C
kahlonel2 个月前
You mean the implementation is faster than the one in C. Because nothing is “faster than C”.
评论 #43382418 未加载
评论 #43382286 未加载
评论 #43382342 未加载
评论 #43382209 未加载
评论 #43382745 未加载
评论 #43383690 未加载
评论 #43392826 未加载
评论 #43384451 未加载
评论 #43383389 未加载
评论 #43381811 未加载
评论 #43381892 未加载
akagusu2 个月前
Bravo. Now Rust has its existence justified.