> 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.
My father had his heart in afib for over 3 months straight as US hospitals and doctors jerked him around and set appointments weeks out before they finally removed his thyroid, despite a family history of thyroid problems and having multiple previous hospital trips for suspected heart attacks, which by itself should give the obvious conclusion that his thyroid needed to be removed.
Being in afib just for a few days can cause permanent heart damage, heart attack, and death. And even once they decided it should be done, it was another 2.5 weeks before they scheduled the surgery. I don't see how anyone can think the US medical system is any good for anybody but the obscenely wealthy.
No doctor in existence would consider that an acceptable scenario, but the profit driven investors seemingly had no problem with him dieing when they had more profitable patients to serve first.
Urgent care would not be urgent if you had to wait months. Hang out with a few elderly people who actually need to see specialists more than people like me. Over the years, I've heard plenty of stories from people I know waiting multiple months to see specialists.
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.
> 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.
Ok.
But in the reply you are responding to I specifically carved out an exception for emergency situations:
> I can only surmise these people haven't been to a non-emergency doctor since prior to 2020.
Your mom's situation was certainly an emergency.
I'm glad she was seen promptly, but her situation is very different than someone who needs to see a specialist for something that is not immediately life threatening (even if waiting could have serious long term health consequences).
Urgent care is not a replacement for a family doctor or internist who can track your health across long periods of time. That's like comparing a substitute teacher to a tutor; a sub might be able to answer your questions, but they cannot track your academic progress over time and help you tackle an extended course.
Exactly. Last time I moved to a new area, out of about 5 local family doctors, the shortest wait time for a New Patient Appointment was eight months. In the good ol' non-socialized-medicine USA. So for eight months, we had to rely on urgent care for every medical need.
30 years ago, you’d just call your GPs office and they would have told you to go to the ER. Instead your moms insurer paid $150 for an interaction that likely funneled you their medical networks local hospital and added low value.
Urgent care is a grift to replace a relationship with a doctor or practice with a lower paid, lower skilled NP. It’s more a sales funnel that anything.
I don’t think the OP is starting from WASM code; they’re starting from a language with SIMD primitives that map closely to those of WASM. There, you often have information to prove function arguments do not alias.
> 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.
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.
Isn't the high startup cost what FSRM is intended to solve?
> With the new Zen3 CPUs, Fast Short REP MOV (FSRM) is finally added to AMD’s CPU functions analog to Intel’s X86_FEATURE_FSRM. Intel had already introduced this in 2017 with the Ice Lake Client microarchitecture. But now AMD is obviously using this feature to increase the performance of REP MOVSB for short and very short operations. This improvement applies to Intel for string lengths between 1 and 128 bytes and one can assume that AMD’s implementation will look the same for compatibility reasons.
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.
I'm not sure that your comment is responsive to the original post.
FSRM is fast on Intel, even with single byte strings. AMD claims to support FSRM with recent CPUs but performs poorly on small strings, so code which Just Works on Intel has a performance regression when running on AMD.
Now here you're saying `REP MOVSB` shouldn't be used on AMD with small strings. In that case, AMD CPUs shouldn't advertise FSRM. As long as they're advertising it, it shouldn't perform worse than the alternative.
Or you leave it as is forcing AMD to fix their shit. "fast string mode" has been strongly hinted as _the_ optimal way over 30 years ago with Pentium Pro, further enforced over 10 years ago with ERMSB and FSRM 4 years ago. AMD get with the program.
rep movsb might have been fast at one point but it definitely was not for a few decades in the middle, where vector stores were the fastest way to implement memcpy. Intel decided that they should probably make it fast again and they have slowly made it competitive with the extensions you’ve mentioned. But for processors that don’t support it, using rep movsb is going to be slow and probably not something you’d want to pick unless you have weird constraints (binary size?)
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.
reply