yuliyp

Perhaps those were different iterations of the technique over time. Start with marking cards to identify face cards, then move on to x-ray table.

That's not the problem. The problem is that you're adding a data dependency on the CPU loading the first byte. The branch-based one just "predicts" the number of bytes in the codepoint and can keep executing code past that. In data that's ASCII, relying on the branch predictor to just guess "0" repeatedly turns out to be much faster as you can effectively be processing multiple characters simultaneously.

No, that's not the stance for electrical utilities (at least in most developed countries, including the US): the vast majority of weather events cause localized outages (the grid as a whole has redundancies built in; distribution to (residential and some industrial) does not. It expects failures of some power plants, transmission lines, etc. and can adapt with reserve power, or, in very rare cases by partial degradation (i.e. rolling blackouts). It doesn't go down fully.

Oh, interesting. I guess `time` is only reporting the usr/sys time of the main process rather than the child workers when using PARTITION_COUNT higher than 1?

You're measuring a cached compile in the subsequent runs. The deps.compile probably did some native compilation in the dep folder directly rather in _build.

They pushed it out while the vehicle was parked. The bug seemed to not break the vehicle immediately, but after some time driving.

I don't understand how this is losing their mind. Toggling this setting is expensive on the backend: opting in means "go and rescan all the photos". opting out means "delete all the scanned information for this user". As a user just make up your mind and set the setting. They let you opt in, they ley you opt out, they just don't want to let you trigger tons of work every minute.

> The New Deal delayed the recovery from the Depression to 10 years or so.

This is categorically wrong: the WW2 GDP boom started in 1939, by which point we'd already been out of the great depression (1936 was the first year that Real GDP was above the previous peak of 1929). Regardless, that point is only 6 years after the New Deal took effect, meaning a delay of 10 years would require reversing the flow of time.

Source: https://alfred.stlouisfed.org/series?seid=GDPCA (I can't figure out how to hotlink to a specific time range so you'll have to plug it in yourself).

Sure they do. Amazon built AWS well after it was big. Apple built the iPhone. Microsoft built VS Code. just to name a few examples.

I think that simulation claim that pick-2 can send 2.5x as much traffic to most loaded vs least loaded is a bit misleading: if the load metric is completely random then that might happen. The more correlation to load the better. Also, rather than looking at the ratio of most loaded to least loaded, it might be better to look at the ratio of most loaded to average: that is, how much extra work did we send to a poor server. In that, pick-2 has an absolute cap of 2xing the load on a server.

Sorry, I guess I meant something like motion planning etc. rather than another transformer.

I can't help but feel like some sort of hybrid approach: use GPT5 for the strategy, then a more direct ML model for actually executing the strategy might work better than trying to use reasoning directly for input control, would work better than trying to reason your way through driving.

In Hack, collection objects were one of the biggest early mistakes that the took a huge amount of effort to undo. It turns out that the copy-on-write semantics of PHP array were extremely important for performance and good APIs. Being able to pass arrays to things without fear of mutation allowed for tons of optimizations and not needing to copy things just in case. This is why Hack switched to using `dict`, `vec`, and `keyset` rather than collection objects.

More generally, it's weird to see a whole blog post about generics for PHP not even mentioning Hack's generics designs. A lot of thought and iteration went into this like 5-10 years ago.

See https://docs.hhvm.com/hack/arrays-and-collections/object-col... and https://docs.hhvm.com/hack/arrays-and-collections/vec-keyset...

There are a few reasons:

1. Random is the one algorithm that can't be fooled. So even if there's something against number of connections as a load metric, not using that metric alone dampens the problems.

2. There is a lag between selection and actually incrementing the load metric for the next request, meaning that just using the load metric alone is prone to oscillation

3. A machine that's broken (immediately errors all requests) can capture almost all requests, while 2-random means its damage is limited to 2x its weight fraction

4. For requests which are a mix of CPU and IO work, reducing convoying (i.e. many requests in similar phases) is good for reducing CPU scheduling delay. You want some requests to be in CPU-heavy phases while others are in IO-heavy phases; not bunched.

They're not getting anything out of the small bump in resale prices well after they wrote and sold those books.

I guess I'd thought of head-of-line-blocking as the delay from a slow request stalling subsequent ones beyond the throughput limits of the system: i.e. a slow-to-parse request causes other cheap requests to wait.

I don't think this is head-of-line blocking. That is, it's not like a single slow request causes starvation of other requests. The IO thread for the connection is grabbing and dispatching data to workers as fast as it can. All the requests are uniform, so it's not like one request would be bigger/harder to handle for that thread.

If you have a single TCP connection, all the data flows through that connection, ultimately serializing at least some of the processing. Given that the workers are just responding with OK, no matter how many CPU cores you give to that you're still bound by the throughput of the IO thread (well by the minimum of the client and server IO thread). If you want more than 1 IO thread to share the load, you need more than one TCP connection.

Right, but over 20 million people do. And those are generally less wealthy people for whom price increases would be quite a hardship.

> you should be interpreting them at time of reading the log

This reminds me of a fun interaction in browser devtools: you can log a complex struct to the console. The browser does not copy the entire nested structure when you do so immediately, meaning that if someone mutates that struct after it was logged, the value you see depends on when you expanded the nested struct.

Think "hardware groups with next generation experimental hardware". Facebook runs their own data centers, including designing their own servers. How do you verify that the servers actually perform well? One natural choice was to put them to work as web servers. Given its size, there was a lot of tooling there to be able to measure very precisely what the throughput of a web server was, so things like "How many of these new servers should we order" could be answered, in addition to the "does the rack catch fire" questions.

One example of a source of tension that such standards were trying to deal with here was in a group trying to run web servers on machines with SSDs that were way too small: obviously for the bean counter saving a bunch of money on the SSDs was nice, but for the team trying to make sure the disk can fit all the code and logs on it, it was less nice.

We know that they restarted a few seconds later a few seconds apart from each other, and shut off a second part from each other.

It's extremely unlikely for a pilot to decide to react by shutting both switches off, then turning them on within seconds (this is not a failure mode they'd have expected, deciding to shut the engine off a couple hundred feet in the air would be... a fairly reckless decision).

That leaves both switches spontaneously turning off, then back on, a couple seconds after takeoff, which is a failure mode that's never been seen before once let alone twice. Also the pilots didn't make a statement about an incongruity between the report from the plane's systems about the switch being off vs the physical position, which they very likely would have in such a situation.

I think it's reasonable to rule that theory out.

It's not dehumanizing them. It's depiloting them. Not everyone should be a commercial airline pilot, no matter how much they may want to be one.

RGB is a color scale of three fractions. Those fractions can each be measured with any number of bits (1 bit, 4 bits, and 8 bits are choices that have seen some use).

Even with a high percentage of time busy, there's still a wide delta between peak and average power draw (basically every EV slows down its charging the higher the charge percentage). Still lots of opportunity for charge/discharge to reduce the peak grid demand.

To contrast, I found that tidbit about Einstein helpful, as it took my memory more promptly to when I studied it in physics classes.

I enjoyed the post more as a story more than as a report.

If you're sorting data on a command line, you probably have some matter of control over how it's generated. So just fully-expand it and then text sorting just works. Pretty simple?

Did the author do any analysis of the effectiveness of their tool on something beyond multiplication? Did they look to see if it caught any bugs in any codebases? What's the false positive rate? False negative?

As is it's neat that they wrote some code to generate some prompts for an LLM but there's no idea if it actually works.

The ADS-B transponder tells other planes where you are. It doesn't tell you where the other planes are. Turning it off when there are civilian planes doesn't improve your ability to aviate. it just hurts the situational awareness of the civilian planes who aren't supposed to be learning how to fight.

> however, you would immediately have a civil case against the person and/or their representative for their false claim.

Look how well that's worked against DMCA and Youtube copyright strike abuse. In the case that the posts that are being taken down are not commercial, being able to prove damages means that the effectiveness of such a deterrent are minimal. The act could have put in some sort of disincentive against fraudulent reports, or even provided for a way to find the reason your stuff was taken down, but notably does not do so.