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.

> Now why can't compilers do this sort of thing automatically?

They do - they just can't assume GFNI instructions are present unless you explicitly say so: https://godbolt.org/z/eYasbKsse

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.

CISC vs RISC doesn't matter. An ISA should ideally be a healthy mixture of both (citation needed). Arm64 allows memory operands, "just" like x86; but it still has code size issues. Memory operands (ie having a bit of address calculation in the load that's fused into its use) are very useful for reducing register pressure, which is an issue that every call ABI must contend with. This is something that the RISC ISA totally misses (and ARM64.. isn't really RISC).

The issue with this "debate" is that it misses the forest for trees. Instead we should be talking about binary encoding (ie how much "variability" is required), and you're right on that bit; memory isn't the issue it once was.

Sadly, nobody can run from memory management.

> Like almost any thorny military problem of the 1950s, the solution was the application of nuclear bombs.

Magnificent.

I don't think scalable vectors is particularly useful feature, especially compared to what compilers have to go though to support it. It's much more useful to be able to do "more powerful" things with existing vector widths at hardware speeds (or perhaps just make the existing stuff faster than it is) than to be able to go wider. Scalable vectors also doesn't solve the ISA problem: don't break existing processors.

Add a period to the end of the sentence and aberration is gone.

"맙소사, 절대평화주의자들도 가끔 존재 자체가 고통이라 해도 남에게 해를 끼치는 행동을 하는 것 같아요."

See AMD "Smart Memory" a.k.a. PCIe Large Bar. This expands the amount of GPU memory that the CPU can directly access, usually to the GPU's entire memory range (ordinarily only ~256Mb is accessible). GPU->CPU Reads have very high latencies, but that's not an issue for CPU->GPU writes.

GPUs have been able to access "host" memory for a long time now, with a few restrictions: you have to setup the GPU mappings first and pin the pages in memory.

> By the time of the second gulf war, the F-14D cost 20% more per unit than the F-18E, and some 80-100% more to maintain. I'm not sure how you're concluding that the taxpayers were ripped off by that.

He/she isn't concluding that, they are repeating what they were told at the time.

Naw, just use {pointer, length} tuples. Crisis averted.

GB4/5 are... not a particularly high quality codebases. I can't offer anything more than that, but, well, lets just say that GB4/5 is my least favorite benchmark as a compiler engineer for AMD. It shouldn't be given much weight as a benchmark.

These opinions are my own, not of AMD.

HBM GPUs are better off because the memory cores are in the same package as the compute cores. So they get the same amount of cooling love as the compute cores enjoy. At least in theory.

> But if you get it a little too close together, it goes boom.

It won't go boom. One of the difficulties (of many) of the Manhattan project was that it was really really difficult to get fissile material together fast enough to cause a significant explosion. Those conditions are impossible in reactors. What does happen is that gaseous hydrogen is generated and that subsequently explodes.

If P=NP, it only going to be possible because of vectorizing/vectorization.

Artificial sweeteners don't taste like sugar, at least none that I've tried. They're sweet, but it ain't sugar.

Halo: Combat Evolved was originally a Mac game, before MS bought Bungie. Bungie's earlier games were released on Mac first (and maybe only; I don't recall). Myst was a Mac only game for a few years after its release in 1993.