Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Making Rust as Fast as Go

christianfscott.com

Post reply on HN
Print view View original

141–150 of 211 posts

Re: Making Rust as Fast as Go

#141

Post by FpUser »

arcticbull wrote: post #100
otterley wrote: post #84

Earlier quoted context omitted.

> this post is probably Fake News It's not Fake News. Fake News is the publication of intentionally false stories. This is just erroneous. There's a yawning chasm between the two.

"fake news" is an attempt at permanently damaging the American public's faith in the fifth estate. Nobody should ever use that term in the current political climate, ever.

"damaging the American public's faith" - Really, just the American? You ever realize there are other human species on this planet?

Re: Making Rust as Fast as Go

#142

Post by fortran77 »

codeflo wrote: post #45
fortran77 wrote: post #40

Earlier quoted context omitted.

This is simply false. Windows APIs are stable. It's one of the best platforms for back compatibility. The kernel32/user32 API has been stable for 20 years. Rust has some work to do.

That’s exactly my point: The problem is that Rust doesn’t use the stable kernel32/user32 functions (VirtualAlloc etc.), but the libc ones, which don’t have a stable location on Windows. Without looking it up: Which DLL do you have to redistribute this week to get “malloc”?

I just tell Visual Studio to create an installer, I select the set of target platforms, and it just works. See, for example: https://docs.microsoft.com/en-us/cpp/ide/walkthrough-deployi...

Re: Making Rust as Fast as Go

#143

Post by dan-robertson »

fluffything wrote: post #114
dan-robertson wrote: post #85

Earlier quoted context omitted.

I suspect that statement is not true for floats. Possibly you don’t get the same float from min(0,-0) as min(-0,0), and similarly with NaNs. Rust specifies that if one input is NaN then the other is returned but doesn’t say what happens if both are NaN.

> Rust specifies that if one input is NaN then the other is returned but doesn’t say what happens if both are NaN. It does. If both are NaN a NaN is returned. Note, however, that when Rust says that a NaN is returned, this means that any NaN can be returned. So if you have min(NaN0, NaN0) the result isn't necessarily NaN0, it might be another NaN with a different payload.

Right. That’s what I was getting at but I didn’t know the NaN-return rule.

Re: Making Rust as Fast as Go

#144

Post by klodolph »

derefr wrote: post #105
arcticbull wrote: post #104

Earlier quoted context omitted.

This doesn't even begin to get into the question of what Levenshtein Distance even means in a Unicode context. What's the Levenshtein Distance of 3 emoji flags? I suppose we should be segmenting by grapheme clusters and utilizing a consistent normalization form when comparing, but Rust has no native support for processing grapheme clusters -- or for normalizations I believe. The UnicodeSegementation crate might help.…

Levenstein (edit) distance is fundamentally an information-theoretical concept defined on bitstreams, as insertions/deletions/swaps of individual bits within a stream. It has a lot in common with error-correcting codes, fountain codes, and compression, which all also operate on bitstreams. Any higher-level abstract mention of Levenstein distances (e.g. of Unicode codepoints) is properly supposed to be taken to refer…

> Any higher-level abstract mention of Levenstein distances (e.g. of Unicode codepoints) is properly supposed to be taken to refer to the Levenstein distance of a conventional (or explicitly specified) binary encoding of the two strings.

This doesn’t match any definition of Levenshtein distance that I’ve ever encountered. I’ve always seen it defined in terms of strings over some alphabet, and the binary case is just what happens when your alphabet only has two symbols in it.

Quite naturally the problem with Unicode strings is that there is are multiple ways to treat them as sequences. One obvious way is to treat them as a sequence of Unicode scalar values, but that’s by no means what you’d want—maybe a sequence of grapheme clusters may be more appropriate, and you also may wish to consider normalization.

Re: Making Rust as Fast as Go

#145

Post by empath75 »

otterley wrote: post #131
will4274 wrote: post #122

Earlier quoted context omitted.

Says who? When news organizations take other news organizations word for it and the story is false, that's fake news. We called it something different back then, but fake news led to the invasion of Iraq. Negligence is sufficient for fake news, malice not required.

Fake News was a term invented around 2015 during the run-up to the 2016 election. It specifically referred to the phenomenon of literally fake news stories, such as rallies and completely false stories about politicians, being published by legitimate-sounding but nonexistent news organizations, using platforms like Facebook to disseminate themselves. Usually these were done from China and Russia.

And then trump redefined it to be about legitimate news sources exclusively. We’ve really been in upside down world for four years.

Re: Making Rust as Fast as Go

#147

Post by saagarjha »

virtualritz wrote: post #75

I tried this on a spare time project[1]. Runtime in a quick test went down from 14.5 to 12.2 secs on macOS! So a solid ~15% by changing the allocator to jemalloc. However, I now have a segfault w/o a stack trace when the data gets written at the end of the process. Possibly something fishy in some `unsafe{}` code of a dependent crate of mine that the different allocator exposed. :] Still – no stack trace at all is ve…

I have found that jemallocator is currently broken on macOS Catalina, so that might be the problem. If you can reproduce this issue reliably, I'd love to hear about it because I can't myself unless I use a very specific toolchain that produces -O3 binaries that are a real pain to work with.

Re: Making Rust as Fast as Go

#148

Post by arcticbull »

FpUser wrote: post #141
arcticbull wrote: post #100

Earlier quoted context omitted.

"fake news" is an attempt at permanently damaging the American public's faith in the fifth estate. Nobody should ever use that term in the current political climate, ever.

"damaging the American public's faith" - Really, just the American? You ever realize there are other human species on this planet?

That's a fair criticism if clumsily put. For the record, I'm Canadian, British and Polish. I called out America as by far the biggest perpetrator at the moment.

So to address the second half of your post, I have indeed heard of "other countries" (just ask USCIS) although being a US resident at the moment I want to speak to what I know, not for anyone else.

Though if we're being super pedantic, there's only one human species on this planet -- species of course being defined as animals who can mate and produce viable offspring.

Re: Making Rust as Fast as Go

#149

Post by arcticbull »

jfkebwjsbx wrote: post #135
gpm wrote: post #92

Earlier quoted context omitted.

One of the most frustrating parts of rust (for me), is that `std::cmp::min` (and some other methods) require that their arguments are `Ord` (totally ordered), and floats are only partially order because of NaN, so you can't use std::cmp::min on floats.

Yeah, it makes no sense to be the default. Code that expects to treat NaNs is very rare.

Safety is the whole idea behind Rust, and if you draw the line here, that's neither in line with the Rust ethos, nor particularly valuable. After all, code that "expects to handle" null was pretty rare too ;)

Re: Making Rust as Fast as Go

#150

Post by matklad »

matklad wrote: post #138
burntsushi wrote: post #56

Earlier quoted context omitted.

It's cheap, but not _that_ cheap. It shouldn't be as cheap as just iterating over a sequence of 32-bit integers. But yes, I did benchmark this, even after reusing allocations, and I can't tell a difference. The benchmark is fairly noisy. I agree with your conclusion, especially after looking at the input[1]. The strings are so small that the overhead of caching the UTF-8 decoding is probably comparable to the cost of…

> It shouldn't be as cheap as just iterating over a sequence of 32-bit integers. I wonder if there are any benchmarks about this? Specifically, it feels like in theory iterating utf8 could actually be faster if the data is mostly ascii, as that would require less memory bandwidth, and it seems like the computation is simple enough for memory to be the bottleneck (this is a wild guess, I have horrible intuition about…

Did a quick benchmark: https://gist.github.com/matklad/ebc1acd2fab884f3ff9d96d4175f....

Seems like hypothesis is not wrong, but also is not interesting: the difference is pretty small, and it can be easily dwarfed by the big wins for utf32 if something like auto-vectorization or bounds-check elision kicks in. Also I am not entirely sure that the diff I observe is not due to something completely irrelevant, like one loop ending up on a lucky cacheline or what not.

Post reply on HN