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

351–360 of 492 posts

Re: Zlib-rs is faster than C

#351

Post by thrance »

jchw wrote: post #231
anonymoushn wrote: post #219

Earlier quoted context omitted.

there are no loads in the above unsafe block, in practice loadu is just as fast as load, and even if you manually use the aligned load or store, you get a crash. it's silly to say that crashes are unsafe.

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.

Re: Zlib-rs is faster than C

#352

Post by tmtvl »

timeon wrote: post #108
chongli wrote: post #47

Earlier quoted context omitted.

Isn't it the case that once you use unsafe even a single time, you lose all of Rust's nice guarantees? As far as I'm aware, inside the unsafe block you can do whatever you want which means all of the nice memory-safety properties of the language go away. It's like letting a wet dog (who'd just been swimming in a nearby swamp) run loose inside your hermetically sealed cleanroom.

> unsafe even a single time, you lose all of Rust's nice guarantees Not sure why would one resulted in all . One of Rust's advantages is the clear boundary between safe/unsafe.

Is there such a boundary? How do you know a function doesn't call unsafe code without looking at every function called in it, and every function those functions call, and so on?

The usual retort to these questions is 'well, the standard library uses unsafe code, so everything would need a disclaimer that it uses unsafe code, so that's a useless remark to make', but the basic issue still remains that the only clear boundary is whether a function 'contains' unsafe code, not whether a function 'calls' unsafe code.

If Rust did not have a mechanism to use external code then it would be fine because the only sources of unsafe code would be either the application itself or the standard library so you could just grep for 'unsafe' to find the boundaries.

Re: Zlib-rs is faster than C

#353

Post by mplanchard »

chjj wrote: post #346
simonask wrote: post #313

Earlier quoted context omitted.

I mean, aren't you having such an interaction right now? Do you find this discussion toxic?

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.

I think “impulse to defend a community you’re a part of when you feel it is being unfairly maligned” is a pretty standard human response pattern.

Re: Zlib-rs is faster than C

#354

Post by brianpane »

Boereck wrote: post #340
brianpane wrote: post #326

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 slic…

Interesting! I wonder if you have used PGO in the project? Forcing fields to be located next to each other kind of feels like something that PGO could do for you.

I basically did manual PGO because I was also reducing the size of several integer fields at the same time to pack more into each cache line. I’m excited to try out the rustc+LLVM PGO for future optimizations.

Re: Zlib-rs is faster than C

#355

Post by mplanchard »

chjj wrote: post #303
hyperbrainer wrote: post #269

Earlier quoted context omitted.

It is not limited to rust zealots or whatever. I have seen this phenomenon of people criticising a certain category for doing something in the comment section on reddit/youtube, but never actually seen the people doing that thing, even browsing the most heavily downvoted comments. Some weird group mentality victimisation.

> never actually seen the people doing that thing I'm happy to share then. Here's my most recent encounter with a rustacean: https://x.com/_chjj/status/1829989494298460636 I asked if he/she/they had ever used the unsafe keyword. That was the response I got. It's usually some vile insult involving furry or transgender genitalia.

Do you not think that the thread you’re currently on here on HN has a lot of rust programmers? So your “most recent encounter” is actually this thread.

It’s trivial to find examples of people in any community who are a bit off the rails, but you shouldn’t let that define your perception of the community, especially given the fact that you’re currently in a context where your thesis doesn’t have much to support it.

Re: Zlib-rs is faster than C

#356

Post by throwaway150 »

hyperbrainer wrote: post #267
throwaway150 wrote: post #207

Earlier quoted context omitted.

> Like the hydrogen sulfide added to natural gas to allow folks to smell a gas leak. I am 100% sure that the smell they add to natural gas does not smell like rotten eggs.

you are lucky to not have smelled metacarpan (which is what is actually put in). Much much worse than H2S

I have. It's worse no doubt. But it's not the smell of rotten eggs. My comment was meant to be tongue-in-cheek to correct the mistake of saying "H2S" in the GP comment.

Re: Zlib-rs is faster than C

#357

Post by YoshiRulz »

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.

.NET (C#) is getting there with Vector.

Re: Zlib-rs is faster than C

#358

Post by pdimitar »

chjj wrote: post #346
simonask wrote: post #313

Earlier quoted context omitted.

I mean, aren't you having such an interaction right now? Do you find this discussion toxic?

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.

Re: Zlib-rs is faster than C

#359

Post by vitus »

anon-3988 wrote: post #171
layer8 wrote: post #81

Earlier quoted context omitted.

C has the restrict type qualifier to express non-aliasing, hence it shouldn’t be a fundamental impediment.

> fundamental impediment This is an interesting word. I wonder why no one has written high performance library code in assembly yet at this point?

> I wonder why no one has written high performance library code in assembly yet at this point?

What do you mean by that?

There is plenty of hand-rolled assembly in low-level libraries, whether you look at OpenBLAS (17%), GMP (36%), BoringSSL (25%), WolfSSL (14%) -- all of these numbers are based on looking at Github's language breakdown (which is measured on a per-file basis, so doesn't count inline asm or heavy use of intrinsics).

There are contexts where you want better performance guarantees than the compiler will give you. If you're dealing with cryptography, you probably want to guard against timing attacks via constant-time code. If you're dealing with math, maybe you really do want to eke out as much performance as possible, autovectorization just isn't doing what you want it to do, and your intrinsic-based code just isn't using all your registers as efficiently as you'd like.

Re: Zlib-rs is faster than C

#360

Post by datadeft »

steveklabnik wrote: post #64
datadeft wrote: post #27

Earlier quoted context omitted.

I thought that the point of Rust is to have safe {} blocks (implicit) as a default and unsafe {} when you need the absolute maximum performance available. You can audit those few lines of unsafe code very easily. With C everything is unsafe and you can just forget to call free() or call it twice and you are done.

> unsafe {} when you need the absolute maximum performance available. Unsafe code is not inherently faster than safe code, though sometimes, it is. Unsafe is for when you want to do something that is legal, but the compiler cannot understand that it is legal.

True, however I only saw this happens to achieve max perf. I have very limited experience so this is confirmation bias from my end.
Post reply on HN