UPDATE tracking_data
SET shown_in_interface = false
WHERE account_name = 'm463'8,833 karma · joined March 27, 2013
Publish a blog at https://orlp.net/blog/.
Other socials:
http://github.com/orlp/
https://stackoverflow.com/users/565635/orlp
https://linkedin.com/in/orson-peters/ UPDATE tracking_data
SET shown_in_interface = false
WHERE account_name = 'm463' vminpd ymm2, ymm1, ymm0
vcmpunordpd ymm0, ymm0, ymm0
vblendvpd ymm0, ymm2, ymm1, ymm0
If you want proper IEEE 754-2019 minimum (propagate NaN, -0.0 < +0.0, NaN bitpattern picked in the usual way) you can do it in 6: vminpd ymm1, ymm0, ymm1
vbroadcastsd ymm2, qword ptr [rip + .LCPI0_0]
vandpd ymm2, ymm0, ymm2
vorpd ymm1, ymm2, ymm1
vcmpunordpd ymm2, ymm0, ymm0
vblendvpd ymm0, ymm1, ymm0, ymm2
I personally find this a load of nonsense I don't care about.If you want propagating NaNs but don't care about signed zero or NaN payload/sign, you can use
vminpd ymm2, ymm0, ymm1
vminpd ymm1, ymm1, ymm0
vorpd ymm0, ymm1, ymm2
What I do in Polars is a bit different, there for propagating NaNs I do if (self < other) | self.is_nan() { self } else { other}
this isn't fully optimal on x86-64 but it's fairly simple and autovectorizes decently on various platforms, here's AVX2: vcmpltpd ymm2, ymm0, ymm1
vcmpunordpd ymm3, ymm0, ymm0
vorpd ymm2, ymm3, ymm2
vblendvpd ymm0, ymm1, ymm0, ymm22. It is non-bypassable tracking of every single click.
3. It does not allow you to inspect the URL to see where it goes to before visiting.
4. It breaks the feedback signal of extensions which redirect sites. E.g. Fandom wikis are shit so I have them redirected to equivalent much better wikis like. But now any such redirection has to be done post-click tracking meaning Google still believes I want to see the Fandom site.
5. It breaks extensions which hide certain shit search results based on URL.
Rust isn't inherently bad at io_uring but at least Tokio currently is. I'm not the one who implemented and benchmarked it so this is second-hand information but if I recall correctly Tokio shares one buffer pool for all threads so as you scale to 100+ threads the whole thing grinds to a halt.
Migrating our I/O to a different async runtime than Tokio was rejected. So we'll wait until it's fixed in Tokio and now use regular blocking reads instead.
This purpose is however much easier/flexible than actual polynomial equivalence since the requirement here is only that the polynomial is injective, not identical.
WyHash and xxh3 do not have polynomial structures.
Again, can you even just name a single supply chain attack that was *shipped* in Rust software? Against the thousands and thousands of known memory vulnerability bugs throughout time?
> And yes, there were successful supply chain attacks on Rust developers, even just recently: https://blog.rust-lang.org/2026/08/20/supply-chain-attack-on... despite this being a "solved" problem.
No, your linked blog post predates the brand-new min-age requirement. The minimum age would have prevented it, since it was detected by AI within an hour. If anything it supports my point.
Plus, as I already mentioned, that is a build.rs supply chain attack that targets developers, not shipped software.
1. Set a minimum age on dependencies: https://github.com/rust-lang/cargo/issues/15973
2. Scan all dependency code with AI
Even if you don't do #2 yourself as long as anyone does in the age window you've set, you're protected. In the age of AI the "you can't read all dependency code" argument doesn't work anymore.On top of the above modern age argument, let's compare the amount of vulnerabilities found in shipped Rust software due to supply chain attacks (0 to my knowledge) against memory safety vulnerabilities (the majority of all vulnerabilities).
There have been successful supply chain attacks against Rust developers due to build.rs but those were quickly dealt with, and should be a thing of the past once min-age hits stable (next release).
Found by searching for wiki + texas poverty.
1. All players flips a coin.
2. Players that got heads go before players that got tails, forming (up to) two groups.
3. If a group has more than one player go back to #1 to determine the order within that group.
It's not a finite process though - it could go on forever if really unlucky. But this is unavoidable, since the number of permutations on n players with n > 2 has factors not divisible by 2 there is no finite series of n coin tosses that could without any bias create a permutation, as the number of outcomes is 2^n.But no, that's not what I meant. I meant that the batch is meant to be of a size that fits in your CPU cache. This can be a huge throughput improvement as each bit of data stays in cache as it moves from data source to sink.
Compare this to column-at-a-time execution: by the time you start the next operation on this column the start of the column will be out of cache again, meaning you operate at RAM speed (or worse, disk speed) rather than cache speed.
I gave a (fairly surface-level) talk on the streaming engine a bit over a year ago: https://pola.rs/posts/talk-polars-meetup-1-streaming-engine/.
The name was chosen early on to contrast with the old execution model, which was essentially all-data-in-memory, column-at-a-time. That engine still exists, we use it as a fallback mechanism for things that aren't supported yet in the new engine (or if you explicitly ask for `engine="in-memory"`).
The new execution model first constructs a computational graph of nodes which communicate in streams of in-cache batches (morsels) of data, meaning the full dataset will never be held in memory if not necessary. This was called the streaming engine for that reason in an early prototype and the name stuck. In hindsight I do admit the naming choice is somewhat confusing.
from polars import col as C
df.select(C.x, y = C.w / C.z)The continuous energy footprint per person globally averages to 356 watt currently.
The compiler itself might be perfectly "memory safe" but the generated binary fundamentally is always at risk (besides WebAssembly I suppose).
I'm fully aware of the separation of compiler and binary, and being able to compile untrusted code safely is nice, but a perfectly safe compiler that generates vulnerable binaries isn't that much better.
Then to finish the conversion you subtract 2^52 and 2^(52 + 32) respectively from the halves and add them together.
vmovq xmm0, rdi
vpunpckldq xmm0, xmm0, xmmword ptr [rip + .CONST1]
vsubpd xmm0, xmm0, xmmword ptr [rip + .CONST2]
vshufpd xmm1, xmm0, xmm0, 1
vaddsd xmm0, xmm1, xmm0
Here CONST1 = [0x43300000, 0x45300000, 0, 0] and CONST2 = [0, 0x43300000, 0, 0x45300000].Second, I have independently invented this (quicksort on string prefixes) at my time at CWI, although I didn't end up publishing it, because...
Third, this was already published in the original 1961 Quicksort paper by Hoare: https://www.cs.ox.ac.uk/files/6226/H2006%20-%20Historic%20Qu.... Near the end, the section on "Multi-word keys" describes a quicksort that partitions on just the first word, and only accesses the next word for the equality partition. And funnily enough this paper credits P. Shackleton for this, thus this idea was thought of even before the Quicksort paper came out.
So as is usual for software patents, this patent never should have been awarded.
A full-on nuclear war will literally make a large portion of our planet uninhabitable for anyone for centuries, and leave the rest severely crippled and contaminated.
Sorry I know we're supposed to be kind and whatnot in these comments but I can't help but explicitly state that your comment is one of the dumbest things I've read on this site in a while. I hope you otherwise have a good day.