apple m1 and numa support

[Cosmos Nicolaou]

Hi,

are there any plans/interest for adding support for the efficiency vs performance cores on Apple's new CPUs? Similarly, it looks as if they may end up with on-die and off-die dram in the future.

Cheers, Cos.

[Athaariq Ardiansyah]

Golang supports ARM architecture pretty well. In term of efficiency and performance on united DRAM, you don't have to worry unless you're working on GPU, DSP, Neural Processors, or anything outside CPU. Golang compiler and runtime program are work mainly at CPU by the way, and which CPUs to be worked on is OS' decision, not userspace program.

[David Chase]

Strictly speaking, yes people are looking at this, but we don't have nearly enough information to commit to a particular interface just yet.

Can you say more about what support you are imagining, and what you would do with it?

For example, right now I use numactl for reliable benchmarking on the BIG.little arm64 on my desk, and that meets my needs.

It's not even clear if we should be supporting "policies" or handing people the ability to talk about classes of cores.

And if it's "policy", what does that look like?  "Best speed", "best power" -- what if best power reduces throughput by 75%?

If I try to imagine what we could reliably provide without rewriting scary parts of the runtime, it would be 3 choices, "all fast", "all slow", "don't care".

I.e., pretty much what you can get from numactl right now, but without wrapping your program in another program.

(How this interacts with already running inside numactl, clouds, containers, VMs, I have no idea.)

Near/far memory support in a general-purpose programming language is still pretty close to a research problem, as far as I know.

[Cosmos Nicolaou]

The main use case that occurred to me is background/daemon apps using high perf cores when they could be using

the efficiency cores (e.g. docker). I'd hate for developers to avoid using go on macs for reasons such as this. Apple's

documentation claims that the OS will do this automatically for background processes vs applications but I expect

it will be far from perfect - eg. the analysis app that I want to run quickly but I put in the background whilst

I do something else.

Assuming you agree that this is worthwhile to consider, then yes, policy specification is the challenge. I had already

come to the same conclusion regarding simple policies: eg: only-performance, only-efficiency and dont-care.

I don't think anything equivalent to numactl is available on macs, do you know of anything?

I may take a stab at implementing this for fun to see how it looks in practice. I have a dev kit so A14 and not M1.

As for near/far memory, I agree that there's nothing to do other than wait to see how they support larger memory.

Cheers, Cos.

[David Chase]

Thanks, glad we at least imagine the same use cases.  (We probably want to hear from other people, too, but so far, so good, right?)

Apple's backgrounding policy might get tripped up by the GC -- every two minutes (current policy) it wakes up and grabs 25% of available cores (current policy) to finish a GC ASAP.

[Nick Keets]

Perhaps have a look at taskpolicy, if you haven't already. I don't have an M1 mac though so I haven't tried it myself.