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

361–370 of 492 posts

Re: Zlib-rs is faster than C

#361

Post by maccard »

ForTheKidz wrote: post #349
maccard wrote: post #329

Earlier quoted context omitted.

Disagree - a rewrite for “maintainability” is an engineer saying they want to rewrite in their preferred language. I wouldn’t allow someone on my team to rewrite a core dependency for “maintainability”, but I absolutely would if they suggested it would be faster and safer.

> a rewrite for “maintainability” is an engineer saying they want to rewrite in their preferred language Not necessarily—sometimes languages are especially poorly suited for tasks or difficult to hire for.

We’re talking about a rust rewrite of a fairly core level library. I don’t think C is inherently unsuitable or difficult to hire for. If the library was in Fortran then maybe.

But yes you are technically correct, congratulations.

Re: Zlib-rs is faster than C

#362

Post by vikramkr »

School-Cotton wrote: post #331
gigatexal wrote: post #324

Earlier quoted context omitted.

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

No you don’t. You can use the standard linked list that is already included in the standard library. Coming up with these niche examples of things you need unsafe for in order to discredit rust’s safety guarantees is just not interesting. What fraction of programmer time is spent writing custom linked lists? Surely way less than 1%. In most of the other 99%, Rust is very helpful.

I think the point is that it's funny that the standard library has to use unsafe to implement a data structure that's like the second data structure you learn in an intro to CS class

Re: Zlib-rs is faster than C

#363

Post by chjj »

pdimitar wrote: post #358
chjj wrote: post #346

Earlier quoted context omitted.

I wouldn't go so far as to say toxic in this case, but their reaction to me having a differing opinion is certainly characteristic of rust developer pathology. Not sure why rust attracts these people. This phenomenon should probably be studied.

- Insult a group with generalization - Members of the group respond non-kindly - "Help! I am being repressed!" I mean, maybe you should try more balanced take next time. Just a thought.

I don't ever recall saying I'm being repressed. Could you point out where I said that?

If you're referring to my above post, I'm pointing out that you're having a very emotional reaction to what I'm saying. That's typically what I see from rust developers.

Re: Zlib-rs is faster than C

#364

Post by jchw »

gpderetta wrote: post #345
jchw wrote: post #231

Earlier quoted context omitted.

Well, there's a category difference between a crash as in a panic and a crash as in a CPU exception. Usually, "safe" programming limits crashes to language-level error handling, which allows you to easily reason about the nature of crashes: if the type system is sound and your program doesn't use unsafe, the only way it should crash is by panic, and panics are recoverable and leave your program in a well-defined stat…

As you point out later, a SIGBRT or a SIGBUS would both be perfectly safe and really no different than a panic. With enough infra you could convert them to panic anyway (but probably not worth the effort).

Well, that's the thing though: in terms of Rust and Go and other safe programming languages, CPU exceptions are not "safe" even though they are not inherently dangerous. The point is that the subset of the language that is safe can't generate them, period. They are not accounted for in safe code.

There are uses for this, especially since some code will run in environments where you can not simply handle it, but it's also just cleaner this way; you don't have to worry about the different behaviors between operating systems and possibly CPU architectures with regards to error recovery if you simply don't generate any.

Since there are these edge cases where it wouldn't be possible to handle faults easily (e.g. some kernel code) it needs to be considered unsafe in general.

Re: Zlib-rs is faster than C

#365

Post by ajross »

steveklabnik wrote: post #202
ajross wrote: post #199

Earlier quoted context omitted.

> In Rust, the compiler does that for you. No it doesn't? That comment is expressing a human analysis. The compiler would allow you to stuff any pointer in that you want, even ones that overlap. You're right that some side effects of the runtime can be exploited to do that analysis. But that's true of C too! (Like, "these are two separate heap blocks", or "these are owned by two separate objects", etc...). Still huma…

I think you're misunderstanding of what I'm claiming is being checked. I don't mean the unsafe block directly. I mean that &mut Ts do not alias. That is checked by the compiler. I'm saying that even in a codebase with a lot of unsafe, the checks that are still performed have value.

Sure, but C++ objects returned from operator new are likewise guaranteed not to alias. There's "value" there, but not a lot of value. And I repeat, you're overselling hard here. People who write rust like this are going to produce roughly the same amount of memory safety bugs, and pretending otherwise is frankly dangerous, IMHO.

Re: Zlib-rs is faster than C

#366

Post by Sharlin »

vikramkr wrote: post #362
School-Cotton wrote: post #331

Earlier quoted context omitted.

No you don’t. You can use the standard linked list that is already included in the standard library. Coming up with these niche examples of things you need unsafe for in order to discredit rust’s safety guarantees is just not interesting. What fraction of programmer time is spent writing custom linked lists? Surely way less than 1%. In most of the other 99%, Rust is very helpful.

I think the point is that it's funny that the standard library has to use unsafe to implement a data structure that's like the second data structure you learn in an intro to CS class

Yeah, but Rust just proves the point here that (doubly) linked lists

a) are surprisingly nontrivial to get right,

b) have almost no practical uses, and

c) are only taught because they're conceptually nice and demonstrate pointers and O(1) vs O(n) tradeoffs.

Note that safe Rust has no problems with singly-linked lists or in general any directed tree structure.

Re: Zlib-rs is faster than C

#367

Post by jchw »

thrance wrote: post #351
jchw wrote: post #231

Earlier quoted context omitted.

Well, there's a category difference between a crash as in a panic and a crash as in a CPU exception. Usually, "safe" programming limits crashes to language-level error handling, which allows you to easily reason about the nature of crashes: if the type system is sound and your program doesn't use unsafe, the only way it should crash is by panic, and panics are recoverable and leave your program in a well-defined stat…

Also, AFAIK panics are not always recoverable in Rust. You can compile your project with `panic = "abort"`, in which case the program will quit immediately whenever a panic is encountered.

Sure, but that is beside the point: if you compile code like that, you're intentionally making panics unrecoverable. The nature of panics from the language perspective is not any different; you're still in a well-defined state when it happens.

It's also possible to go a step further and practice "panic-free" Rust where you write code in such a way that it never links to the panic handler. Seems pretty hard to do, but seems like it might be worth it sometimes, especially if you're in an environment where you don't have anything sensible to do on a panic.

Re: Zlib-rs is faster than C

#368

Post by Sharlin »

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…

To be fair, there's a safe portable SIMD abstraction brewing in `std::simd` but it's not stable yet. SIMD is just a terrible mess of platform differences in general and making a SIMD-using program safe means ensuring the availability of every single intrinsic used, lest the program is unsound. Of course that's not what C or C++ programs typically do, but in that world unsoundness is the norm anyway.

Re: Zlib-rs is faster than C

#369

Post by brooke2k »

chjj wrote: post #133
layer8 wrote: post #74

Earlier quoted context omitted.

If anything, this should be “zlib-rs is faster than zlib-ng”, but not “$library is faster than $programming_language”.

[flagged]

the point of saying "faster than C" isn't to make it a competition, it's to demonstrate that Rust is capable of hitting performance goals that previously one needed to use C/C++ for.

Re: Zlib-rs is faster than C

#370

Post by queuebert »

torginus wrote: post #337
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…

I wonder why writing SIMD in high-level languages hasn't been figured out yet for CPUs (it has been the norm for GPUs for since forever). Auto-vectorization universally sucks, so do OpenMP directives. There was Ispc, which was a separate C-like programming language just for SIMD, but I don't understand why can't regular compilers generated high-quality vectorized code.

Why do you say that? I would say SIMD is pretty well figured out in well-written code, e.g. small, tight loops over vectors. Unrolling and vectorizing a loop is not that hard and happens constantly on all our phones for signal processing, for example.
Post reply on HN