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

51–60 of 180 posts

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

#51

Post by coldtea »

rootusrootus wrote: post #23
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.

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…

>and before anyone asks, yes, I tried a different HDMI cable

Have you tried a USB-C/thunderbolt cable/controller tho?

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

#52

Post by titzer »

brigade wrote: post #46
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,…

The dependency chain is state += 0x60bee2bee120fc15ull or (state += UINT64_C(0x9E3779B97F4A7C15)); the rest of the calculations are independent per iteration. Anyway, the more important fact is that 64x64b -> 128b mul might be one instruction on x86, but it's broken into 2 µops. Because modern CPUs generally don't design around µops being able to write two registers in the same set.

It's a shame we can't see the rest of the code. What is happening to the result value? Is it being compared to something? Put into an array, or what? All of that code probably totally outweighs what you pointed out here. Or, at least it should. I have a bad feeling it might be being dead-code eliminated, since compilers are super aggressive about that nowadays, but I hope he's somehow controlled for that.

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

#53

Post by coldtea »

CameronNemo wrote: post #39
Waterluvian wrote: post #18

Earlier quoted context omitted.

Did you somehow accumulate a bajillion passwords?

Crypto optimizations are no joke. My Pinebook Pro takes several seconds longer than my T430 to decrypt my keepassxc database.

Why would it need to decrypt a whole database though, and not just the required password? To avoid leaking the key name?

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

#54

Post by colinmhayes »

cyanydeez wrote: post #32
simongr3dal wrote: post #26

Earlier quoted context omitted.

> Why would they? Because Apple has a lot of capital and they wouldn’t need to compete as hard for their share of tsmc production capacity.

they are addicted to cheap labor.

How much labor is involved in semiconductor manufacturing? It's mostly automated, right?

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

#55

Post by rootusrootus »

coldtea wrote: post #51
rootusrootus wrote: post #23

Earlier quoted context omitted.

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…

> and before anyone asks, yes, I tried a different HDMI cable Have you tried a USB-C/thunderbolt cable/controller tho?

I'm kinda limited in my options, because this MBP only has two USB ports. So I have one port which goes to a USB hub, and the other port goes to an Apple A/V adapter with USB-C power delivery pass-thru, HDMI, and a USB port. If not for my need to have one USB port be switchable, and the rest not, I'd use a USB-C -> DP cable like I use on my 16" MBP.

This may prompt me to upgrade prematurely, if/when the next M1 MBP comes out with more than two ports.

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

#56

Post by mhh__ »

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,…

At that throughput the CPU is speculating and exploiting the access pattern.

It's also worth saying that if Apple were dead set on throughput in this area they could've implemented some non-trivial fusion to improve performance. I don't have an M1 so I can't find out for you (and Apple are steadfast on not documenting anything about the microarchitecture...)

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

#57

Post by bosswipe »

kube-system wrote: post #31
tedyoung wrote: post #17

Earlier quoted context omitted.

Not in the next 10 years. Why would they? Fabs are extremely capital-intensive and take years to get up and running, when (like Taiwan Semi) knows how to do it. Intel has shown how hard it can be to do this right. Let TSM work on production (and hopefully get more/larger fabs in the USA up and running) and getting better at packing in the transistors, and let Apple improve the design (and software).

They’ve vertically integrated everything else, and they’ve had great success along the way. TSMC has other customers that compete with Apple for production capacity. And there’s geopolitical risk in the region where TSMC (currently) operates.

Apple hasn't been vertically integrated in any kind of manufacturing since the 90s. It's all built in China.

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

#58

Post by somethoughts »

tedyoung wrote: post #17
LAMike wrote: post #16

Anyone want to take a guess at how long it will be until Apple has their own fab in the US making M1 chips?

Not in the next 10 years. Why would they? Fabs are extremely capital-intensive and take years to get up and running, when (like Taiwan Semi) knows how to do it. Intel has shown how hard it can be to do this right. Let TSM work on production (and hopefully get more/larger fabs in the USA up and running) and getting better at packing in the transistors, and let Apple improve the design (and software).

Why would they make their own M and A processors? They could continue to buy Intel chips and revert back to using PortalPlayer and Samsung chips. Chip designing is capital intensive and takes years to get up and running, when Intel and Samsung know how to do it.

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

#59

Post by coldtea »

floatingatoll wrote: post #8
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.

It’s inappropriate of you to post an offtopic end user technical support question on this post about CPU microarchitecture performance.

It's inappropriate of you to scold another commenter with a content-less comment.

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

#60

Post by brigade »

titzer wrote: post #52
brigade wrote: post #46

Earlier quoted context omitted.

The dependency chain is state += 0x60bee2bee120fc15ull or (state += UINT64_C(0x9E3779B97F4A7C15)); the rest of the calculations are independent per iteration. Anyway, the more important fact is that 64x64b -> 128b mul might be one instruction on x86, but it's broken into 2 µops. Because modern CPUs generally don't design around µops being able to write two registers in the same set.

It's a shame we can't see the rest of the code. What is happening to the result value? Is it being compared to something? Put into an array, or what? All of that code probably totally outweighs what you pointed out here. Or, at least it should. I have a bad feeling it might be being dead-code eliminated, since compilers are super aggressive about that nowadays, but I hope he's somehow controlled for that.

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-on-Daniel-Lemire-s-blog/...
Post reply on HN