diamondlovesyou

Yeah, and specialists are "usually" not available via urgent care. If not for the like of urgent care, specialties would be worse. The fact that it takes so long for such access is still a demand and supply problem at the end of the day, no way around the knowledge bottleneck - fixing that means shifting demand to different, more plentiful, supply (doing that soundly is not trivial, but likely easier than attempting to multiply the specialists, depending on the specialist). ERs are expensive because they have to have certain specialties "on tap" 24/7, among other reasons. This is not a unique problem of any single health-care system.

> Because even here in the US if you aren't fabulously wealthy with concierge medical you'll be waiting weeks/months to see a 'doctor'. And you'll almost certainly never actually see a doctor, you're going to see an overworked NP (no shade on NPs here, most of whom are great, just establishing how our medical system actually works in 2026).

But it's simply not true. my mom broke her back last year and before we realized that her back was broken, we saw an urgent care doctor, same day, within 30mins (I don't recall the exact timescale now, but it was pretty much instant). Who promptly gave my mom an Rx and told us to go to the ER. Personally, urgent care appointments have always been available within 2hrs, and even stuff like an xray (usually in a centralized office, so some travel required) is possible same day. This isn't special treatment.

If someone is waiting long for care, it isn't a problem with the system - and the alternative you speak of isn't going to solve the "I'm not a medical doctor" problem either, which is the main objection to the long wait-times. Minor hypochondriac-ness notwithstanding - nothing will be able to solve that completely - money is the back-pressure mechanism to avoid waste of limited resources. Whether anybody likes it or not, doctors/xray-machines/etc are not infinite (for now heh).

For-profit health-care insurance companies should burn in hell, though.

Not if you can't prove anti-aliasing properties, which wasm doesn't carry.

That won't be located on the stack either. The underlying buffer will be a TU local - ie static and not rx

> This post makes it seem like the pass ordering problem is bigger than it really is and then overestimates the extent to which egraphs solve it.

It isn't so much for SoTA implementations like LLVM, but it is for HL IRs like those present in MLIR. For LLVM, you're basically always in the same representation and every pass operates in that shared representation. But even then, this is not quite true. For example, SLP in LLVM is one of the last passes because running SLP before most "latency sensitive cleanups" would break most of them.

In particular, HL to LL lowering pipelines suffer very heavily from the ordering concerns.

I don't use credit cards for the credit; in fact mine are completely paid for every statement. They are used for the customer protections and other provided "free" benefits. If some scummy or outright scam-y thing is charged to my Amex, I know I will have Amex on my side. If my card is stolen, Amex will refund any fraudulent charges and overnight me a new card; I probably won't get my debit card overnighted, though they will probably refund the fraud. The other thing is credit card points, which are essentially a benefit paid for by credit card processing fees charged to businesses. Many cards also offer access to "private" airport lounges. And other benefits I'm forgetting off the top of my head.

Additionally, having high credit limits, low usage, and older accounts improves credit scores for loans/etc.

No interest is charged if there is no balance carried statement-to-statement, so why bother with silly debit pins and such.

That's how it becomes the default way of payment; it's not really "credit".

Less area means less sources of interference for others (this property is also true in the other direction). So the attenuation reduces the signal area, and stronger attenuation lets the transmitter be "strong" in the house without the downsides in congested areas.

> Why is cooperation unlikely? AFAIK it’s not too hard to make a compiler support a function attribute that says “do not optimize this function at all”

Compilers like Clang actually generate terrible code; it's expected that a sufficiently smart optimizer (of which LLVM is a member) will clean it up anyway, so Clang makes no attempt to generate good code. Rust is similar. For example, a simple for-loop's induction variable is stored/loaded to an alloca (ie stack) on every use, it isn't an SSA variable. So one of the first things in the optimization pipeline is to promote those to SSA registers/variables. Disabling that would cost a ton of perf just right there, nevermind the impact on instruction combining/value tracking/scalar evolution, and crypto is pretty perf sensitive after security.

BTW, Clang/LLVM already has such a function-level attribute, `optnone`, which was actually added to support LTO. But it's all or nothing; LLVM IR/Clang doesn't have the info needed to know what instructions are timing sensitive.

GB6 will use the Zen4's AVX512, which Zen2 doesn't support.

Fast is relative here. These are microcoded instructions, which are generally terrible for latency: microcoded instructions don't get branch prediction benefits, nor OoO benefits (they lock the FE/scheduler while running). Small memcpy/moves are always latency bound, hence even if the HW supports "fast" rep store, you're better off not using them. L2 is wicked fast, and these copies are linear, so prediction will be good.

Note that for rep store to be better it must overcome the cost of the initial latency and then catch up to the 32byte vector copies, which yes generally have not-as-good-perf vs DRAM speed, but they aren't that bad either. Thus for small copies.... just don't use string store.

All this is not even considering non-temporal loads/stores; many larger copies would see better perf by not trashing the L2 cache, since the destination or source is often not inspected right after. String stores don't have a non-temporal option, so this has to be done with vectors.

AMD's string store is not like Intel's. Generally, you don't want to use it until you are past the CPU's L2 size (L3 is a victim cache), making ~2k WAY too small. Once past that point, it's profitable to use string store, and should run at "DRAM speed". But it has a high startup cost, hence 256bit vector loads/stores should be used until that threshold is met.

I have been very happy with my Minisforum Venus UM790, though I use it as a mobile computer since I can just throw it into my backpack. It's been great to have access to AVX512 on the go.

> It is not a language flaw. C++ requires types to be complete when defining them because it needs to have access to their internal structure and layout to be in a position to apply all the optimizations that C++ is renowned for. Knowing this, at most it's a design tradeoff, and one where C++ came out winning.

This statement is incorrect. "Definition resolution" (my made up term for FE Stuff(TM) (not what I work on)) happens during the frontend compilation phase. Optimization is a backend phase, and we don't use source level info on type layout there. The FE does all that layout work and gives the BE an IR which uses explicit offsets.

C++ doesn't allow two phase lookup (at least originally); that's why definitions must precede uses.

The power of the optimizations available to C++ are what make it so fast (see how slow debug mode is vs -O2/etc), and what allow C++ to be fast in the face of common/easy-to-understand, but technically perf-hostile, patterns. Bit counting loops vs popcnt, auto-vectorization, DCE, RCE, CSE, CFG simplification, LTCG/LTO, and so on. These things let you write "high level" (to a point - there are some ways to do "high level" paradigms and absolutely eviscerate the compilers ability to optimize) code/algos and still get great hardware level performance. This is so much more important overall than the time it takes to compile your program, and even more so once you consider that often such programs are shipped once and then enter maintenance mode.

It doesn't really have anything to do with compatibility (not entirely, but the things that are the biggest issue to good optimization quality and are fixable are things that need a system-level rethinking on how hardware exceptions happen). It just isn't reasonable to expect developers to know how to optimize, and it doesn't scale.