phire

35 ms·

511.
by phire 2y ago
But such benchmarks don't tell you anything at all about general ARM vs RISC-V performance. Those benchmarks would only tell you about those exact two cores, Cortex-M33 vs Hazard3. There are many other ARM and RISC-V implementations th
512.
by phire 2y ago
Do you have any protection against power/clock glitching attacks?
513.
by phire 2y ago
Hard to tell. If you ignore the FPU (I think it can be power gated off) the two cores should be roughly the same size and power consumption. Dual issue sounds like it would add a bunch of complexity, but ARM describe it as "limited&q
514.
by phire 2y ago
I really hope people don't do this. Or at least not try to sell it as ARM vs RISC-V tests. Because what you are really testing is the Cortex-M33 vs the Hazard 3, and they aren't equivalent. They might both be 3 stage in-order RISC
515.
by phire 2y ago
Or even just changing the order of instructions whenever there are no dependencies.
516.
by phire 2y ago
It might be an old design, but it's not outdated. There hasn't been any major innovation in CPU design for this power/performance/feature/area target, so the Cortex-M3 is still a valid choice if you don't need&
517.
by phire 2y ago
I suspect the head flying just above the surface has something to do with it. A bar would need to be held at a fixed height above the surface. The flying head dynamically adjusts to both distortions across the surface, and temporal variatio
518.
by phire 2y ago
Yep. It uses the branch predictor to slice up the instruction stream and feed it to multiple instruction decoders. Because the variable length nature of x86 instructions makes it hard to implement extremely wide instruction decoders. To rea
519.
by phire 2y ago
I didn't even notice that advantage. I was just thinking about how it minimised each branch target entry to about 16 bits. I suspect Apple are also using it as a way predictor. If the BTB points directly to the correct cacheline and ea
520.
by phire 2y ago
It's a sub-optimal strategy. A modern TAGE branch predictor is correct well over 99% of the time. So those extra instructions for the other side of the branch are almost always discarded. Worse, the frontend is fetching dozens of branc
521.
by phire 2y ago
> It seems like the lookahead past n+1 would make cache evictions much more likely, so maybe I'm missing something here. The frontend is already predicting dozens of branches ahead of what the backend can actually confirm. Looking
522.
by phire 2y ago
The thing is, "incorrect" implies the existence of a static "correct". Which I interpret as a static spec which a microcode bug violated and could be fixed back to that static spec with a simple microcode update. I do fi
523.
by phire 2y ago
It's way more extreme than that. For any named product (such as Raptor Lake) intel only make 1-3 unique silicon dies. Any product in the Alder Lake only had two dies, 8P+8E and 6P+0E [1]. Every single SKU comes from those two dies, i
524.
by phire 2y ago
I suspect it's for one of the low power modes. Keep in mind that the L2 cache is the last level cache for the E cores, and is shared by the entire cluster of four E cores. (One of the two clusters connects to the ring bus and shares th
525.
by phire 2y ago
It's complicated. On Raptor lake, there are a few integrated voltage regulators to which provide new voltages for specialised uses (like the E core's L2 cache, parts of DDR memory IO, PCI-E IO), but the current draw on those regul
526.
by phire 2y ago
I find it hard to believe that it actually is a microcode issue. Mostly because Intel has way too much motivation to pass it off as a microcode issue, as they can fix a microcode issue for free, by pushing out a patch. If it's an actua
527.
by phire 2y ago
Probably not. R8 is 0x9c in that example, which is somewhat typical for null+offset, but in the twitter thread it's 0xffff9c8e0000008a. So the actual bug is further back. It's not a null pointer dereference, but it somehow results
528.
by phire 2y ago
I can think of a bunch of different answers: This wasn't a code update, just a configuration update. Maybe they don't put config update though QA at all, assuming they are safe. It's possible that QA is different enough from
529.
by phire 2y ago
Sure, it's certainly possible. Though, I prefer to give people benefit of doubt for this type of thing. IMO, the level of incompetence to parse a binary file before checking the signature is significantly higher (or at least different)
530.
by phire 2y ago
The update files are almost certainly signed. Even if the HTTPS channel is compromised with a man-in-the-middle attack, the attacker shouldn't be able to craft a valid update, unless they also compromised CrowdStrke's keys. Howeve
531.
by phire 2y ago
No. To trigger the crash, you need to write a bad file into C:\Windows\System32\drivers\CrowdStrike\ You need Administrator permissions to write a file there, which means you already have code execution permissions, and don't need an e
532.
by phire 2y ago
EFLAGS is actually put in the same renaming register as the result, so you get renaming for free. The renaming registers in the Intel Pentium Pro and Pentium II are actually over 80 bits wide. They need to hold a full 80bit float, or 64bit
533.
by phire 2y ago
The other thing I noticed while playing around; Performance absolutely falls off a cliff if your hot loop starts missing in the L1i cache. This blog post [1] from CloudFlare has a few interesting hints about the M1's branch predictor.
534.
by phire 2y ago
too late to edit Turns out that M1 can track the history of indirect branches just fine, but it takes 3 cycles for a correct prediction. With threaded jumps, the M1 gets a slightly higher hit rate for the initial 1 cycle prediction. http
535.
by phire 2y ago
Ok, I spent quite a bit of time looking at performance counters, trying to understand what the M1's branch predictor was doing. The branch predictor is really accurate with a common dispatcher, it predicts those indirect branches corre
536.
by phire 2y ago
Pretty sure it's Haswell and Zen 2. They both implement IT-TAGE based branch predictors. I just assumed the M1 branch predictor would also be in the same class, but I guess not. In another comment ( https://news.ycombinator.c
537.
by phire 2y ago
> The dispatch loop takes a single indirect branch to the opcode-specific implementation. This means that the branch will be nigh unpredictable! Modern branch predictors can actually predict indirect branches with multiple destinations
538.
by phire 2y ago
Modern Out-of-order CPUs (like the M1), they can't see branches until far too late. The M1's frontend at least 24 instruction past the unconditional branch before the early possible moment it can even see it. So the branch predict
539.
by phire 2y ago
> It also turns out that Windows 3.1 (maybe even Windows 3.0 if memory serves) had a bitmap-style background pattern feature that included a pattern composition tool. The very first version of MacOS had a pattern editor in 1984. Mac Sy
540.
by phire 2y ago
Because it can't actually see that return instruction until way too late. Apple M1 CPU here loads and decodes 8 instructions per cycle, and the instruction cache access, plus the decoding takes multiple cycles. I don't know exactl

More ›