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

M1 Pro First Impressions: Core Management and CPU Performance

eclecticlight.co

Post reply on HN
Print view View original

151–160 of 234 posts

Re: M1 Pro First Impressions: Core Management and CPU Performance

#151

Post by yeldarb »

PikachuEXE wrote: post #45
yeldarb wrote: post #12

Mine just arrived today and I'm blown away. After upgrading our app's dependency chain to run native arm64 builds (which took a bit of googling) webpack's incremental build time on our app is down to 116ms from 983ms on my 2016 Macbook Pro. Over 8x faster. Our Tensorflow.js (webgl) models that previously ran about 8fps in the browser are now running at the camera's native 30fps framerate. (Similar to my desktop 2080t…

> After upgrading our app's dependency chain to run native arm64 builds Would you mind sharing your research results? I am getting one soon and I am in progress of drafting notes for stuff like migration & setup.

It was mostly stuff specific to our specific situation.

We were still on node 12 because, until recently, Google Cloud Functions didn’t support anything newer. But when I installed it, I noticed it was running on x86 via Rosetta. So I upgraded to the latest node (17) which installed as native arm64.

Almost everything “just worked” but there were build errors with installing: webpack, node-sass, gprc, and node-canvas.

Webpack turned out to be an issue with node current (17) so downgrading to lts (which is currently 16) worked.

That seems to have magically fixed the gprc build too.

We weren't actually using node-sass anymore; so removed that dependency.

Upgrading node-canvas to 2.8.0 and building from source (after installing its dependencies via homebrew) seems to have worked.

All in all it took maybe 2 hours to follow all the rabbit holes. And our whole engineering team is going to move over to arm64 as soon as Apple can deliver their machines.

Re: M1 Pro First Impressions: Core Management and CPU Performance

#152

Post by q-base »

00deadbeef wrote: post #117

Any devs here switched from an old 15.4" MBP to a new 14" MBP? I'm curious how you find the screen size for doing work? My 15.4" can scale to "looks like 1920x1200" and the 14" to "1800x1169" so there's not a lot of difference. Does the smaller size make it feel cramped?

Can you help me understand what that means? Is it not possible to run it at the "full" resolution? Will it be scaled to what equates to the 1800x1169 that you mention?

That would equate to less "real estate" than what I have on my T460s FHD screen? Of course the screen would be light years ahead to look at. But just sounds a little bit strange with regards to actual pixels/space on the screen?

Re: M1 Pro First Impressions: Core Management and CPU Performance

#153

Post by sudhirj »

zuhsetaqi wrote: post #137
codeisawesome wrote: post #133

Earlier quoted context omitted.

I’ve wondered for a while if the fans coming on due to dual monitors is a software / driver issue that could be fixed by a patch. It would save me from buying a new machine right now.

It’s because as soon as you plug in an external monitor, the dedicated GPU is used for the output and is responsible for the added heat

That part isn't a bug, though. It needs the dedicated GPU to push all those pixels, the native screen is already pretty dense.

There was a bug where something would infinite loop on a non-standard resolution, think that was fixed.

Re: M1 Pro First Impressions: Core Management and CPU Performance

#154

Post by Lukas_Skywalker »

DJHenk wrote: post #122
pistoriusp wrote: post #112

Earlier quoted context omitted.

Why not both? I can honestly say that I didn't know how bad the 2019 MBP Intel CPUs are until I tried a M1. It's streets ahead. I don't think people will be moving away from webpack for awhile, but transpilation is often a very expensive part, and `swc` is very near to stable, and as a transpiler / polyfilling tool it's pretty fast.

> Why not both? Because buying new stuff is wasteful and only a temporary solution to the problem? Look, I like nice, fast machine as much as the rest of the crowd here, but let's not kid ourselves. In a years time the software we run on it will have become even more bloated and things will be just as slow as they were. And then a new machine comes out we all want to buy that. There will be some ecstatic blog posts a…

I am still on an i5 11" MacBook Air made of aluminum from Mid 2012 with 4GB RAM. Changed the battery twice, upgraded to a larger SSD once. I was considering buying a new laptop a few years ago, but that thing has served me so well despite falling to the ground unprotected about 3 times and being old. I do embedded and some web programming. I will use it until I am no longer able to start it up. And at that point, I will probably open it up and have a very last try at fixing it.

Re: M1 Pro First Impressions: Core Management and CPU Performance

#155

Post by littlecranky67 »

DSingularity wrote: post #63
whalesalad wrote: post #30

I can’t wait for the desktop-class Pro hardware. If you extrapolate on power consumption alone it would be a complete monster. They could do something gnarly like fit 8 sockets on a single board and send your compute ability to level 9000. I’m hoping for a mid-tier unit though - a rebirth of the G4 Cube as a “Mac Mini Pro” I daily drive an M1 mini now and abuse the hell out of it. I’ve never heard the fan. It’s a rem…

They will skip desktop and ship server chips. If the trends hold, they will have TCO savings which no cloud provider can resist.

Apple will not enter the server chip market, hell Apple is not even selling any B2B products, and Jobs was always very vocal about how he doesn't like B2B.

Re: M1 Pro First Impressions: Core Management and CPU Performance

#156

Post by mrctte »

nvarsj wrote: post #95
zibzab wrote: post #20

Earlier quoted context omitted.

Unity is slow on any machine. With that said, there is a huge M1 hype on HN. It reminds me of the 64-bit ARM hype when someone benchmaked encryption (because ARMv8 has AES instructions) and everyone were made to belive that the new iPhone would be 3-4 times faster.

Don't you think it's deserved? I haven't seriously used a macbook in nearly a decade now but the M1 is making me consider buying one. Desktop class performance in a laptop with very long battery life is just amazing. The only thing stopping me is OS X. Using it is super painful for me - it doesn't even have basic snap to edge or split window functionality. My workflow is heavily dependent on tiling WMs and it would a…

This app changes everything https://apps.apple.com/us/app/magnet/id441258766?mt=12

Re: M1 Pro First Impressions: Core Management and CPU Performance

#157

Post by littlecranky67 »

nvarsj wrote: post #95
zibzab wrote: post #20

Earlier quoted context omitted.

Unity is slow on any machine. With that said, there is a huge M1 hype on HN. It reminds me of the 64-bit ARM hype when someone benchmaked encryption (because ARMv8 has AES instructions) and everyone were made to belive that the new iPhone would be 3-4 times faster.

Don't you think it's deserved? I haven't seriously used a macbook in nearly a decade now but the M1 is making me consider buying one. Desktop class performance in a laptop with very long battery life is just amazing. The only thing stopping me is OS X. Using it is super painful for me - it doesn't even have basic snap to edge or split window functionality. My workflow is heavily dependent on tiling WMs and it would a…

BetterTouchTool gets you that, along with a lot of other productivity features.

Re: M1 Pro First Impressions: Core Management and CPU Performance

#159

Post by masklinn »

TheTon wrote: post #5

I have noticed that threads running at the Utility QoS level perform a lot more consistently on the M1 than they do on Intel. Utility being the lowest libdispatch QoS level that still gets scheduled on a P core. For example, a piece of code I was optimizing recently ran with very little variation in time between runs on my M1 system, but had ~30% variation on a similarly loaded Intel Mac. Changing the QoS level to De…

Have you noticed whether `nice(1)` also triggers these QoS change, or is it limited to libdispatch?

> it sounds like on the M1 Pro maybe the two highest QoS levels (interactive and user initiated) now preferably map to p cores 0-3, and maybe now default and utility map to p cores 4-7

That seems unlikely, though I don't have an M1* device what feels more likely is that the two clusters are independently powered (the turbo-ing works on a cluster basis so that's almost certain), therefore the machine favors fully loading the first one before it starts "spilling" to the second (and thus has to power it up).

Re: M1 Pro First Impressions: Core Management and CPU Performance

#160

Post by masklinn »

saagarjha wrote: post #147
dwaite wrote: post #19

Earlier quoted context omitted.

For Linux, I believe it will dispatch based on the niceness level and overall CPU utilization - past a certain threshold, it will start putting work at default or higher priority onto the performance cores. For the Mac, I believe you have equivalent access for scheduling between posix and GCD, but the scheduling configuration is likely way more approachable in GCD. Also: On M1, there is an added capability to run in…

M1's cores are homogenous and all of them support TSO.

Saying that the M1's cores are homogenous is pretty misleading / confusing as the icestorm and firestorm cores are rather different. big.LITTLE/DIQ-type architectures are usually considered heterogenous even if all the actors share an ISA (because you can't treat all the cores

But as to the latter assertion, you're indeed correct per Joe Groff (Swift compiler engineer at Apple): https://twitter.com/jckarter/status/1332045390057639939

> The A12 only supported TSO on the performance cores. The M1 supports it on all cores.

Post reply on HN