Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Apple’s M1 processor and the full 128-bit integer product

lemire.me

Post reply on HN
Print view View original

141–150 of 180 posts

Re: Apple’s M1 processor and the full 128-bit integer product

#141

Post by bzzzt »

monsieurbanana wrote: post #125
bombcar wrote: post #13

Earlier quoted context omitted.

I have a non-M1 with Big Sir and it takes more than full minute from sleep to usable. I suspect it’s because I have five monitors and 20 million pixels (actually more as that’s the post-retina resolution).

How does the number of pixels (or even monitors, for that matter), affect that much sleeping time? Rendering a FPS game at 1080p is 2 million pixels per frame. At 60fps, that's rendering 120 million pixels per second. What am I missing?

Detecting the monitors, negotiating the correct resolutions, setting scaling factors and window positions after coming out of sleep will take some time. Maybe macOS does monitor setup sequentially? (no idea, just got 1 big external screen that also takes a few seconds to light up - handshake speed seems to vary between monitor brands)

Re: Apple’s M1 processor and the full 128-bit integer product

#142

Post by siquick »

SCUSKU wrote: post #6
thefourthchime wrote: post #2

I love my M1, but does anyone else have horrific performance when resuming from wake? It’s like it swaps everything to disk and takes a full minute to come back to life.

I haven't noticed poor wake times, but my laptop does kernel panic and reboot a fair amount. Maybe 4 times in the past week. My hunch is that it's Spotify's fault but I haven't dug into the logs.

I have this problem but only if I've been plugged into a monitor, and then unplugged and gone onto battery. Rebooting after unplugging stops it but its annoying.

Re: Apple’s M1 processor and the full 128-bit integer product

#143

Post by namibj »

For the interested, LLVM-MCA says this

    Iterations:        10000
    Instructions:      100000
    Total Cycles:      25011
    Total uOps:        100000

    Dispatch Width:    4
    uOps Per Cycle:    4.00
    IPC:               4.00
    Block RThroughput: 2.5

    No resource or data dependency bottlenecks discovered.
, which to me seems like 2.5 cycles per iteration (on Zen3). Tigerlake is a bit worse, at about 3 cycles per iteration, due to running more uOPs per iteration, by the looks of it.

For the following loop core (extracted from `clang -O3 -march=znver3`, using trunk (5a8d5a2859d9bb056083b343588a2d87622e76a2)):

    .LBB5_2:                                # =>This Inner Loop Header: Depth=1
    mov     rdx, r11
    add     r11, r8
    mulx    rdx, rax, r9
    xor     rdx, rax
    mulx    rdx, rax, r10
    xor     rdx, rax
    mov     qword ptr [rdi + 8*rcx], rdx
    add     rcx, 2
    cmp     rcx, rsi
    jb      .LBB5_2

Re: Apple’s M1 processor and the full 128-bit integer product

#144

Post by immigrantsheep »

mpweiher wrote: post #118
zelon88 wrote: post #101

You mean to tell me that a $2000 Macbook is almost as performant as a $1000 PC? Tell me more!

Both Minis and Airs start at under $1000, and they're all the same speed.

Air starts at $1500 if you're not in the USA

Re: Apple’s M1 processor and the full 128-bit integer product

#145

Post by gpderetta »

pbsd wrote: post #80
titzer wrote: post #67

Earlier quoted context omitted.

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…

Based on the information from [1] we have something like this for both loops: .LBB0_2: eor x13, x9, x9, lsr #30 # 2 \* p1-6 mul x13, x13, x11 # 1 \* p5-6 eor x13, x13, x13, lsr #27 # 2 \* p1-6 mul x13, x13, x12 # 1 \* p5-6 eor x13, x13, x13, lsr #31 # 2 \* p1-6 str x13, [x0, x10, lsl #3] # 1 \* p7-8 add x13, x10, #2 # 1 \* p1-6 add x9, x9, x8 # 1 \* p1-6 mov x10, x13 # none cmp x13, x1 # b.lo .LBB0_2 # Fused into 1 \…

I think you are right that mull/h are fused. I think that M1 has 128 ALUs for the vector unit, so it would be a good way to make use of them. M1 is far from the first iteration of the architecture and Apple has likely picked most if not all low hanging fruits. It also helps x86 emulation I guess.

edit: but see the comment else thread about the loop iteration time being off by a factor of 2.

Re: Apple’s M1 processor and the full 128-bit integer product

#146

Post by gpderetta »

ascar wrote: post #124
titzer wrote: post #40

Did anyone actually look at the machine code generated here? 0.30ns per value? That is basically 1 cycle. Of course, there is no way that a processor can compute so many dependent instructions in one cycle, simply because they generate so many dependent micro-ops, and every micro-op is at least one cycle to go through an execution unit. So this must mean that either the compiler is unrolling the (benchmarking) loop,…

This is the benchmarking loop: for (size_t i = 0; i N is 20000 and the time measured is divided by N. [1] However, that loop has two increments and only computes 10000 numbers. This is also visible in the assembly add x8, x8, #2 So if I see this correctly the results are off by a factor of 2. [1] https://github.com/lemire/Code-used-on-Daniel-Lemire-s-blog/...

Yes, the i++ seems an oversight.

The relative speed between the two hashes is still the same, but it is no longer one iteration per cycle.

Re: Apple’s M1 processor and the full 128-bit integer product

#147

Post by Ar-Curunir »

ben_bai wrote: post #119

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.

128-bit muls really help speed up finite field impl, which speed up elliptic curve crypto. That’s one crucial place where faster code helps.

Re: Apple’s M1 processor and the full 128-bit integer product

#148

Post by HelloNurse »

ascar wrote: post #124
titzer wrote: post #40

Did anyone actually look at the machine code generated here? 0.30ns per value? That is basically 1 cycle. Of course, there is no way that a processor can compute so many dependent instructions in one cycle, simply because they generate so many dependent micro-ops, and every micro-op is at least one cycle to go through an execution unit. So this must mean that either the compiler is unrolling the (benchmarking) loop,…

This is the benchmarking loop: for (size_t i = 0; i N is 20000 and the time measured is divided by N. [1] However, that loop has two increments and only computes 10000 numbers. This is also visible in the assembly add x8, x8, #2 So if I see this correctly the results are off by a factor of 2. [1] https://github.com/lemire/Code-used-on-Daniel-Lemire-s-blog/...

A C for statement is a "benchmarking loop" in the same sense that "slice a sponge cake into two layers and place custard in the middle" is an actionable dessert recipe.

Re: Apple’s M1 processor and the full 128-bit integer product

#150

Post by Toutouxc »

immigrantsheep wrote: post #144
mpweiher wrote: post #118

Earlier quoted context omitted.

Both Minis and Airs start at under $1000, and they're all the same speed.

Air starts at $1500 if you're not in the USA

$1345 in my country, $1265 with edu discount.
Post reply on HN