exmadscientist

Would anyone downvoting care to explain? I'm genuinely interested in seeing anything that suggests there's either some secret breakthrough (completely plausible, but there's no evidence that I've seen hint of) making quantum computers actually useful, or an argument that they'll be usable by (say) 2050?

Because right now my attitudes are trained by things like this https://algassert.com/post/2500 that explain just why 15 was factored in that famous run of Shor's algorithm and not, say, 21; and why 21 hasn't been factored yet and isn't likely to be any time soon....

Agreed. This looks from the outside like someone read a report, got unnecessarily spooked, and now the rest of the herd is following along.

But it's also very possible that hypothetical report was genuinely concerning. We just haven't seen it or anything like it.

However I'm pretty firmly in the "quantum computing won't be doing anything useful any time soon, if ever" camp, so that definitely colors my opinions. I don't have any particular recent expertise to support that, but I did used to share an office with some serious QC people and go to their talks so... make of my words what you will.

The word "uncorrelated" is doing a lot of heavy lifting in that claim. Most DRAM error sources are pretty clearly correlated, if you're paying any attention.

FYI, it's not so much photons (gamma rays) as muons.

Muons are nasty little buggers.

We're right here! Some of us just prefer to stay out of these silly irrational debates because we know that neither of those two crazy camps will listen to a word we, or anyone else, will say. We might be wrong about that (I hope we're wrong about that!) but there sure are enough other people chattering that it's easy to sit back and let them have it out.

I don't have anything covering recent generations. Try the usual suspects, I guess (Agner Fog et al). Sorry that's not more useful, but I haven't seriously worked on x86 in over a decade, so I'm a bit out of date.

Certainly, back then the prefetchers were a lot happier when they could easily identify patterns. They are more sophisticated now, but the old tricks still work. Avoiding register-based indirection is a major help to pretty much everything. When the base register gets updated, as well as the index register, that's hard to optimize. It shows up in both memory prefetch as well as speculation past an instruction.

The other idea to keep in your head is to start thinking in SSA form. Compilers live and breath SSA, so if your fast-path code looks like SSA with a couple of phi nodes, well, it's probably going to generate like you think it will. That's why I preferred the explicit `update_j` style: it's SSA form!

in this particular case I think it's a little misguided ... only inherent difference between 8-bit and 32-bit code is the use of `movzx` versus `mov` ... generates ugly code for address calculation ... the induction heuristics didn't do their best here

OK, it seems I've been a bit confused myself. I think my final conclusion is actually just that clang is generating kind of crap code here, and this change gets good codegen out of clang. Since I was mostly looking at clang and was leaving gcc as an afterthought, I didn't pick up on this. (Obviously I'm a little rusty on my x86, I shouldn't have fallen for that!) As gcc shows, it doesn't matter much either way. But when clang is happy, its code is quite nice, so there's that.

That little address dependency chain is nastier than it looks, though, the way clang is writing it. Best done away with. There's really no reason for clang to be emitting that crud. gcc handles the addressing in a much cleaner manner whether it's byte- or dword-wide. But gcc also does need that fence when clang does not. I'm sure that's not a coincidence.

Could you explain your thought process [on placing the compiler fence]?

I ended up dumping this in kind of carelessly and noting that it worked before moving on (it was a last-minute add and I was kind of done by this point). But GCC does care where it goes, since it doesn't work if placed before. Let's try this explanation: the fence basically means "resolve all funny business with this variable before proceeding". Before the write, there's no funny business to resolve: nothing has happened to that variable. No writes, no outstanding reads (we're well into the loop at this point, in theory). So it's a fancy nop. But if it's after the write, we've now got a consequence: `next_j[i][j]` is different now. The fence forces us to resolve that now and not let it linger until the next loop iteration. Where it can be handled perfectly well, but not particularly quickly (which we do care about), and by the way that choice puts the update in the fast path. Forcing it to be dealt with before we re-enter the fast path is how we force the stupid compiler to keep it out of the fast path.

ugly code for address calculation... might affect throughput a little

What I'd actually worry most about is poisoning the prefetchers, and speculation more generally. They're very very good at handling things like "increasing stride off this base". They struggle more with things like "double indirect register access to determine next address", though there is so much compiler crud out there that they have some surprising capabilities. Basically: simple stupid loop stride is going to do well with them. Complicated four-instruction chains to generate an address that could have been `[base + 8*stride]` or whatever is just... not helping. gcc does perfectly well here. It has multiple offsets floating around, but all of those instructions to update them can update superscalar, in a single cycle. The clang chain is a four-cycle delay. And to top it all off the branch can probably fuse in the simple addressing case!

A huge part of the problem here is that you're playing with the 8-bit registers. They work, but they're like travelling the back roads: the CPU designers put all their effort into the big highway next door, and not so much into keeping the back roads clear. They're infamous for random weird stalls and such. I wouldn't be surprised at all if there's dependency chain tracking weirdness using them.

If you can change the type on `next_j` over to `unsigned` (or `size_t` or ...) then a lot of weird stuff goes away. The dependency chains in address calculation at the beginning of the loop are gone too, which seems a win. (Or I'm sure there's some other, more complicated, way to get the compiler to get rid of them.) But if the space hit from using `unsigned` is allowable, I'd expect it to be both faster and less brittle.

The processor doesn't really know what you're up to, it only sees registers. When `j` is stored in `ecx`/`rcx` and `ecx` isn't changing, it knows it's free to push ahead pretty far on speculation. If the update to `ecx` is rare, putting it behind a well-predicted-not-taken branch will make it go away, as far as the speculation engine is concerned, and let the processor go far and fast. (The rollback on mispredict can be pretty painful, but, well, that's out-of-order execution for you.) That's what we're really trying to accomplish here: stuff that single register write behind a rare branch, somehow.

Here's what that can look like: https://clang.godbolt.org/z/1ss6hsEKb

Note that I disabled unrolling because some approaches got unrolled more than others. (I saw no unrolling, 2x, and more!) Comparing them without unrolling is fairest, I think, though it's also interesting to see how far they can unroll without assistance.

I also found that clang didn't need any additional fencing (or care if it was present), but gcc did, so there's an `asm volatile` style fence, which I think is a lot more clear than the other tricks. (Your mileage may vary; people who've done a lot of low-level work won't blink at these, while others will just stare agape. Perhaps also not blinking, but for opposite reasons!)

(Mind you, I didn't actually run any of this, so, well, you get what you pay for.)

Part of my point is that making a print head driver is, in general, harder than making a laser imaging head. A lot harder.

Of course the details of what specific parts are purchaseable on the open market can and will change this calculus a lot.

I talked a bit about this years ago: https://news.ycombinator.com/item?id=37007815

TL;DR: I'm surprised this isn't a laser printer, as those are actually quite a bit easier to design and manufacture, especially if you can use a cheap, older, commonly available, remanufacturable toner cartridge.

Exactly!

Quantum mechanics is an excellent example here. It is not "defeatist" to accept that we don't know where the electron in the hydrogen atom actually is. Or to accept that if we really, really wanted to figure out where it is, we can only do so by disturbing it enough that its position is probably no longer a useful thing to know.

These are fundamental features of the world (at least according to our best theories of Nature), and it is only by accepting them and the uncertainties inherent to them that we are able to make progress using those theories. Among the consequences is that thinking about "the position of the electron" is not so useful; we instead need to leave position behind and start thinking using a new thing, "the orbital of the electron". This is a major conceptual change, and internalizing it can be Very Difficult for some people.

But the world does not care. It and its complexity owes nothing to anyone. It is us who must adapt to the world, in all its fuzziness and incompleteness. Nature will break the rigid, but if you bend, you can soar.

optimistic that modern reactor designs and reprocessing technologies can overcome these issues

The obstacles aren't technical. They never really have been. The obstacles are human: political, bureaucratic, and corporate. It's not about "can we build a safe nuclear plant?". It's about "do you trust these bozos to build a safe nuclear plant?", remembering that if said bozos screw up, the damage is basically irreversible.

That's the problem.

LILCO Shoreham, for example, famously couldn't build backup gernerators that worked, until they exploded and had to be completely redesigned and replaced. Does that inspire confidence in the rest of their plant?

And following on from that, this has all the hallmarks of a successful appeal for unreasonable sentences. However, it's going to go to the Fifth Circuit, who are, ah, not known for their friendliness to criminal defendants.

There is always one "The Diagnosis".

No, that is not true at all.

This is a kind of thinking a lot of programmers fall prey to. The real world, outside of code, is a very fuzzy and inherently analog place. There is very rarely one in any complex system having a complex problem needing a complex solution. At some point even the definition of diagnosis gets fuzzy.

The best demonstration of this in medicine is probably the DSM-5. What, really, is the difference between Narcissistic Personality Disorder and Borderline Personality Disorder and Generalized Anxiety Disorder? Can they overlap? (Yes.) How do you treat them? (It's not easy.) What about depression: how do you tell if someone has Major Depressive Disorder or Bipolar Depression? (Again: not easy.) In some circumstances the only way to tell the difference between the two is what drugs work: if antidepressants help, it's Major Depression; if mood stabilizers help, it's Bipolar Depression. It's kind of odd to define a One True Diagnosis by "well we fixed it this way, so it must have been that", with no other way to do it, isn't it? (What if both work? What if one works for a while, then the other works? What if treatment with antidepressants induces bipolar (hypo)mania? All of those happen!)

And that's just a few examples.

Somehow I only managed to end up on one of these gorgeous birds once. In seat 64K, NRT-DTW (or was it NRT-MSP?). The main cabin is... nothing to write home about. I was in no hurry to book another 744 leg. Upper deck, perhaps a different story.

Great seat number though.

Not really. They're trying to split up potential causes of failure between:

1. "Funding" meaning: We knew what we had to do but didn't have enough money to do it; if we had, this path would have worked (though why it says "TAM" here I don't quite get);

2. "Technical" meaning: We knew what we wanted to do but couldn't quite make it work; if we had, this path would have worked

3. "Uptake"/"Regulatory" (perhaps not the most natural pairing, though I see why they're together) meaning "We couldn't get people to actually do it"/"The authorities wouldn't let us do it"; if we had, this path would have worked

But that is missing a much different type of failure:

4. "Strategy" meaning "This path does not actually lead to our goal"

It's easy to see why in marketing material they'd leave out that last one. They want to build confidence! But for a moonshot like this, especially a biological one, it's kind of silly to think that this is definitely the best way to achieve this goal. I am, personally, quite skeptical; this reads like a mashup of SV and germophobes (with apologies to, well, both of those groups). I hope it works! And I won't stand in its way. But I won't be betting my own money on it. Probably we will learn something interesting no matter what.

More generally, this is a distinction that a lot of people miss (often intentionally, if PR/marketing is involved): strategy and tactics are distinct and they can succeed or fail independently. The best execution (tactics) here will not help if the plan (strategy) is flawed. And there are numerous other examples from research, business, and of course everyone's favorite hobby subject, war, of what happens when your tactics are good but your strategy isn't, or vice versa, or any of the other combinations. And, of course, making decisions about when to pivot (switch strategies) and all those other fun topics.

Right -- if you're invested in the NASDAQ 100 (most people aren't, directly or indirectly), get angry. Or get out, if you can and it's not too late.

Everyone else has dodged this bullet. I'm surprised, pleasantly, that S&P et al actually made the right choice here.

I will never understand why so many otherwise smart people keep trying to make nuclear happen in their minds.

I don't really get this either. I've come to think that it comes down to two pieces. The easy piece is that some people don't seem to realize just how good renewable power sources have gotten in the last 10-20 years. Nuclear has simply been outcompeted in so many ways. But this happened pretty quickly, so not everyone has gotten the message.

The other one is more subtle. For decades there were a lot of bad attacks on nuclear as a technology. (And a few good criticisms, but for some reason those never seem to get the attention, even though they should -- they're pretty strong arguments!) There's a certain type of person who loves to debunk these bad arguments, and there's plenty of that type of person around here. And that can get you emotionally invested into the thing you've been defending (perhaps rightfully: they were crappy arguments against it), and might keep you promoting it after its natural time has passed.

(To be clear: I don't think nuclear plants are worthless, and I think keeping the ones we've got operating smoothly as base load stations is probably an excellent idea. But I don't think it makes a whole lot of sense to be building more of them these days.)

Or, to say a little more explicitly what you're getting at: when you take a logarithm of some quantity, log x, x absolutely must be unitless. There's no way whatsoever to take a logarithm of something with a unit attached. (This is an important and useful dimensional analysis check in formulas and long calculations!)

So what do you do in practice? You have to normalize: you don't calculate log x, but instead log x/U for some scaling unit U. It's typical for U to be something like 1 mV or 1 W in electrical engineering, for example. This is completely legitimate, but it does mean that the thing that comes out needs a corresponding unit attached to it: dBmV, dBW, et cetera.

And it's really kind of important to be careful about that.

Robots that cannot share sidewalks with humans, including humans in wheelchairs, should be banned from sidewalks. Full stop. End of discussion. They can use the streets proper if they want to.

I'm sure there is some way to formalize that using ADA sidewalk requirements or something similar.

The article is making the case that this is not healthy for society. It is the kind of thing that's fine if 5/100 do it, seriously worrying if 50/100 do, and basically fatal to civilized society if 99/100 people do.

And when I go to the park and have a run, of the 100 people I might see there and on the way, we're closer to 50/100 than 5 or 99. So I think we have a problem.

I think that's an unusual scenario, and I'd ask you to consider that that's probably not the argument I was making.

Most of the dozens and dozens of people I see in daily life sealed away in their earbud pockets do not appear in any way to need to do that. I am certainly not seeing the full picture of every single person's life, but I do not think that every last one of them is incapable of meaningfully engaging with the world.

Being able to do it in the middle of a riot is, absolutely, a hard-earned skill.

But it is, like so many of these things, a skill. You have to practice it.

I think that putting earbuds in and checking out of the world around you is a really awful thing to do as your default in life. As a "sometimes" thing it's fine, even healthy. There's a lot of talk of public transit in this thread. If people do it during riding transit, and not really at other times, I'm fine with that. But so many people have their earbuds in before they leave their front door, every day, every week, and they don't come back out.

And I think that's really, really unhealthy, for them and for the rest of us.

Talking to strangers is a skill. You can practice it! I've made a point of trying to practice, albeit halfheartedly, and even though it's difficult for me, because I like it when other people try to talk to me.

Earbuds stop this practice dead in its tracks. You can't deny that.

The actual "make it go bang" bit here isn't the most potent. (I think I have capacitors here which wouldn't care in the least about this, despite their datasheet ratings.)

If you need to take it to the next level, consider something based on a xenon photoflash driver. These aren't as common as they used to be, but they're still not hard to make. I had to make one of these a while back and ended up using one of those $5 LTC chips but that was appropriate for the situation; there are certainly other ways to do it. This will basically charge a 400V capacitor up for you, which you can then dump into the 5V part. High-quality 5V capacitors will handle small spikes of this. But using a big 400V capacitor will make a big spike, which is not kind to the other capacitor. (I must confess I didn't try blowing up a lot of things on the one I made, but it was medical test gear, not technically a capacitor-blower-uper, and I was on deadline anyway. I also had other, significantly more destructive, equipment available to me should that be the goal.)

The ads showed up when the launcher got a major redesign, and the Google TV (or whatever they call it this week) launcher is a Google product. I seem to remember that nVidia delayed shipping the new enshittified version for quite a long time, so I'm pretty confident Google gets the blame here.

My point, which matches what you've written out in more detail, is that there's supposed to be stuff (resistors) in the cable, stuff which is often not there. There are plenty of these abhorrent cables in the wild. And when you come across one, things get weird, because some sources and sinks deviate from the standard in ways that make them work with these bad cables. Others don't do that. (I believe there were a lot more abhorrent cables in the early days, and thus began the chain of accommodation....)

So unless your cable is known-good, if you are having trouble, trying a different cable should be the first thing you do. It really does often get things working.

Contrarily, if you have identified a naughty cable, it should be immediately widlarized.

The 4.7k "default pullup" is an old-school 5V TTL thing. It works really well for TTL inputs. But CMOS inputs don't really care very much, especially if they aren't toggling or if there's a bit of hysteresis on the input stage (which there often, but not always, is). There seem to be 10k resistors in every design so CMOS pullups often end up at 10k. If power savings are a concern, especially if you need a tie-off more so than a pull resistor, 10k-100k is a perfectly valid range, and I've even used 1M in extreme circumstances.

Usually 5k is a little too weak for I²C. Rule of thumb is that you want to be around 1mA, so for a 3.3V system you start at 3.3k. Generally 1.8k to 3.3k ends up being a pretty common range. More current is usually better than less current, so even at 5V where 4.7k might be OK (if you're even at 5V Vdd these days), going stronger is often a good idea. If power savings is a concern, or if timing's somehow important (did you find another touchy badly behaved I²C device? say it isn't so!) then it might be time to break out the active pullup structures (mostly current source type things). Once this is done and tested it tends to get fossilized, for good reason, so this one won't usually get swept up in a standard-effort cost reduction pass.

The controlling standard is usually 62368, and the target is usually being a "Limited Power Source", which is 60V or less, and 100 VA max.

Right. That phrase "standards-compliant" in the above comments is doing a lot of heavy lifting.

A lot of devices are not actually standards-compliant. Some are close. (This may actually be worse.)

My experience has been that if the source and sink are broken, they are often hilariously badly broken and it is pretty easy to figure out that they are the problem, if not quite exactly what they've done wrong. But if things are flaky and weird and don't really make sense, it's probably the cable. Try a known-really-seriously-actually-standards-compliantly-good cable and many problems go away, even if the source and sink aren't perfect.

(Many sources and sinks aren't standards-compliant because, even though they easily could be, they're trying to work around the other end not being standards-compliant itself, because that's what you've got to do to sell a product. So they're close but not quite there. This is not always ideal.)