Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Zlib-rs is faster than C

trifectatech.org

Post reply on HN
Print view View original

441–450 of 492 posts

Re: Zlib-rs is faster than C

#441

Post by cesarb »

jrockway wrote: post #55

Chromium is kind of stuck with zlib because it's the algorithm that's in the standards, but if you'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. Some reading: https://jolynch.github.io/posts/use_fast_data_algorithms/ (As an aside, at my last job container pushes / pulls were in the dev…

> Zstandard is faster and compresses better.

However, keep in mind that zstd also needs much more memory. IIRC, it uses by default 8 megabytes as its buffer size (and can be configured to use many times more than that), while zlib uses at most 32 kilobytes, allowing it to run even on small 16-bit processors.

Re: Zlib-rs is faster than C

#442

Post by jason-johnson »

johnisgood wrote: post #12
qweqwe14 wrote: post #11

Earlier quoted context omitted.

The fact that it's faster than the C implementation that surely had more time and effort put into it doesn't look good for C here.

It says absolutely nothing about the programming language though.

How can it not? Experts in C taking longer to make a slower and less safe implementation than experts in Rust? It's not conclusive but it most certainly says something about the language.

Re: Zlib-rs is faster than C

#443

Post by keybored »

YZF wrote: post #18

I found out I already know Rust: 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); 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 mat…

> 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?

Kidding aside the 150-comment Unsafe Rust subthread was inevitable.

Re: Zlib-rs is faster than C

#444

Post by jason-johnson »

johnisgood wrote: post #4

"faster than C" almost always boils down to different designs, implementations, algorithms, etc. Perhaps it is faster than already-existing implementations, sure, but not "faster than C", and it is odd to make such claims.

This has generally been the case, but a system language like Rust has access to optimisations that C simply won't have due to the compiler having so much more information (e.g. being able to skip run time array size checks because the compiler was able to prove out of bounds access cannot occur).

Re: Zlib-rs is faster than C

#445

Post by steveklabnik »

no_wizard wrote: post #440
steveklabnik wrote: post #400

Earlier quoted context omitted.

There is no possible way for something to be written in 100% memory safe code, no matter what the language, if you include "no unsafe code anywhere in the call stack." Interacting with the hardware is not memory safe. Any useful program must on some level involve unsafety. This is true for every programming language.

I wasn't asking for 100%, I am asking for a reasonable proof of assertions.

You may like my next blog post.

Re: Zlib-rs is faster than C

#446

Post by all2well »

gigatexal wrote: post #324
timschmidt wrote: post #36

Earlier quoted context omitted.

Unsafe is a very distinct code smell. Like the hydrogen sulfide added to natural gas to allow folks to smell a gas leak. If you smell it when you're not working on the gas lines, that's a signal.

Someone mentioned to me that for something as simple as a Linked list you have to use unsafe in rust Update its how the std lib does it: https://doc.rust-lang.org/src/alloc/collections/linked_list....

Doesn’t Arc and Weak work for doubly linked lists? Rust docs recommend Weak as a way to break pointer cycles: https://doc.rust-lang.org/std/sync/struct.Arc.html#breaking-...

Re: Zlib-rs is faster than C

#447

Post by steveklabnik »

kazinator wrote: post #435
Aurornis wrote: post #29

Earlier quoted context omitted.

Using unsafe blocks in Rust is confusing when you first see it. The idea is that you have to opt-out of compiler safety guarantees for specific sections of code, but they’re clearly marked by the unsafe block. In good practice it’s used judiciously in a codebase where it makes sense. Those sections receive extra attention and analysis by the developers. Of course you can find sloppy codebases where people reach for u…

> clearly marked by the unsafe block. Rust has macros; are macros prohibited from generating unsafe blocks, so that macro invocations don't have to be suspected of harboring unsafe code?

No. Just like function bodies can contain unsafe blocks.

Re: Zlib-rs is faster than C

#448

Post by burntsushi »

sunshowers wrote: post #427
DannyBee wrote: post #350

Earlier quoted context omitted.

Hard disagree - if you violate the invariants in Rust unsafe code, you can cause global problems with local code. You can cause use-after-free, and other borrow checker violations, with incorrect unsafe code. Nothing will flag it, you will have no idea which unsafe code block is causing the isue, debugging will be hard. I have no idea what your definition of encapsulation is, but mine is not this. It's really only en…

> It's really only encapsulated in the sense that if you have a finite and small set of unsafe blocks, you can audit them easier and be pretty sure that your memory safety bugs are in there. This reality really doesn't exist much anymore because of how much unsafe is often ued, and since you you have to audit all of them, whether they come from a library or not, it's not as useful to claim encapsulation as one thinks…

> and we've added support for Miri to make its runs many times faster

Whoa. This might be the kick in the ass I needed to give cargo-nextest a whirl in my projects. Miri being slow is the single biggest annoyance I have with it!

Re: Zlib-rs is faster than C

#449

Post by no_wizard »

steveklabnik wrote: post #445
no_wizard wrote: post #440

Earlier quoted context omitted.

I wasn't asking for 100%, I am asking for a reasonable proof of assertions.

You may like my next blog post.

I think whenever someone takes the time to walk their audience through the nuances of this question its a big win.

No different than how I asked of the Go community how it could produce binaries on any platform for all major platforms it supports (IE, you don't have to compile your Go code on Linux for it to work on Linux, only have to set a flag, with the exception If I recall correctly of CGO dependencies but thats a wild horse anyway)

Re: Zlib-rs is faster than C

#450

Post by randomNumber7 »

bangaladore wrote: post #415
selfmodruntime wrote: post #377

Earlier quoted context omitted.

> With unsafe you get exactly the same kind of semantics as C, if you don't uphold the invariant the unsafe functions expect, you end up with UB exactly like in C. This is not exactly true. Even in production code, unsafe preconditions check if you violate these rules. Here: https://doc.rust-lang.org/core/macro.assert_unsafe_precondit... And here: https://google.github.io/comprehensive-rust/unsafe-rust/unsa...

Quoted from your link > Safe Rust: memory safe, no undefined behavior possible. Unsafe Rust: can trigger undefined behavior if preconditions are violated. So Unsafe Rust from a UB perspective is no different than C/C++. If preconditions are violated, UB can occur, affecting anywhere in the program. Its unclear how the compiler could check anything about preconditions in a block explicitly used to say that the develop…

The rust compiler was written by chuck norris.
Post reply on HN