111–120 of 180 posts
Earlier quoted context omitted.
A user-land program cannot be at fault for a kernel panic, that is the kernels fault, always.
xnu will panic if it doesn't receive periodic check-ins from userspace. For example if WindowServer hangs, then the kernel may deliberately panic so that the system reboots. See man watchdogd for (a tiny bit) more.
Earlier quoted context omitted.
It has a bit less gain on a RISC due to the code density (or lack thereof), since it requires more fetch bandwidth. Apple works around this by using a very wide front-end: https://news.ycombinator.com/item?id=25257932
x86-64 code density is more than 4 bytes / instruction.
Earlier quoted context omitted.
Not in the next 10 years. Why would they? Fabs are extremely capital-intensive and take years to get up and running, when (like Taiwan Semi) knows how to do it. Intel has shown how hard it can be to do this right. Let TSM work on production (and hopefully get more/larger fabs in the USA up and running) and getting better at packing in the transistors, and let Apple improve the design (and software).
But Apple has a lot of capital, and could win massive political brownie points for doing so, especially if they promised that some percentage of fab capacity would be sold to other American firms.
Earlier quoted context omitted.
The blog post links to the benchmark... It's repeatedly populating a 20k entry array with the results. godbolt clang compiles it to: .LBB5_2: // =>This Inner Loop Header: Depth=1 mul x13, x11, x10 umulh x14, x11, x10 eor x13, x14, x13 mul x14, x13, x12 umulh x13, x13, x12 eor x13, x13, x14 str x13, [x0, x8, lsl #3] add x8, x8, #2 // =2 cmp x8, x1 add x11, x11, x9 b.lo .LBB5_2 [1] https://github.com/lemire/Code-used-o…
Thanks for the link. Just staring at the machine code, it looks like the hottest loop for wyrng is about 10 instructions with a store in it. If the processor can do that loop in 1 cycle on average then...holy fuck. edit: I was looking at similar code generated by clang on my machine. Again, holy fuck. I don't think the story here is that 64x64=128 multiply is fast, honestly. The real story is the insane level of spec…
I wonder if order matters? That is, would mul followed by mulh be the same speed as mulh followed by mul? How about if there is an instruction between them that does not do arithmetic? (What I'm wondering here is if the processor recognizes the specific two instruction sequence, or if it something more general like mul internally producing the full 128 bits, returning the lower 64, and caching the upper 64 bits somew…
It would be fun to experiment with, for someone that has the hardware. My guess is that swapping the order will make it slower, but adding an independent instruction or two between them probably won't have a measureable effect. It would be fun to try and consistently interrupt the CPU between the two instructions as well somehow, to see if that short-circuits the optimization.
Earlier quoted context omitted.
Oh goodness I thought this was just me after searching online and finding very little, if any, discussion of the bug. The issue I had wasn't on password login prompts, but on account creation prompts (i.e. password+confirm password). I had assumed it was lastpass at first, but the freeze persisted even after removing that -- on a one-day old computer.
Feel free to report it in Feedback Assistant.
You mean to tell me that a $2000 Macbook is almost as performant as a $1000 PC? Tell me more!
That's great if you App is compute bound. "May all your Processes be compute bound." Back in the real world most of the time your Process will be io bound. I think that's the real innovation of the M1 chip.