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

291–300 of 492 posts

Re: Zlib-rs is faster than C

#291

Post by pjmlp »

throwaway2037 wrote: post #250
sunshowers wrote: post #122

Earlier quoted context omitted.

What language is the JVM written in? All safe code in existence running on von Neumann architectures is built on a foundation of unsafe code. The goal of all memory-safe languages is to provide safe abstractions on top of an unsafe core.

> What language is the JVM written in? I am pretty sure it is C++. I like your second paragraph. It is well written.

Depends on which JVM you are talking about, some are 100% Java, some are a mix of Java and C, others are a mix of Java and C++, in all cases a bit of Assembly as well.

Re: Zlib-rs is faster than C

#292

Post by [deleted] »

timschmidt wrote: post #59
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.

It seems like you've got it backwards. Even unsafe rust is still more strict than C. Here's what the book has to say ( https://doc.rust-lang.org/book/ch20-01-unsafe-rust.html ) "You can take five actions in unsafe Rust that you can’t in safe Rust, which we call unsafe superpowers. Those superpowers include the ability to: Dereference a raw pointer Call an unsafe function or method Access or modify a mutable static va…

[deleted]

Re: Zlib-rs is faster than C

#293

Post by IshKebab »

steveklabnik wrote: post #172
ajross wrote: post #168

Earlier quoted context omitted.

But again, not exploited by the code in question . This isn't using the Rust runtime heap, it's doing its own thing with raw pointers/indexing, and even seems to have its own allocator.

> This isn't using the Rust runtime heap, Rust does not have a specific "Rust runtime heap."

It does, it has a default global heap allocator.

Re: Zlib-rs is faster than C

#294

Post by ricardobeat »

Aurornis wrote: post #29
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…

Using unsafe blocks in Rust is confusing when you first see it. The idea is that you have to opt-out of compiler safety guarantees for specific sections of code, but they’re clearly marked by the unsafe block. In good practice it’s used judiciously in a codebase where it makes sense. Those sections receive extra attention and analysis by the developers. Of course you can find sloppy codebases where people reach for u…

Is this a sloppy codebase? I browsed through a few random files, and easily 90% of functions are marked unsafe.

Re: Zlib-rs is faster than C

#295

Post by atoav »

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 place, with some high effort C-implementations being slower and a highly optimized assembler variant taking first place.

Since then I programmed a lot more in C and C++ as well (for other reasons) and got more experience. Rust is not automatically faster, but the defaults and std library of Rust is so well put together that a common-sense approach will outperform most C code without even trying – and it does so while having typesafety and memory safety. This is not nothing in my book and still extremely impressive.

The best thing about learning Rust however was how much I learned for all the other languages. Because what you learn there is not just how to use Rust, but how to program well. Understanding the way the Rust borrow checker works 1000% helped me avoiding nasty bugs in C/C++ by realizing that I violatr ownership rules (e.g. by having multiple writers)

Re: Zlib-rs is faster than C

#296

Post by TheDong »

johnisgood wrote: post #286
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…

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.

Such a rust zealot is a strawman, though please don't let me stop you from enjoying burning such a strawman.

Re: Zlib-rs is faster than C

#297

Post by josefx »

oneshtein wrote: post #257
throwaway2037 wrote: post #234

Earlier quoted context omitted.

I assume you are hinting at 'int' is signed here? And, that signed overflow is UB in C? Real question: Ignoring what the ISO C language spec says, are there any modern hardware platforms (say: ARM64 and X86-64) that do not use two's complement to implement signed integers? I don't know any. As I understand, two's complement correctly supports overflow for signed arithmetic. I might be old, but more than 10 years ago,…

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 an error value that is not a valid output or just output the error and average in two distinct variables.

AI and C seem like a match made in hell.

Re: Zlib-rs is faster than C

#298

Post by Someone »

tdiff wrote: post #32
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.

Nevertheless Russinovich actually says something in the lines of "simple rewriting in rust made some our code 5-15% faster (without deliberate optimizations)": https://www.youtube.com/watch?v=1VgptLwP588&t=351s

Without analysis as to what caused that, that statement is meaningless.

For example, he says they didn’t set out to improve the code, but they were porting decennia-old C code to rust. Given the subject (truetype font parsing and rendering), my guess would be that the original code had more memory copies copying data out of the font data because rust makes it easier to safely avoid that (in which case the conclusion would be “C could be as fast, but with a lot more effort”), but it could also be that they spent a day figuring out some code did to realize that it wasn’t necessary on anything after Windows 95, and stripped it out, rather than porting it.

Re: Zlib-rs is faster than C

#299

Post by throwaway2037 »

pjmlp wrote: post #291
throwaway2037 wrote: post #250

Earlier quoted context omitted.

> What language is the JVM written in? I am pretty sure it is C++. I like your second paragraph. It is well written.

Depends on which JVM you are talking about, some are 100% Java, some are a mix of Java and C, others are a mix of Java and C++, in all cases a bit of Assembly as well.

You are right. I should have been more clear. I am talking about the bog standard one that most people use from Oracle/OpenJDK. A long time back it was called "HotSpot JVM". That one has source code available on GitHub. It is mostly C++ with a little bit of C and assembly.

Re: Zlib-rs is faster than C

#300

Post by sidkshatriya »

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…

You can choose unsafe rust which has many more optimizations and is much faster than safe rust. Both are legitimate dialects of the language. Should you not feel confident with a library that is too “unsafe” you can use another crate. The rust ecosystem is quite big by now.

Personally I would still use unsafe safe rust than raw C which has more edge cases. Also when I’m not on the critical path I can always use safe rust.

Post reply on HN