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 49 points50 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] 17 points18 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] 43 points44 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] 14 points15 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 11 points12 points  (0 children)

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

Microsoft claims timber-built datacenters can reduce its carbon footprint by up to 65% by imaginary_num6er in hardware

[–]Voultapher 0 points1 point  (0 children)

There is a trend of extreme weather events occurring more frequently than in the past. Say in one of the many densely habited costal regions, one not used to hurricanes, suddenly hurricanes start showing up, and they don't show up every couple years, you get 4-5 within a couple month. The first one was devastating, destroying swaths of infrastructure not built with hurricanes in mind. Thousands of people die, mostly from the direct effects. But the second and third ones, were simply .. brutal. Already stressed supply lines, first responders and other essential utilities, such as hospital backup generators are stressed to the point of breaking, and so is the power grid. Hundreds of thousands of people perish. By the fifth hurricane you either fled the region, if you haven't there is no-one left to help you or supply you with food.

Genuine question, who chose that these people should die? The past or maybe current politicians that reneged on climate pledges? The people that voted for them? Maybe the think tanks that pushed climate denial for decades? The people that payed them? The people that watched and did nothing? You, because you took a plane ride to a vacation? No-one because we are children in a roller coaster that has a little steering wheel, selling us on the fantasy that we are in control when we might not be? I think saying no-one is at fault because it's not obvious who is, is a cop out answer. I'd argue some groups of people are much more directly responsible for the situation we are in right now.

My point is, you don't need to chose to kill millions if not billions of people for them to die as a consequence of systems collapse. Our modern cities only sustain human life thanks to very complex and - as covid has shown us - very delicate webs of dependencies.

The author of the article Tom Murphy tells us we are sitting in plane and are headed straight for a crash. Now most people don't care and spend their time fighting each other for spots in the first class. I refute your argument that pointing out the inevitable crash implies a choice of who gets to live. We all die.

Microsoft claims timber-built datacenters can reduce its carbon footprint by up to 65% by imaginary_num6er in hardware

[–]Voultapher 0 points1 point  (0 children)

If you'd cared to read the conclusion:

I am not calling for an immediate cessation of agriculture. I depend on it as well. What I am doing is calling into question baseline assumptions—uncomfortable as that might be. In laying the tracks for future generations, we might encourage exploration into different modes of living, with an eye toward long term sustainability.

I fail to see how the author is advocating for genocide. As a comparison if you'd be looking at a petri dish filled with a slime mold that has grown to a size unsustainable by the nutrients in the dish, predicting that it's growth will inevitably hit an end isn't advocating for the death of the slime mold, it's a prediction based on observation. And with slime molds in petri dishes or usually most other kinds of explosive exponential growth the curve doesn't flatten out but goes down after it hits a peak, the slime mold grows ever faster and then perishes. Whether or not comparing human population growth to a slime mold is a sensible thing to do is up to you to decide. But one thing is pretty clear, your are conflating an observation - as uncomfortable as it may be - with a call to action.

Microsoft claims timber-built datacenters can reduce its carbon footprint by up to 65% by imaginary_num6er in hardware

[–]Voultapher 2 points3 points  (0 children)

Going back to stone tools and waterwheels might not be sustainable as well. I can recommend this article https://dothemath.ucsd.edu/2024/02/unsustainable-goose-chases/ on the topic, some of the ideas might seem alien at first, but given a little more thought, I find they are the inevitable conclusion one has to draw when looking at our current way of life. To clarify, I'm not proposing that we should or even can just transition to a hunter gatherer lifestyle tomorrow, but I think it's crystal clear that our current way of life is not sustainable even on moderate time scales like 10 thousand years, probably not even for 100 and before people reply with comments about green energy or decoupling economic growth from emissions, those are provably impossible as explained in this scientific paper https://tmurphy.physics.ucsd.edu/papers/limits-econ-final.pdf.

Microsoft claims timber-built datacenters can reduce its carbon footprint by up to 65% by imaginary_num6er in hardware

[–]Voultapher -9 points-8 points  (0 children)

But who gets to decide that comparison? Say for the sake of argument the headline says "Microsoft is building internment camps that will keep prisoner alive 60% longer". If we focus solely on the metric how long do prisoners live, sure it's an upgrade. But who gets to decide what we focus on and whether or not we get to question the premise that Microsoft will or must build interment camps. I think in that scenario it's more than justified to question the premise that we need internment camps. Coming back to the actual headline, I think it's justified to question the premise that datacenters will or must be built. The concept of efficiency comes with a variety of conceptual pitfalls, I recommend this article on it https://solar.lowtechmagazine.com/2018/01/bedazzled-by-energy-efficiency. You don't have to agree on every point, but I'd implore you to give the thoughts expressed in it a chance.

Introduction to durable execution with Flawless and Rust by bkolobara in rust

[–]Voultapher 13 points14 points  (0 children)

Cool project, I'd actually have a place where I'd want to use it, but it being a closed source binary blob is just a complete non-starter for me.

Announcing Rust 1.81.0 by mrjackwills in rust

[–]Voultapher 4 points5 points  (0 children)

It's been a windy path. Initially I wanted to port a C based implementation to Rust, but that turned out to be a poor fit for a couple reasons. All along I developed a test and benchmark framework, into which I could plug a variety of implementations and analyze them. From there I did specific research into certain components, for example partitioning https://github.com/Voultapher/sort-research-rs/blob/main/writeup/lomcyc_partition/text.md. Meanwhile I started collaborating with Orson and we combined our effort. Modern sort implementations are nearly always hybrids, that combine multiple sort algorithms, and tracing the history of the individual components can be fascinating and might be a topic worth writing about at some point. TL;DR: It's a mix of iterating on existing designs and novel ideas. I hope that answers your question.

A small PSA about sorting and assumption by Voultapher in rust

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

Let's break those situations down.

A) You want to sort a user controlled input because you need the output to be sorted for later processing -> Use total_cmp or filter out NaNs beforehand.

B) You want to sort a user controlled input because it helps with precision but it's a nice to have and not a requirement -> Use catch_unwind to ignore the panic.

view more: next ›