phire

Media encoding is actually an FPU workload, and a pretty brutal one at that.

Media encoding might not use much floating point arithmetic, but it does use massive amounts of packed integer SIMD. And all SIMD instructions (both integer and floating) execute on the shared FPU, not the integer unit. It's only scalar integer instructions that execute on the integer unit.

Which leads me to believe that Bulldozer's shared FPU is not a bottleneck at all. Most evidence seems to point to the shared frontend being the primary bottleneck (which is why steamroller puts some effort into duplicating the instruction decoding, for some pretty large IPC wins)

Steamroller did see 30% IPC improvements over Bulldozer (all the design work would have been done before they switched to Zen), but AMD canceled the full FX version, and only ever shipped the APU version of Steamroller (with only 2 modules, aka 4 threads).

If they had shipped a Steamroller FX cpu, the generational improvements would have looked similar to many of the generational improvements that Zen received... but didn't really matter as Bulldozer started so far behind.

I actually remember media speculating that Sun didn’t want to take the next step and actually file a lawsuit, because they didn’t have enough resources to go up against Google in court.

Then Oracle bought Sun, and suddenly the unproductive negotiations transformed into a lawsuit.

While it was difficult to make it follow instructions, GPT-2 was still reasonably good at generating SEO-spam websites, and reasonably easy to make it do so. AI slop was a very obvious usecase for LLMs as capable as GPT-2, and we are talking about an era were everyone was already concerned about the way "fake news" on social media was being used to manipulate people. Perhaps even more concerned than we are today.

But all evidence suggests OpenAI also had strong ulterior motives. They were busy readying the API groundwork for monetising it, and wanted to delay any competition by as much as possible.

Otherwise most modern CPUs would be labeled as either 256-bit or 512-bit.

These days we generally label CPUs based on the width of the general purpose registers (though, it gets messy with things like the 68000). I personally suspect we won't ever see GPRs wider than 64 bits.

They aborted the go-around attempt because they were literally at the end of the runway; Probably because they thought it would be "safer" to run off the end without the engines rapidly reaching full thrust.

If so, it’s tight… but i feel like they should have made it if they had stuck to that plan. They commanded full power 15 seconds before the crash, and were pretty close to (if not slightly above) their stall speed (depends on load). I suspect they just needed another 10-20 knots and enough energy to climb.

And for all we know, it might be officially supported in their internal builds of Visual Studio.

The "how" it does dual-issue is not documented at all, so I'm speculating. There is no smoking gun saying "register renaming". While it would be possible to implement its known capabilities without any kind of renaming, it would be so much simpler to implement it with register renaming.

The thing is.. once your forwarding network and hazard detection gets complicated enough, it basically becomes a janky form of register renaming. So it's cleaner to just implement proper register renaming, and actually saves hardware.

While the A53 might issue in-order, the pipelines have different lengths and they don't finish executing in order.

I find the fact the A53 can speculate a few instructions past a cache miss to be very interesting, along with the fact it can issue two writes to the same logical register in a single cycle.

Also, the smoking gun is that the A510 (same lineage as the A53) is documented to do out-of-order issue (see chipsandcheese again [1]), so it must be doing register renaming. ARM still insist on still calling it an in-order core because it's OoO is so much more limited to modern OoO cores, but it's more OoO than early PowerPC designs (including the G3) that everyone is happy applying the OoO label to.

[0] https://chipsandcheese.com/p/arms-cortex-a53-tiny-but-import... [1] https://chipsandcheese.com/p/arms-cortex-a510-two-kids-in-a-...

And while courts might have ruled that a CAPTCHA might count as a "technological measure" they haven't gotten as far as ruling them as "effective" yet.

But in general yes. The protection scheme doesn't need to be well designed or free of design flaws to count as "effective". But from what I can tell, it does need to be a valid attempt at some cryptographic scheme requiring a secret known only to the copyright holder.

[0] https://law.justia.com/cases/federal/appellate-courts/F3/387...

But the original question was asking why disabling data prefetching to a memory region didn't automatically disable instruction prefetching at the same time.

And the answer is that speculative execution is a completely different mechanism that I'm not even sure can be disabled, at least not per memory region.

I really hope not. My understanding is that to be "effective" it needs to at least be a form of encryption with a secret key. At least, I'm not aware of any case law that allowed anything less than that.

IMO, "dummy notes" are nothing more than a form of obfuscation. If it's obvious how to filter them out, then I don't think it comes close to meeting the bare minimum of what might count as an "effective technical measure".

Of course, who knows what way the courts will rule if it ever reached that far.

It's simply speculative execution. Which doesn't look any different to regular execution. The fetcher has no idea that its predicted branch is about to invalidated and flushed, otherwise it would never have issued that fetch.

Actually, on a modern OoO core, [0] it's very rare for the instruction fetcher to not be doing speculative fetches. Even when it's not predicting a branch, the fact that it has "predicted" the lack of a branch is speculative in itself. It assumes it didn't fetch a branch in the last cycle, but it can't be sure until after instruction decoding, which takes at least 2 cycles (more on larger L1i caches).

About the only time the instruction fetcher is not doing speculative fetching is for a single cycle after each miss-predicted branch.

[0] Or even something technically in-order, like the Cortex A53 cores here. They might issue in-order, but because of how they implement dual issue, they look somewhat close to a simple OoO core... I suspect they actually do register renaming. And (most importantly) importantly they have a branch predictor.

By definition, a ZST hold no runtime data. It does hold some compile-time data based on its existence, but after compiling, that has been type erased away.

Since a ZST holds zero bits of state, there can only be one valid instance of it. You can't have multiple different versions of the same ZST representing different things.

So if you have one, you automatically know it's going to be equal to all other instances of the same ZST type. And not equal to any other ZSTs. There is no point doing a pointer comparison, as that gives you no extra information, type ownership is enough.

Rust also has the complication that function pointers are not guaranteed to have an unique identity; If multiple functions compile to the same code, the compiler is allowed de-duplicate them.

The documentation [0] also warns it's also possible for the compiler to create multiple versions of the same function. And while I've absolutely seen the compiler to create multiple optimised versions of functions in disassembled code (partial inlining based on the caller), I'm not sure it's possible to get pointers to more than one version.

[0] https://doc.rust-lang.org/std/ptr/fn.fn_addr_eq.html

Plus, it's not the worst idea to exercise your "whoops we leaked our secrets" procedures. You do have procedures, right?

But I'm a little worried that solo developers might follow this device. And then not notice for weeks or months, losing large amounts of git history in the best case; Or potentially massive amounts of actual work if their original development folder is gone.

But now I think about it, the metal layers (especially traces carrying power) are probably think enough, and different enough to show up. And even just power distribution is enough for the shape of the cores to be visible.

The pilots took exactly enough fuel to reach their destination. They didn't have enough fuel to divert to an alternative airport. They didn't even have the mandatory 30min of reserve fuel. They did not account for a minor holding pattern just before landing (ironically, because another plane had a fuel leak).

The crew failed to declare a fuel emergency, and crashed 18km from the airport. They had only been in the hold for 10 min when their engines ran out.. they were very short of fuel, the pilots knew they were short. They should have diverted (or declared a fuel emergency) almost an hour earlier, but they didn't want anyone to know how close they were cutting it.

There aren't that many existing flight routes that will fit into the 125 mile range (though the existence of this plane might change that), so I suspect we will see most of these planes go into service on slightly longer routes. So they will probably still need one cycle per flight.

Though... The video isn't quite clear if the 125 miles is what they can fly without starting the turbines or if it's what they can fly without needing the turbines ready to act as an emergency reserve. I actually suspect it's the later and this aircraft can make it to 200+ miles without starting the turbines.

Where I live, there aren't that many 125 mile flights, but there are a lot of 200 mile fights.

I also suspect the turbines are sized so that only need to start one of the two turbines on most flights, which would extend lifetime a lot. Ideally the turbines would be sized so that one is enough for cruising, and with two you can actually charge the batteries after a go-around (enough to enable a second and third go-around)

But still very serious. 9 simultaneous fuel emergencies could have easily overwhelmed ATC and snowballed to worse issues.

Something lead 10 different aircraft to make the exact same mistake and find themselves without enough fuel for a safe diversion. There will be recommendations to try and prevent it from happening again.

You make it sound like it is acceptable for a badly planned flight to have a fuel emergency. It is not.

If there is a fuel emergency (or the plane lands with less than 30min of fuel) there will be an incident investigation that treats the situation as serious as if the plane had crashed. If the investigation discovers it was nothing more than bad planning, (at minimum) the planning procedures will be changed to ensure it never happens again.

I somewhat doubt that. Part of the advantage of the design is that the generators don't need to be sized as big enough to power take off, climb and a potential go-around on landing. They only need to be sized as big enough for cruising.

So powering them up during critical phases wouldn't help with safety. If anything, normal operating procedures might actually require shutting them down during critical phases.

What this does mean is that the batteries need to be reasonably full when it comes into land, possibly as high as 50%. And most go arounds will require immediately powering up the generators, so it probably needs to be fuelled for all but the shortest flights.

Looks like the most important step towards tier two is mostly about proving the CI infrastructure is reliable (which takes time at tier 3), and have at least two core developers committed to fixing any issues (within 24 hours)

It’s very rare that the actual performance benefits of rust implementations come from rust itself (though it does often push you to slightly better patterns). They usually come from the fact that rust implementations are usually a second (or 3rd, or 4th) iteration of the design, and the lessons learned help performance.

The other benefit of rust is that the stronger type system makes it easier to iterate and optimise without bugs creeping in. But once optimisations are implemented in rust, there isn’t that much pain to porting them back to c++, as long as someone cares enough to do so.

Apple is not some magic solution to the question of on-device privacy. But compared to Android, the improvement is night and day.

What that part of the GPL does absolutely forbid is stripping out the comments from the source code, or only shipping generated source files (but not the code which generated it). And arguably, git history is much of the same thing as comments. Especially when we have IDEs that can be configured to give us easy access to blame to help us understand the code.

The fact that commit history is not inline with the source code (or even stored as human readable files) makes it a little harder to see/argue that git history could be considered to be part of the source code, and I do wonder where this argument stops? Should the contents of bug trackers and PRs be considered to be part of the source code? What about design documents?

For the first half, custom ROMs were a massive boost to the experience, but I never really bothered after 2018; You had to install so much of google's stuff to get anywhere near proper experience that it just wasn't worth it, and even then many apps were starting to throw a fit when they detected a rooted device.

And at the same time, the stock android experience from most vendors was now good enough. I didn't even check custom ROM compatibly for my last Android two purchases (both Samsung). But it was nice to have the option of rooting and maybe finding/making a custom ROM Samsung removed that in their last update to One UI :(

But the other reason is that most of Android’s openness is quickly disappearing, so my main argument against iPhone is gone. And on the topic of privacy, I actually trust Apple way more than I trust the company that makes most of their revenue via advertising.

Interesting choice of cropping for that quote.

If you had included the previous word, it would be blindly obvious that “on a medium“ is only talking about the transport layer, not the format of the data. So it would exclude distributing source code on tape, or even optical discs, as nobody uses those anymore. About the only medium used for source code distribution these days is “the internet”

You could potentially stretch this to excluding google drive, though google will argue that the medium is http, not google drive; But you can’t stretch this to requiring it be formatted as git.

And even if you did manage to successfully argue that, google would just ship it as one (tagged) commit per release. The history would still be missing.