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

401–410 of 492 posts

Re: Zlib-rs is faster than C

#401

Post by steveklabnik »

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…

> 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 point is that you don't need to. The guarantees compose.

> The usual retort to these questions is 'well, the standard library uses unsafe code

It's not about the standard library, it's much more fundamental than that: hardware is not memory safe to access.

> If Rust did not have a mechanism to use external code then it would be fine

This is what GC'd languages with runtimes do. And even they almost always include FFI, which lets you call into arbitrary code via the C ABI, allowing for unsafe things. Rust is a language intended to be used at the bottom of the stack, and so has more first-class support, calling it "unsafe" instead of FFI.

Re: Zlib-rs is faster than C

#402

Post by cesarb »

josefx wrote: post #297
oneshtein wrote: post #257

Earlier quoted context omitted.

AI rewrote to avoid undefined behavior: int average(int x, int y) { long sum = (long)x + y; if(sum > INT_MAX || sum

> long sum = (long)x + y; There is no guarantee that sizeof(long) > sizeof(int), in fact the GNU libc documentation states that int and long have the same size on the majority of supported platforms. https://www.gnu.org/software/libc/manual/html_node/Range-of-... > return -1; // or any value that indicates an error/overflow -1 is a perfectly valid average for various inputs. You could return the larger type to encode…

> There is no guarantee that sizeof(long) > sizeof(int), in fact the GNU libc documentation states that int and long have the same size on the majority of supported platforms.

That used to be the case for 32-bit platforms, but most 64-bit platforms in which GNU libc runs use the LP64 model, which has 32-bit int and 64-bit long. That documentation seems to be a bit outdated.

(One notable 64-bit platform which uses 32-bit for both int and long is Microsoft Windows, but that's not one of the target platforms for GNU libc.)

Re: Zlib-rs is faster than C

#403

Post by ofek »

brianpane wrote: post #354
Boereck wrote: post #340

Earlier quoted context omitted.

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.

A long-standing issue with that was just recently fixed: https://github.com/rust-lang/rust/pull/133250

Re: Zlib-rs is faster than C

#404

Post by School-Cotton »

cesarb wrote: post #398
School-Cotton wrote: post #372

Earlier quoted context omitted.

Why is it particularly funny? C has to make a syscall to the kernel which ultimately results in a BIOS interrupt to implement printf, which you need for the hello world program on page 1 of K&R. Does that mean that C has no abstraction advantage over directly coding interrupts with asm? Of course not.

> C has to make a syscall to the kernel which ultimately results in a BIOS interrupt to implement printf, That's not the case since the late 1990s. Other than during early boot, nobody calls into the BIOS to output text, and even then "BIOS interrupt" is not something normally used anymore (EFI uses direct function calls through a function table instead of going through software interrupts). What really happens in th…

Thanks for the information (I mean that genuinely, not sarcastically — I do really find it interesting). But it doesn’t really impact my point.

Re: Zlib-rs is faster than C

#405

Post by hyperbrainer »

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.

Honestly, that website is so far off the end of the sanity meter that I don't know what to say. Technically, you are right in that counterexamples exist. But on platforms like HN/techincal subreddits etc., never seen it myself, suggesting the problem is far less widespread than one might be initially moved to assume.

Re: Zlib-rs is faster than C

#406

Post by hyperbrainer »

chjj wrote: post #371
mplanchard wrote: post #355

Earlier quoted context omitted.

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.

Fair enough. I suppose it is my most recent encounter. The result: I still don't like the rust community. You may have different opinions. I see no issue here.

> I still don't like the rust community

I wonder whether you believe these people would ever be endorsed by the faces of the Rust language or whether the majority of people in the community would behave so. In my experience (not to minimise yours), the Rust community and FOSS in general, are some of the most open and welcoming communities online, albeit with clear exceptions

Re: Zlib-rs is faster than C

#407

Post by hyperbrainer »

throwaway150 wrote: post #356
hyperbrainer wrote: post #267

Earlier quoted context omitted.

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.

If that is the case (and I have no reason to believe otherwise), I apologise. Should work on detecting tone better.

Re: Zlib-rs is faster than C

#408

Post by hyperbrainer »

oneshtein wrote: post #397
hyperbrainer wrote: post #270

Earlier quoted context omitted.

In GR, the speed of gravitational waves is _exactly equal_ to c.

In reality, speed of light is slightly lower than speed of gravitation, because gravitation slows down speed of light.

We were presumably talking about an ideal massless space [Minkowski] in which the speed of light in a vaccuum is considered -- that is what c is defined as.

Re: Zlib-rs is faster than C

#409

Post by atiedebee »

PhilipRoman wrote: post #275
techjamie wrote: post #44

Earlier quoted context omitted.

There is an option to not link to it for instances like OS writing and embedded. Writing everything in pure Rust without libc is entirely possible, even if an effort in losing sanity when you're reimplementing every syscall you need from scratch. But even then, your code is calling out to kernel functions which are probably written in C or assembly, and therefore "dangerous." Rust code safety is overhyped frequently,…

Ironically using C without libc turns out to be easier (except for portability of course). The kernel ABI is much more sane than . The only useful parts of libc are DNS resolution and text formatting, both of which it does rather poorly.

By text formatting, do you mean printf and the like? It is pretty powerful in my experience.

Also, DNS resolution isn't part of the C standard, it's a POSIX interface I think.

Re: Zlib-rs is faster than C

#410

Post by cesarb »

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…

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

Yes, there is a boundary, and usually it's either the function itself, or all methods of an object. For instance, a function I wrote recently goes somewhat like this:

  fn read_unaligned_u64_from_byte_slice(src: &[u8]) -> u64 {
    assert_eq!(src.len(), size_of::());
    unsafe { std::ptr::read_unaligned(src.as_ptr().cast::()) }
  }
The read_unaligned function (https://doc.rust-lang.org/std/ptr/fn.read_unaligned.html) has two preconditions which have to be checked manually. When doing so, you'll notice that the "src" argument must have at least 8 bytes for these preconditions to be met; the "assert_eq!()" call before that unsafe block ensures that (it will safely panic unless the "src" slice has exactly 8 bytes). That is, my "read_unaligned_u64_from_byte_slice" function is safe, even though it calls unsafe code; the function is the boundary between safe and unsafe code. No callers of that function have to worry that it calls unsafe code in its implementation.
Post reply on HN