Discussion Apple Silicon SoC thread

[Eug]

M1
5 nm
Unified memory architecture - LP-DDR4
16 billion transistors

8-core CPU

4 high-performance cores
192 KB instruction cache
128 KB data cache
Shared 12 MB L2 cache

4 high-efficiency cores
128 KB instruction cache
64 KB data cache
Shared 4 MB L2 cache
(Apple claims the 4 high-effiency cores alone perform like a dual-core Intel MacBook Air)

8-core iGPU (but there is a 7-core variant, likely with one inactive core)
128 execution units
Up to 24576 concurrent threads
2.6 Teraflops
82 Gigatexels/s
41 gigapixels/s

16-core neural engine
Secure Enclave
USB 4

Products:
$999 ($899 edu) 13" MacBook Air (fanless) - 18 hour video playback battery life
$699 Mac mini (with fan)
$1299 ($1199 edu) 13" MacBook Pro (with fan) - 20 hour video playback battery life

Memory options 8 GB and 16 GB. No 32 GB option (unless you go Intel).

It should be noted that the M1 chip in these three Macs is the same (aside from GPU core number). Basically, Apple is taking the same approach which these chips as they do the iPhones and iPads. Just one SKU (excluding the X variants), which is the same across all iDevices (aside from maybe slight clock speed differences occasionally).

EDIT:



M1 Pro 8-core CPU (6+2), 14-core GPU
M1 Pro 10-core CPU (8+2), 14-core GPU
M1 Pro 10-core CPU (8+2), 16-core GPU
M1 Max 10-core CPU (8+2), 24-core GPU
M1 Max 10-core CPU (8+2), 32-core GPU

M1 Pro and M1 Max discussion here:

Page 78 - Discussion - Apple Silicon SoC thread

Page 78 - Seeking answers? Join the AnandTech community: where nearly half-a-million members share solutions and discuss the latest tech.

forums.anandtech.com

M1 Ultra discussion here:

Page 109 - Discussion - Apple Silicon SoC thread

Page 109 - Seeking answers? Join the AnandTech community: where nearly half-a-million members share solutions and discuss the latest tech.

forums.anandtech.com

M2 discussion here:

Page 127 - Discussion - Apple Silicon SoC thread

Page 127 - Seeking answers? Join the AnandTech community: where nearly half-a-million members share solutions and discuss the latest tech.

forums.anandtech.com

Second Generation 5 nm
Unified memory architecture - LPDDR5, up to 24 GB and 100 GB/s
20 billion transistors

8-core CPU

4 high-performance cores
192 KB instruction cache
128 KB data cache
Shared 16 MB L2 cache

4 high-efficiency cores
128 KB instruction cache
64 KB data cache
Shared 4 MB L2 cache

10-core iGPU (but there is an 8-core variant)
3.6 Teraflops

16-core neural engine
Secure Enclave
USB 4

Hardware acceleration for 8K h.264, h.264, ProRes

M3 Family discussion here:

Page 215 - Discussion - Apple Silicon SoC thread

Page 215 - Seeking answers? Join the AnandTech community: where nearly half-a-million members share solutions and discuss the latest tech.

forums.anandtech.com

M4 Family discussion here:

Page 263 - Discussion - Apple Silicon SoC thread

Page 263 - Seeking answers? Join the AnandTech community: where nearly half-a-million members share solutions and discuss the latest tech.

forums.anandtech.com

 

[igor_kavinski]

Didnt someone on this forum prove that AVX512 gives Zen5 no benefits in Geekbench?

I don't know. The 285K doesn't do as well in the same subtest: https://browser.geekbench.com/v5/cpu/compare/23023412?baseline=23018554

 

[CouncilorIrissa]

Didnt someone on this forum prove that AVX512 gives Zen5 no benefits in Geekbench?

Yes.

 

[igor_kavinski]

Yes.

That's GB6.

 

[MS_AT]

That's GB6.

I would not expect Geekbench to regress with x64 support when they introduce things like SME on ARM.

Yes.

There is actually a difference in one of the subtests that is above noise (almost 10%), but only in ST and it doesn't seem it has any notable influence on the average. So without a few runs hard to say if it was one time anomaly. But well, I think this discussion should move then GB specific thread.

On topic:

Was there any reviewer that tried to even look into M family performance counters and do similar analysis that Chips&Cheese do but for Apple chips? Are Perf Counters even available for mortals?

 

[digitaldreamer]

14900K hackintosh vs. M4 Pro: https://browser.geekbench.com/v5/cpu/compare/23023862?baseline=23018554

Wonder how long Apple will allow some users to "enjoy" the MacOS experience on the cheap.

My hackintosh back in the day was about the same price as the base M4 Pro, but had significantly less RAM, spinning platters for storage, USB 2 ports, and a huge heatsink with 5" fan. How far we've come.

 

[Eug]

14900K hackintosh vs. M4 Pro: https://browser.geekbench.com/v5/cpu/compare/23023862?baseline=23018554

Wonder how long Apple will allow some users to "enjoy" the MacOS experience on the cheap.

Some macOS Sequoia features are not supported on Intel Macs at all.

 

[name99]

I would not expect Geekbench to regress with x64 support when they introduce things like SME on ARM.

There is actually a difference in one of the subtests that is above noise (almost 10%), but only in ST and it doesn't seem it has any notable influence on the average. So without a few runs hard to say if it was one time anomaly. But well, I think this discussion should move then GB specific thread.

On topic:

Was there any reviewer that tried to even look into M family performance counters and do similar analysis that Chips&Cheese do but for Apple chips? Are Perf Counters even available for mortals?

Yes perf counters are available. Yes they can be used.

The BIG problem with all the standard sites (Chips and Cheese, Geekerwan, James Aslan) is that they are not especially curious. They will run microbenchmarks or look at perf counters and then say what they say (eg "The branch predictor looks same level as Intel" or "Fetch is not as good as ARM which can fetch across two taken branches per cycle" or "The memory forwarding is OK, but nothing special, slower than Intel")
all of which is *technically* true but fails to deal with the obvious question: OK then, why is Apple so much faster?

That's the question I answered in my PDFs. And that's the question about which all these x86-based sites have ZERO curiosity. They're just not interested in investigating how Apple does things DIFFERENTLY, it's enough for them to say "Well, when it comes to Apple doing some x86 thing, they do it OK"; they don't have the imagination or curiosity to see what Apple does that is NOT just an x86 thing.

It's pathetic, truly pathetic, and yet it's true.

Meanwhile, for people who get it. who do understand what Apple is doing that's a decade beyond where Intel and ARM are living, let me give a few choice recent patents:

US20240354109A1 - Re-use of Speculative Load Instruction Results from Wrong Path - Google Patents

Disclosed techniques relate to re-use of speculative results from an incorrect execution path. In some embodiments, when a control transfer instruction is mispredicted, a load instruction may have been executed on the wrong path. In disclosed embodiments, result storage circuitry records...

patents.google.com

https://patents.google.com/patent/US12067398B1

https://patents.google.com/patent/US12001847B1

 

[jdubs03]

Yes perf counters are available. Yes they can be used.

The BIG problem with all the standard sites (Chips and Cheese, Geekerwan, James Aslan) is that they are not especially curious. They will run microbenchmarks or look at perf counters and then say what they say (eg "The branch predictor looks same level as Intel" or "Fetch is not as good as ARM which can fetch across two taken branches per cycle" or "The memory forwarding is OK, but nothing special, slower than Intel")
all of which is *technically* true but fails to deal with the obvious question: OK then, why is Apple so much faster?

That's the question I answered in my PDFs. And that's the question about which all these x86-based sites have ZERO curiosity. They're just not interested in investigating how Apple does things DIFFERENTLY, it's enough for them to say "Well, when it comes to Apple doing some x86 thing, they do it OK"; they don't have the imagination or curiosity to see what Apple does that is NOT just an x86 thing.

It's pathetic, truly pathetic, and yet it's true.

Meanwhile, for people who get it. who do understand what Apple is doing that's a decade beyond where Intel and ARM are living, let me give a few choice recent patents:

US20240354109A1 - Re-use of Speculative Load Instruction Results from Wrong Path - Google Patents

Disclosed techniques relate to re-use of speculative results from an incorrect execution path. In some embodiments, when a control transfer instruction is mispredicted, a load instruction may have been executed on the wrong path. In disclosed embodiments, result storage circuitry records...

patents.google.com

https://patents.google.com/patent/US12067398B1

https://patents.google.com/patent/US12001847B1

I’d be curious about these PDFs!

 

[MS_AT]

Yes perf counters are available. Yes they can be used.

The BIG problem with all the standard sites (Chips and Cheese, Geekerwan, James Aslan) is that they are not especially curious. They will run microbenchmarks or look at perf counters and then say what they say (eg "The branch predictor looks same level as Intel" or "Fetch is not as good as ARM which can fetch across two taken branches per cycle" or "The memory forwarding is OK, but nothing special, slower than Intel")
all of which is *technically* true but fails to deal with the obvious question: OK then, why is Apple so much faster?

That's the question I answered in my PDFs. And that's the question about which all these x86-based sites have ZERO curiosity. They're just not interested in investigating how Apple does things DIFFERENTLY, it's enough for them to say "Well, when it comes to Apple doing some x86 thing, they do it OK"; they don't have the imagination or curiosity to see what Apple does that is NOT just an x86 thing.

It's pathetic, truly pathetic, and yet it's true.

Meanwhile, for people who get it. who do understand what Apple is doing that's a decade beyond where Intel and ARM are living, let me give a few choice recent patents:

US20240354109A1 - Re-use of Speculative Load Instruction Results from Wrong Path - Google Patents

Disclosed techniques relate to re-use of speculative results from an incorrect execution path. In some embodiments, when a control transfer instruction is mispredicted, a load instruction may have been executed on the wrong path. In disclosed embodiments, result storage circuitry records...

patents.google.com

https://patents.google.com/patent/US12067398B1

https://patents.google.com/patent/US12001847B1

I remember I run into googledocs in the making that was trying to describe M1 back in the day, but since this was work in progress I thought I would come back to it later and.... I lost the link Were you the author / one of the authors and could you share the link?

 

[igor_kavinski]

Were you the author / one of the authors and could you share the link?

I think this is him: https://github.com/name99-org/AArch64-Explore

 

[jdubs03]

That’s some real dedication right there. Sheesh!