Live data from Hacker News

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

lemire.me

161–170 of 180 posts

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

#161
post #114

Earlier quoted context omitted.

But Apple has a lot of capital, and could win massive political brownie points for doing so, especially if they promised that some percentage of fab capacity would be sold to other American firms.

TSMC is based in on the soil of one of America's allies.

An ally who China is dreaming of re-assimilating (or taken over, depending on which side of the view you are) since its inception.

China is engaging in ever more aggressive saber rattling and the total lack of any measurable reaction to their takeover of Hong Kong only has emboldened them. Who can guarantee Taiwan won't end up the same fate?

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

#162

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.

Yes. This is actually a known issue, provided you have an external monitor attached; lots of people complaining about it. The Mac actually wakes up instantly if you lift the screen, but it usually takes 5-10 seconds before it will wake up the external monitor. Worse, for some of us when it does finally wake up the monitor, sometimes it wakes it up with all the wrong colors, and rebooting is the only reliable fix. (an…

M1 instantly wakes my XDR display and never has a problem.

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

#163
post #141

Earlier quoted context omitted.

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)

This is almost certainly it - the screens show all sorts of weird graphical artifacts (some clearly a Retina display in "native" resolution) as it starts and loads. I assume it's having to fire up all the GPU memory, etc.

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

#164
post #60

Earlier quoted context omitted.

The blog post links to the benchmark... It's repeatedly populating a 20k entry array with the results. godbolt clang compiles it to: .LBB5_2: // =>This Inner Loop Header: Depth=1 mul x13, x11, x10 umulh x14, x11, x10 eor x13, x14, x13 mul x14, x13, x12 umulh x13, x13, x12 eor x13, x13, x14 str x13, [x0, x8, lsl #3] add x8, x8, #2 // =2 cmp x8, x1 add x11, x11, x9 b.lo .LBB5_2 [1] https://github.com/lemire/Code-used-o…

I would be wary of using gettimeofday to measure such short periods. As https://pubs.opengroup.org/onlinepubs/009604599/functions/ge... says, the resolution of the system clock is unspecified, and 20,000 × ≈10 ≈ 200k instructions easily run in under a millisecond on modern hardware. The benchmark probably get rids of that by doing it 40,000 times in quick succession, but why not measure the time of all 40,000 iterati…

The resolution of the clock is unspecified by the POSIX standard but that does not mean it's unspecified by the platform this is actually running on. If this was trying to be portable code you'd have a big issue there but it's not. It is still limited by gettimeofday maxing out at microsecond precision, though, which is quite poor. And seems to be using a realtime clock, which introduces errors from network time sync & such. That's unlikely to crop up here, but it's still a risk. clock_gettime_nsec_np(CLOCK_MONOTONIC) is what should be used here.

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

#165
post #80

Earlier quoted context omitted.

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.

Oh yeah, I thought the add r,r,2 was odd but didn't investigate. This brings things back to ~2+ cycles per iteration, which strictly speaking does not require fusion.

It would be easier to test this explicitly instead of inside some unrelated RNG.

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

#166
post #124
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/...

> Update: The numbers were updated since they were off by a factor of two due to a typographical error in the code.

The article got updated by now :)

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

#167

Earlier quoted context omitted.

I think they are still working through some external monitor driver issues. The colors on my LG 4k were initially way off until I did an advanced calibration. Occasionally waking up from sleep it will revert, but opening the Display preference and swapping between the calibrations fixes it. My connection is through usbc. I don't have any performance issues waking up though.

I think there are a couple issues going on with the colors. For some people it is calibration. But what I experience is almost like a color inversion (but it's not a full inversion, it looks like maybe one or two channels got inverted). Makes it difficult to even find the mouse pointer so I can get to the menu and reboot the machine. Then it comes up fine.

Interesting. I did submit a bug to Apple about my issue. Mainly because I never did a calibration with my 2017 mbp and the monitor looked great. With the M1 MBA I had to do the advanced calibration just to make the same monitor usable. Otherwise the colors were completely washed out. It almost seemed like the setting to auto-dim the laptop monitor was also being oddly applied to the external.

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

#168
post #60

Earlier quoted context omitted.

The blog post links to the benchmark... It's repeatedly populating a 20k entry array with the results. godbolt clang compiles it to: .LBB5_2: // =>This Inner Loop Header: Depth=1 mul x13, x11, x10 umulh x14, x11, x10 eor x13, x14, x13 mul x14, x13, x12 umulh x13, x13, x12 eor x13, x13, x14 str x13, [x0, x8, lsl #3] add x8, x8, #2 // =2 cmp x8, x1 add x11, x11, x9 b.lo .LBB5_2 [1] https://github.com/lemire/Code-used-o…

I would be wary of using gettimeofday to measure such short periods. As https://pubs.opengroup.org/onlinepubs/009604599/functions/ge... says, the resolution of the system clock is unspecified, and 20,000 × ≈10 ≈ 200k instructions easily run in under a millisecond on modern hardware. The benchmark probably get rids of that by doing it 40,000 times in quick succession, but why not measure the time of all 40,000 iterati…

On Linux and MacOS, gettimeofday is accurate to microseconds. Not only is the returned struct is expressed in microseconds, but I have personally observed that it is accurate to microseconds.

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

#169

Earlier quoted context omitted.

Instant wake for me. However any time I come across a password field in a website the computer freezes for a painfully long 10 seconds or so while it presumably decrypts my password vault. Sometimes this will happen multiple times per page load if I deselect and reselect the password field.

This happens to me too, I’m using 1Password. I have a suspicion the plug-in is involved with this but I’ve not had time to collect evidence yet. Seems to be rare though, I’ve not spotted anybody else with this issue.

Huh, no problem here. I use lastpass and safari's built in password thing.

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

#170
post #9

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.

No, it's perfect, instant wake for me. I have never seen anything like this. I have buggy apps (like Facebook Messenger) locking up, but I guess that's normal, I just uninstall them.

Which M1 do you have?
Post reply on HN