Surely it's obvious, but authority matters. If I do a google search and then scan over a SERP and click through and read the answer I'm looking for, there are a hundred and one signals about where it's coming from. Is it a news page? The manufacturer's documentation? Someone's blog? A random forum post? If it's a forum post, are there are others participating, and if so what do they say about it?
All of this matters, and all of it is erased when it's just Google itself apparently telling me in black on white text above all the search results "here's the answer you're looking for ps. I'm an AI and can make mistakes, btw this space will sometimes secretly be an ad lol"
Fair, but it depends how uniform the culture is around a particular project. Is it haskell and everyone is using emacs? Sure, include those. But trying to chase the requirements of half a dozen different editors is silly.
That's the thing though, you don't need to do that.
Whoever is using whatever editor can do it, so the effort is distributed to whoever cares to contribute.
There is no meaningful penalty for it to be not up-to-date. There is only a benefit for people who come in when it's already configured, as they don't need to configure anything anymore.
(I say that but I'm using a global ignore too for eg ai configuration like skills as I like to half-ass them before discarding again)
Basically, even if your application _can_ run as the kernel, and it's desirable for it to run with kernel-level permissions, do you really want production to be a world without strace and iotop and the like?
Indeed, there's no "be a better/stronger cancer and spread more effectively to more hosts" the way there is with bacteria or a virus. It's not like the flu where we need a new shot every winter because every winter is a new flu.
Once we solve the cancers we know about, they're solved forever, with the one caveat that more people will live longer, so that will increase the window for eventually still ending up dying to one of the cancers that happens to have a non-evolved built in resistance to this or that treatment. Which is a great deal of course, especially if it's a treatment that sounds way less destructive of QoL than chemo, radiation, etc.
>there's no "be a better/stronger cancer and spread more effectively to more hosts"
No, but there is "be a better/stronger cancer cell and don't succumb to whatever therapy is killing its neighboring cells." It's exactly akin to how dosing isolated populations of bacteria with antibiotics selects for individual cells that are resistant, which then multiply and dominate [0], just like a tumor.
Right, but that's within a single host isn't it? Like patient A gets that mutation and succumbs, that sucks, but the stronger cancer cells don't them jump to patient B the way antibiotic-resistant bacteria do.
(barring the transmissible cancers article that your sibling comment linked to, but that's not the common case)
Sure, but my point is that convergent selective pressure across different individuals' tumors is strong enough that they independently arrive on the same resistance mechanisms to a given therapy, e.g. [0]. Just like if you performed the same bacterial antibiotic resistance experiment [1] across multiple independent trials, you'd repeatedly get the same result.
One of the frustrating limits historically with some of these is that when you're already an unprivileged user it's been difficult or impossible to get to a sandboxed environment to perform hermetic or untrusted builds. So like with nix for example you could do a user install and then builds would build as your user, but if you installed as root, then builds would delegate out properly to nixbld users.
This has gotten better in recent years with user namespaces but it takes time for it to be adopted and achieve parity with what used to be just jumping to a user who can only write to a newly created dir in tmp.
So I was a Mac user for years and accepted and adapted to natural scrolling after it appeared as the default in 2011. When I switched back to a Windows laptop for work around 2018, I kept it on natural mode.
But then two years ago I got a desktop computer with an external mouse again and.... natural scrolling doesn't work for me on a physical wheel. With a trackpad, the metaphor is direct, that the page or document is being moved by the motion of your fingers; but with a wheel, I still want to pull it toward me to scroll down, because that feels like rolling the little wheel along the document, or turning it to advance the document beneath, like a printer finishing a page.
Maybe that's all silly, but for me it's natural scrolling on trackpads and conventional scrolling on mice with scrollwheels.
I've long been surprised there isn't more multiversion stuff built right into every language compiler; I would have thought Intel would be very motivated to get more binaries lighting up the features they add to their expensive top line CPUs.
But yeah no, on the whole cost of the checks and duplicated binary size aren't seen as worth it, so instead it's piecemeal implementations mostly in numeric packages like eigen and lapack.
> so instead it's piecemeal implementations mostly in numeric packages like eigen and lapack.
Because that’s where the user-noticeable gains can be made. Using popcount in code you run once is going to shave off, maybe, 100 cycles. That isn’t worth the extra cycles of that approach.
Also, FTA: “and arguably the whole scheme should be replaced by finer-grained feature detection”. Such feature detection would lead to a combinatorial explosion of different binaries.
Finally, where it really matters, it’s not only a matter of recompiling the same code. For optimal performance, you also want to change loop unrolling strategy, stride count, etc.
Doesn't that get into the domain of a distro like Gentoo though? (Or sort of Nix as well) - rebuild everything to precisely target your actual architecture.
Yes, and the maximally performant configurations are at odds with a usefully hardened security posture. This only gets more true as time goes on and additional mitigations pile up.
POPCNT is an interesting example. Runtime dispatch (with a conditional branch) would actually make sense for it because it's comparatively difficult to implement from scratch. PDEP and PEXT might be similar (but I don't think compilers pattern-match for it, unlike POPCNT). AArch64 uses localized run-time dispatch extensively because LL/SC atomics are so very bad on current cores, but there isn't anything comparable in the x86-64 space (POPCNT isn't that frequent).
For many other things, like using a YMM register to copy a 32-byte struct or a variable shift, run-time dispatch just not make sense. You will only see a benefit if you generate this code unconditionally. For FMA, you wouldn't even get bit-identical output, leading to testing concerns.
> Also, FTA: “and arguably the whole scheme should be replaced by finer-grained feature detection”. Such feature detection would lead to a combinatorial explosion of different binaries.
I see I wasn’t clear enough. The tool I discussed generates multiple binaries and then packs all of them into a single binary. I was referring to the former.
“After building the different versions, it computes a hash of each version and it filters out the duplicates (i.e., the compilations that gave the same binaries despite having different CPU features). Finally, it builds a runner that embeds one version compressed (the source) and the others as compressed binary patches to the source. For instance, when building for the target x86_64-pc-windows-msvc, by default 4 different versions will be built, filtered, compressed, and merged into a single portable binary.
When executed, the runner uncompresses and executes the version that matches the CPU features of the host.”
Hopefully (and likely) the patches will not be too large, but for 6 binary compiler flags, you’d still have 2⁶ binaries.
Yeah, but that's because of pragmatic choices to limit the scope of the tool. In the wider context of "I've long been surprised there isn't more multiversion stuff built right into every language compile" it's easy to imagine a compiler that can heuristically detect which functions would benefit from certain CPU features, and walk over the call graph to find locations for runtime feature detection that balance detection overhead with code duplication for the fallback functions. For example merging the feature detection of adjacent function calls, making sure feature detection is moved out of hot loops, etc.
Obviously this is much easier to imagine than to implement. And in some languages it might be made impossible by certain language features (function pointers might become tricky). But this is more or less what some people do by hand in Rust with the more manual is_x86_feature_detected macro, so there's no obvious reasons why compilers couldn't automate it in at least some languages.
Ok, then it will be an explosion of binary size, if you have several code blocks optimized for each architecture level - I'm not very familiar with the subject, but I imagine it would have to be relatively large chunks of code, otherwise the constant branching would eat up the speed advantage.
Are current datacenter deployments structured in such a way that the memory can later be moved to newer GPU dies? Or is it all packaged together as on consumer graphics cards?
I assumed the latter and therefore that the memory is depreciating along with the GPU cores it's soldered onto PCBs with.
... or is it a different argument being made, perhaps that depreciation for GPUs has slowed because rising demand will keep them in service longer?
Removing RAM chips off old cards is uneconomical, until it isn't. With things going the way they are, if you've got a card with soldered on RAM that could be transplanted to a newer card, I think you'll start seeing that happening.
All of this matters, and all of it is erased when it's just Google itself apparently telling me in black on white text above all the search results "here's the answer you're looking for ps. I'm an AI and can make mistakes, btw this space will sometimes secretly be an ad lol"
reply