Because that’s what I had access when I did the tests. I’ll do a series of tests on our cluster and post these.

Will these be meaningful for you?

The thing is, M1 on air is a relatively low clock speed CPU with passive cooling. 10200K is actively cooled, unlimited beast of its generation. The libraries I use are X86 optimized. Yet the code I’ve written is 25% faster on ARM.

This is significant.

I'm not saying it isn't, but the "low clock speed" part is often brought up in a discussion like this, implying that Apple could make a M1KFS running at much higher clocks.

X86 optimized doesn't actually mean that much on a lot of workloads because the memory hierarchy completely dominates performance.

Apple knew this so the M1 has an extremely fast memory system.

It’s a scientific code which manipulates a lot of relatively big matrices, which saturates the FPUs pretty well (I made the analysis back then).

Intel’s memory architecture can keep up with the load until I utilize all cores. When I start to use HT cores, neither cache, nor memory can keep up.

I do the both tests (Intel and Apple) both with physical core counts to keep it fair.

So it’s not some run of the mill code.

> 10200K is actively cooled, unlimited beast of its generation

Curious what you meant here since that part doesnt exist, and if it did it would be near the bottom of the stack for the generation (101xx and 103xx are the low core count i3 and i5 parts).

I meant 10700K.

Written that comment on mobile on a plane, before take-off, so I either typo'd and didn't see, or auto-correct changed it deeming 10200K is more correct than 10700K.

If you look to the original comment where I sparked the discussion, I've mentioned it as 10700K already.

Because it's a huge step compared to most ARM SoCs.

Being able to compete against a consumer high end desktop, even if it's an older one, it's a feat all by itself