8,867 karma · joined March 18, 2011
They stopped making the lpddr2 dram that the old SoCs used a few years back, and now most of the stock has dried up.
The Pi 4 SoC used lpddr4, and I’m pretty sure they are still making it.
That's not quite enough to prove it was AI in itself. But when combined with the fact he was unable produce the original raw grayscale video and how he deleting his linkedin... basically confirmed to be AI.
Not sure where that comes from. The original release box art [1] says it will work on any PC with 512KB of ram. So that's an 8088 running at just 4.77 MHz.
But that's far from the lowest spec port of the game. The Commodore 64 version might have been missing quite a few features (like stadiums, police/fire stations and railways), but the main city simulation loop was there in just 64KB of ram and a 1MHz 6502.
And the BBC Micro/Acorn Election port was even more impressive. Had basically all the features of the full Amiga/PC/Mac version, only missing Music/Sound/Animation. With a 2Mhz 6502 (or 1Mhz on the Election) and just 32KB of ram.
[1] https://images.launchbox-app.com/79861ce4-75ea-46dd-b46e-521...
IMO, the main reason Sony are discontinuing ps5 disc manufacturing now is so by the time they get around to launching the ps6, the move away from optical discs is old news. They know the move is unpopular and they don’t want the drama associated with the launch of their new console.
I’m less sure about what will happen to bluray movies. But this is not a good sign.
Besides, even with the automated start system, the actual spin-up time of the turntables would have been a little chaotic. I suspect they were only aiming to get the four turntables within about 100ms of each other. The decrypted signal itself could then be used for the final fine-tuning of the timings (which also included adjusting for any speed-of-light delays)
If you weren't within 20ms, the operator would only hear noise (like a radio). Once they were within ~20ms, the operator would start hearing silence and would tune the phase until all noise went away.
You don't really need exact synchronisation because like a radio, the operator could just scrub the tuning to find the silence.
The synchronised clocks meant that once the operators had locked on, it would stay locked for a long time.
[1] https://www.nsa.gov/portals/75/documents/about/cryptologic-h...
It was in development for a long time at a critical point in history. It seems to have started off as a software-first project (or possibly even software-only), then switched to hardware-first near the end of development. And not every effect was implemented in the hardware renderers.
Half-Life has a lot of grid textures that really need bilinear filtering and mipmapping to look decent, and they look even better with anisotropic filtering.
Many other games that released a little later (like Decent III) actually fully removed their software renderers before release because games needed to be hardware-only if they actually wanted to compete on visual quality.
And while hardware image decoders might be dubious, hardware video decoders are very much worth it.
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.
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.