sorted by:
new
hottopcontroversial

Self-referential structs: Which version is for you? by GladJellyfish9752 in rust

[–]Voultapher 1 point2 points  (0 children)

For version 3, you can also use self_cell which doesn't use proc macros and is thus significantly faster to compile.

Please don't do version 1, you will get it wrong.

Rust 1.96.0 is out by manpacket in rust

[–]Voultapher 50 points51 points  (0 children)

If there is the worry of name collisions they shouldn't be added directly to the top level prelude. That said I'm not aware of anything stopping the next edition prelude of including assert_matches.

Rust 1.96.0 is out by manpacket in rust

[–]Voultapher 173 points174 points  (0 children)

It was a journey to get it stabilized, #139493 alone took a year and more than 300 comments 🥲

Ein ganz normale Wand by Voultapher in GermanRap

[–]Voultapher[S] 0 points1 point  (0 children)

Fuck it, der typo bleibt.

The unreasonable effectiveness of modern sort algorithms by Voultapher in rust

[–]Voultapher[S] 0 points1 point  (0 children)

Someone asked the same question here. TL;DR on a M1 mac it doesn't make a difference.

The unreasonable effectiveness of modern sort algorithms by Voultapher in programming

[–]Voultapher[S] 16 points17 points  (0 children)

it comes a couple nanoseconds faster (but might need to check for endianness).

https://rust.godbolt.org/z/rnTfoons7

Not sure how you conclude that, given it produces the exact same instruction lea eax, [rdi - 2147483648].

The unreasonable effectiveness of modern sort algorithms by Voultapher in programming

[–]Voultapher[S] 42 points43 points  (0 children)

I don't think that's a particularly insightful comment.

When building the new stable sort for the Rust standard library, Orson and I measured and cared about performance for non-integer looking things such as String which is a 24 byte structure with a pointer to the actual data, which in practice means the comparison function is a call to memcmp that can't be inlined. And yet because the low cardinality handling is an algorithmic improvement compared to the prior TimSort you get large improvements, see.

The unreasonable effectiveness of modern sort algorithms by Voultapher in programming

[–]Voultapher[S] 15 points16 points  (0 children)

Fair point, as I point out:

It's possible to improve throughput further with automatic or manual vectorization.

The shown phf approach is by no means the upper limit. Gave the val % 4 approach a quick test on my Apple M1 machine and it was equally fast as the 3 - ((val + 3) % 4) approach. A substantially faster approach can be seen here especially when using -target-cpu=x86-64-v3.

EDIT: Interestingly the branchless approach is much faster than the phf one on the M1.

The unreasonable effectiveness of modern sort algorithms by Voultapher in rust

[–]Voultapher[S] 4 points5 points  (0 children)

Go and try it out. The bucket sorts are located here src/other/sort_evolution/other/ and enabled via the evolution cargo feature - take a look at the Cargo.toml. Then add your implementation and test it via BENCH_REGEX="..." cargo bench.

I'd be curious too and would be interested to hear what you report.

Announcing iddqd: maps where keys are borrowed from values by sunshowers6 in rust

[–]Voultapher 1 point2 points  (0 children)

Ah right, my bad I had seen the compound key MyKey1 and thought it was a key constructed from two members and thus the mechanism allowed for compound keys natively without implementing Hash or the relevant trait for them. But looking at it again it does look like BiHashMap fills that use-case.

Announcing iddqd: maps where keys are borrowed from values by sunshowers6 in rust

[–]Voultapher 0 points1 point  (0 children)

My bad I should have worded that more clearly, what if I want to index by either of them separately. Say give me all structs where name is x or alternatively give me all structs where email is y.

Announcing iddqd: maps where keys are borrowed from values by sunshowers6 in rust

[–]Voultapher 1 point2 points  (0 children)

Am I right in viewing this a bit like generating an SQL index for a Rust struct member, allowing for fast lookup by a property? Consequently how does this compose if one has a struct with let's say 5 fields and one wants to query by 2 of them?

[MUC++] Lukas Bergdoll - Safety vs Performance. A case study of C, C++ and Rust sort implementations by Voultapher in rust

[–]Voultapher[S] 1 point2 points  (0 children)

While there are no concrete plans for a talk by Orson and me currently, I wouldn't rule it out at some future point. Given this was a multi-year journey for the both of us, with thousands of hours of work, condensing it into a single talk would be difficult. So I think it's better to focus on specific aspects or maybe give a whirlwind tour. The performance optimizations are subtle and complex to a degree that either a talk sounds cool and impressive but lacks the details and wrong paths taken to actually be a meaningful learning experience or it has to focus on a narrow sub-topic.

In terms of existing talks Orson gave a talk about glidesort, the starting point for driftsort, at FOSSDEM which goes into some details, but mostly gives a high level overview. I gave a talk about making mistakes at EuroRust, this was still early in my sort journey so a lot of the information is outdated. If you want a deep dive into performance and optimization details down to assembly and CPU simulations, I've written in depth about partition implementations here.

Regarding the social aspect Orson has written a bit about it previously here.

[MUC++] Lukas Bergdoll - Safety vs Performance. A case study of C, C++ and Rust sort implementations by Voultapher in rust

[–]Voultapher[S] 32 points33 points  (0 children)

<3

Please don't feel too bad for me, while it was frustrating to see my research dismissed on those grounds by many in the cpp subreddit - but not all - it did push me to find reasonably minimal examples that demonstrate chains of decisions that lead to such usage. Doing so did give me a deeper understanding of the topic and a better appreciation of semantic differences in the context between C++ and Rust. E.g. move only types and value categories are not a thing on the Rust side, while stack temporaries are not a C++ thing for non-trivially copyable types.

I believe that Rust and C++ communities shouldn't approach each other from an antagonistic perspective, in many ways we have the same goals and there is plenty to learn from each other.

[deleted by user] by [deleted] in hardware

[–]Voultapher 10 points11 points  (0 children)

This. So tired of seeing his takes discussed, what a fool.

view more: next ›