Stories
Slash Boxes
Comments

SoylentNews is people

SoylentNews is powered by your submissions, so send in your scoop. Only 19 submissions in the queue.

Why is Apple’s M1 Chip So Fast?

posted by Fnord666 on Wednesday December 02 2020, @02:28PM   Printer-friendly
from the all-the-chips dept.

NPC-131072 writes:

A medium article

On Youtube I watched a Mac user who had bought an iMac last year. It was maxed out with 40 GB of RAM costing him about $4000. He watched in disbelief how his hyper expensive iMac was being demolished by his new M1 Mac Mini, which he had paid a measly $700 for.

In real world test after test, the M1 Macs are not merely inching past top of the line Intel Macs, they are destroying them. In disbelief people have started asking how on earth this is possible?

If you are one of those people, you have come to the right place. Here I plan to break it down into digestible pieces exactly what it is that Apple has done with the M1.

Related:
What Does RISC and CISC Mean in 2020?

Original Submission

 
This discussion has been archived. No new comments can be posted.
Why is Apple’s M1 Chip So Fast? | Log In/Create an Account | Top | 77 comments | Search Discussion
Display Options Threshold/Breakthrough Mark All as Read Mark All as Unread
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.

  • (Score: 1) by anyanka on Thursday December 03 2020, @05:08AM

    by anyanka (1381) on Thursday December 03 2020, @05:08AM (#1083511)

    Also, there's no reason the CPU has to do a memcpy itself. It could very well just schedule that to the memory controller which can do that in the background and put up hazards for accesses to not-yet-copied areas, or even predict those and/or satisfy them with priority. This won't work on x86, because there are thousands of different libc-with-memcpy equivalents with all run some bizarre code contraption which was at some point in time considered ideal. The problem goes away if you're the sole player, supply your own libc which knows about the tricks, and make sure everyone else on your new platform does it that way, too.

    Sure, even primitive 1970s hardware like the Z80's DMA controller lets you do superfast memcpy without wasting CPU time one. And it's not much of a problem that various obscure libc versions doesn't support it, as long as the one you're using does. The worse issue on x86 is probably that not all CPUs support all instructions (just like many Z80 systems didn't have a DMA controller back in the day), but the same goes for any other hardware acceleration – including on the Mac when Apple introduces the M2 with its Quantum Processing Unit. A cursory look at GNU libc seems to indicate it'll try to do bulk 'copying' by remapping memory with copy-on-write pages – though this seems to only be implemented on the Mach kernel. Plain copying is usually surprisingly fast anyway, and probably not worth worrying about until profiling tells you it's a bottleneck.