Most active commenters
  • no_wizard(5)
  • TheDong(3)
  • johnisgood(3)

←back to thread

Zlib-rs is faster than C

(trifectatech.org)
341 points dochtman | 15 comments | 16 Mar 25 19:35 UTC | HN request time: 2.014s | source | bottom
Show context
YZF ◴[16 Mar 25 20:12 UTC] No.43381858[source]▶
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 mattering if this is C or Rust?

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?

replies(30): >>43381895 #>>43381907 #>>43381922 #>>43381925 #>>43381928 #>>43381931 #>>43381934 #>>43381952 #>>43381971 #>>43381985 #>>43382004 #>>43382028 #>>43382110 #>>43382166 #>>43382503 #>>43382805 #>>43382836 #>>43383033 #>>43383096 #>>43383480 #>>43384867 #>>43385039 #>>43385521 #>>43385577 #>>43386151 #>>43386256 #>>43386389 #>>43387043 #>>43388529 #>>43392530 #
koito17 ◴[16 Mar 25 20:33 UTC] No.43382028[source]▶
The purpose of `unsafe` is for the compiler to assume a block of code is correct. SIMD intrinsics are marked as unsafe because they take raw pointers as arguments.

In safe Rust (the default), memory access is validated by the borrow checker and type system. Rust’s goal of soundness means safe Rust should never cause out-of-bounds access, use-after-free, etc; if it does, then there's a bug in the Rust compiler.

replies(2): >>43382647 #>>43382680 #
no_wizard ◴[16 Mar 25 21:41 UTC] No.43382647[source]▶
How do we know if Rust is safe unless Rust is written purely in safe Rust?

Is that not true? Even validators have bugs or miss things no?

replies(2): >>43382727 #>>43384836 #
TheDong ◴[17 Mar 25 03:11 UTC] No.43384836[source]▶
And while we're in the hypothetical extreme world somewhat separated from reality, a series of solar flares could flip a memory bit and all the error-correction bits in my ECC ram at once to change a pointer in memory, causing my safe rust to do an out of bounds write.

Until we design perfectly correct computer hardware, processors, and a sun which doesn't produce solar radiation, we can't rely on totally uniform correct execution of our code, so we should give up.

The reality is that while we can't prove the rust compiler is safe, we can keep using it and diligently fix any counter-examples, and that's good enough in practice. Over in the real world, where we can acknowledge "yes, it is impossible to prove the absence of all bugs" and simultaneously say "but things sure seem to be working great, so we can get on with life and fix em if/when they pop up".

replies(1): >>43385259 #
1. no_wizard ◴[17 Mar 25 04:39 UTC] No.43385259[source]▶
I’m simply positing how do we know the safety guarantees hold, not a hypothetical extreme. Not really sure where the extreme comes in.

If you take Rust at face value, than this to me seems like an obvious question to ask

replies(1): >>43386052 #
2. TheDong ◴[17 Mar 25 07:40 UTC] No.43386052[source]▶
Sorry, it's just that I have an allergic reaction to what sounds like people trying to make debate-bro arguments.

Like, when I say "use signal, it's secure", someone could respond "Ahh, but technically you can't prove the absence of bugs, signal could have serious bugs, so it's not secure, you fool", but like everyone reading this already knew "it's secure" means "based on current evidence and my opinion it seems likely to be more secure than alternatives", and it got shortened. Interpreting things as absolutes that are true or false is pointless debate-bro junk which lets you create strawmen out of normal human speech.

When someone says "1+1 = 2", and a debate-bro responds "ahh but in base-2 it's 10 you fool", it's just useless internet noise. Sure, it's correct, but it's irrelevant, everyone already knows it, the original comment didn't mean otherwise.

Responding to "safe Rust should never cause out-of-bounds access, use-after-free" with "ahh but we can't prove the compiler is safe, so rust isn't safe is it??" is a similarly sorta response. Everyone already knows it. It's self-evident. It adds nothing. It sounds like debate-bro "I want to argue with you so I'm saying something that's true, but we both already know and doesn't actually matter".

I think that allergic response came out, apologies if it was misguided in this case and you're not being a debate-bro.

replies(2): >>43386124 #>>43389238 #
3. johnisgood ◴[17 Mar 25 07:57 UTC] No.43386124[source]▶
But you have to admit Rust zealots are misguided, too, who does not happen to know or realize the obviousness of what you just said with regarding to Rust.
replies(1): >>43386207 #
4. TheDong ◴[17 Mar 25 08:15 UTC] No.43386207{3}[source]▶
Such a rust zealot is a strawman, though please don't let me stop you from enjoying burning such a strawman.
replies(1): >>43386655 #
5. johnisgood ◴[17 Mar 25 09:43 UTC] No.43386655{4}[source]▶
How is it a strawman? Many people have misconceptions with regarding to Rust, while not even knowing about the existence of Ada/SPARK to begin with. They blindly spout "Rust is saFeEe!44!". If you are not a zealot, then it is not applied to you.
replies(1): >>43386969 #
6. umanwizard ◴[17 Mar 25 10:39 UTC] No.43386969{5}[source]▶
I see about 1000x more anti-rust-zealot strawman arguments than rust zealots on this site. Can you give some examples of the misguided rust zealotry you’re talking about?
replies(2): >>43387069 #>>43387110 #
7. ◴[17 Mar 25 10:52 UTC] No.43387069{6}[source]▶
8. johnisgood ◴[17 Mar 25 10:57 UTC] No.43387110{6}[source]▶
I deleted my initial response, but FWIW you do not have to go far, take a look at the title of this submission.
9. no_wizard ◴[17 Mar 25 14:56 UTC] No.43389238[source]▶
I don't think we can go beyond the 'human limitations' if you will, of any software.

Bugs happen, they're bound to. Its more, what is enforcing the Rust language guarantees and how do we know its enforcing them with reasonably high accuracy one can ascertain?

I feel that it can only happen as Rust itself becomes (or perhaps it meaningfully already is) written in pure 100% safe Rust itself. At which point, I believe the matter will be largely settled.

Until then, I don't think its unreasonable for someone to ask about how it verifies its assertions is all.

replies(2): >>43389787 #>>43396137 #
10. steveklabnik ◴[17 Mar 25 15:48 UTC] No.43389787{3}[source]▶
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.
replies(1): >>43392377 #
11. no_wizard ◴[17 Mar 25 20:22 UTC] No.43392377{4}[source]▶
I wasn't asking for 100%, I am asking for a reasonable proof of assertions.
replies(1): >>43392546 #
12. steveklabnik ◴[17 Mar 25 20:43 UTC] No.43392546{5}[source]▶
You may like my next blog post.
replies(1): >>43392710 #
13. no_wizard ◴[17 Mar 25 21:02 UTC] No.43392710{6}[source]▶
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)

replies(1): >>43401875 #
14. umanwizard ◴[18 Mar 25 05:51 UTC] No.43396137{3}[source]▶
Yes, the rust compiler, like all complex software, has bugs. And yes, those bugs could result in memory unsafety, undefined behavior, etc.

The same is true of every programming language. There might be bugs in clang or gcc so how can we prove that they actually follow the C++ spec? We can’t. rustc is no different, but nobody ever claimed it was, so why hold it to a higher standard than clang?

15. rc00 ◴[18 Mar 25 17:08 UTC] No.43401875{7}[source]▶
Cross-compilation with Cgo can be resolved using something like Zig as the compilation toolchain:

https://zig.news/kristoff/building-sqlite-with-cgo-for-every...