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

471–480 of 492 posts

Re: Zlib-rs is faster than C

#471

Post by School-Cotton »

tmtvl wrote: post #352
timeon wrote: post #108

Earlier quoted context omitted.

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

The point of rust isn’t to formally prove that there are no bugs. It’s just to make writing certain classes of bugs harder. That’s what people are missing when they point out that yes, it’s possible to circumvent safety mechanisms. It’s a strawman: bulletproof, guaranteed security simply isn’t a design goal of rust.

Re: Zlib-rs is faster than C

#472

Post by School-Cotton »

no_wizard wrote: post #391
TheDong wrote: post #279

Earlier quoted context omitted.

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

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

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?

Re: Zlib-rs is faster than C

#473

Post by [deleted] »

ajross wrote: post #348
solidsnack9000 wrote: post #246

Earlier quoted context omitted.

I'm not sure why people say this about certain languages (it is sometimes said about Haskell, as well). The code has a C style to it, but that doesn't mean it wasn't actually written in Rust -- Rust deliberately has features to support writing this kind of code, in concert with safer, stricter code. Imagine if we applied this standard to C code. "Zlib-NG is basically written in assembler, not C..." https://github.com…

> Imagine if we applied this standard to C code. "Zlib-NG is basically written in assembler, not C..." We absolutely should, if someone claimed/implied-via-headline that naive C was natively as fast as hand-tuned assembly! This kind of context matters. FWIW: I'm not talking about the assembly in zlib-rs, I was specifically limiting my analysis to the rust layers doing memory organization, etc... Discussing Rust is ju…

[deleted]

Re: Zlib-rs is faster than C

#474

Post by hitekker »

ajross wrote: post #348
solidsnack9000 wrote: post #246

Earlier quoted context omitted.

I'm not sure why people say this about certain languages (it is sometimes said about Haskell, as well). The code has a C style to it, but that doesn't mean it wasn't actually written in Rust -- Rust deliberately has features to support writing this kind of code, in concert with safer, stricter code. Imagine if we applied this standard to C code. "Zlib-NG is basically written in assembler, not C..." https://github.com…

> Imagine if we applied this standard to C code. "Zlib-NG is basically written in assembler, not C..." We absolutely should, if someone claimed/implied-via-headline that naive C was natively as fast as hand-tuned assembly! This kind of context matters. FWIW: I'm not talking about the assembly in zlib-rs, I was specifically limiting my analysis to the rust layers doing memory organization, etc... Discussing Rust is ju…

FWIW, I think your opinion is accurate, particularly regarding digressions. It's a common debate tactic for hyping a language under the thin veneer of technical discussion.

Re: Zlib-rs is faster than C

#475

Post by MaxBarraclough »

MaxBarraclough wrote: post #457
oneshtein wrote: post #395

Earlier quoted context omitted.

An error value is valid output in both cases.

The code is unarguably wrong. average(INT_MAX,INTMAX) should return INT_MAX , but it will get that wrong and return -1. average(0,-2) should not return a special error-code value, but this code will do just that, making -1 an ambiguous output value. Even its comment is wrong. We can see from the signature of the function that there can be no value that indicates an error, as every possible value of int may be a legit…

Too late for me to edit: as josefx pointed out, it also fails to properly address the undefined behavior. The sums INT_MAX + INT_MAX and INT_MIN + INT_MIN may still overflow despite being done using the long type.

That won't occur on an 'LP64' platform, [0] but we should aim for proper portability and conformance to the C language standard.

[0] https://en.wikipedia.org/wiki/64-bit_computing#64-bit_data_m...

Re: Zlib-rs is faster than C

#476

Post by johnisgood »

atoav wrote: post #295
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.

The thing is, Rust allows you to casually code things that are fast. A few years back I took part in an "all programming languages allowed" competition on a popular hacker blog in my country. The topic was who writes the fastest tokenizer (a thing splitting sentences into words). I took 15 minutes to write one in Rust (a language I had just learned by that point) using a "that should work" approach and became second…

Well, yeah, same with books on Erlang, Common Lisp, even Odin. They teach you how to become a "better" (debatable, perhaps) programmer.

Re: Zlib-rs is faster than C

#477

Post by selfmodruntime »

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…

> So Unsafe Rust from a UB perspective is no different than C/C++. If preconditions are violated, UB can occur

Only if you actively disable panics being triggered if unsafe preconditions are triggered. In most code, the program will crash instead. Enabling default panic on up violation in production code was done last year, IIRC.

> Its unclear how the compiler could check anything about preconditions

It can't. This is done at runtime, by default and without manually needed programmer interaction.

You can see an example of this in the `ptr`module, here: https://doc.rust-lang.org/beta/src/core/ptr/mod.rs.html#1071

Some are only enabled for `debug_assert` (which is enabled by default), see `ptr::read`, here: https://doc.rust-lang.org/beta/src/core/ptr/mod.rs.html#1370

Re: Zlib-rs is faster than C

#478

Post by WalterGillman »

1vuio0pswjnm7 wrote: post #206

Which library compiles faster. Which library has fewer dependencies. Is each library the same size. Which one is smaller.

> Which library has fewer dependencies.

This is not insignificant.

Remember xz? That could have been a disaster.

That the language includes a package manager that fetches an assortment of libraries from who knows whom on demand doesn't exactly inspire confidence in the process to me. Alice's secure AES implementation might bring Eve's string padding function along for the ride.

Rust(TM) the language might be (memory) safe in theory but I have serious issues (t)rusting (t)rust and anything built with it.

Re: Zlib-rs is faster than C

#479

Post by burntsushi »

DannyBee wrote: post #466
burntsushi wrote: post #412

Earlier quoted context omitted.

> I can break your safe API by getting the constraints wrong on unsafe code inside that API. This doesn't make any sense at all as a broader point. Of course you can break the safe API by introducing a bug inside the implementation! I honestly just cannot figure out how you have a misunderstanding of this magnitude, and I'm forced to conclude that we are mis-communicating at some level. I did read the rest of your co…

This doesn't seem like we are getting anywhere on this part of the thread, unfortunately. My suggestion would be - if we are ever in the same place, let's just grab coffee or something. In the end - i suspect we are just going to find we have different enough experiences that our views of safe encapsulation and its usefulness are very different. Let's put that aside for a second - I'll also take one more pass at the…

> To go back all the way to where we started, the comment i was originally replying to said "No, C lacks encapsulation of unsafe code. This is very important. Encapsulation is the only way to scale local reasoning into global correctness."

That's fair. I was focusing more on the factual aspect of "Rust enables encapsulating `unsafe`." But you're right, this statement is making a bigger claim than that, and it crosses over into something that is a (in theory) testable opinion.

I do agree with it though. But I recognize that it is a different claim than the one I was putting forward as factual.

I think for this, I would say that my experience with Rust has demonstrated that encapsulation is working at some non-trivial scale. The extent to which it will continue to scale depends, in part, on whether people writing Rust prioritize soundness. In my bubble, this prioritization is extremely high. But will what is arguably a cultural norm extend out to all Rust programmers everywhere?

I legitimately don't know. This is why I was one of the first (but not the first) people to make a stink about improper `unsafe` usage inside the Actix project some years ago. It was because I perceived the project as specifically flouting the cultural norm and rejecting soundness as a goal to strive for. I do indeed see this as an essential piece of what Rust brings to the table, and for it to succeed in its goals, we have to somehow figure out how to maintain the cultural norm that safe APIs cannot be used in a way that leads to UB.

I think where you and I differ is both in what we've seen (it sounds like you've seen evidence of this cultural norm eroding) and what we consider encapsulation busting. I'm not at all worried about bugs in `unsafe` code. Those are going to happen, and yes, they will lead to safe Rust having UB. But those are "just" bugs. The vastly more important thing to me is intent and where blame is assigned when UB happens. If blame starts shifting to the safe code, then that will indicate the erosion of that cultural norm.

As for tooling, I think it's vital to making sure safe encapsulations are correct, but I don't see it as having a significant impact on the norm.

Then again, these are the days in which even some of the strongest cultural norms we've had (in the United States anyway) have been eroding. So maybe building a system on top of one is folly.

Re: Zlib-rs is faster than C

#480

Post by rc00 »

no_wizard wrote: post #449
steveklabnik wrote: post #445

Earlier quoted context omitted.

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…

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

Post reply on HN