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

16-inch MBP 2x slower than M1 MacBook Air in a real-world Rust compile

twitter.com

Post reply on HN
Print view View original

351–360 of 529 posts

Re: 16-inch MBP 2x slower than M1 MacBook Air in a real-world Rust compile

#351

Post by spullara »

nullandvoid wrote: post #136
dom96 wrote: post #113

Earlier quoted context omitted.

I actually feel like 16GB is pretty much the sweet spot. I've built a desktop PC recently and didn't bother with 32GB and haven't had any troubles. The only time I've run into limits is when I was doing things like running games and big IDEs at the same time which seems like a waste in any case regardless of how much RAM is available.

For me on windows, multiple virtual desktops, browser (chrome for work, ff for personal) IDE's and VMs (ubuntu running in wsl, and any docker containers) made 16gn unuseable for me And that's before I decided to boot up a game with all of the existing applications For me the £50 is well worth not having to care about pruning applications constantly!

I wonder if they have improved their memory compression with this new release as well. Would have compare apples to apples for various applications to see the effect.

Re: 16-inch MBP 2x slower than M1 MacBook Air in a real-world Rust compile

#352

Post by mixmastamyk »

bronson wrote: post #334
ogre_codes wrote: post #289

Earlier quoted context omitted.

I would turn that around. What kind of development are you doing where you feel 32GB is "Barely enough"? Right now I primarily work on a very complex react based app. I've also done Java, Ruby, Elixir, and Python development and my primary machine has never had 32GB. More RAM is definitely better, but when I hear phrases like "32GB is barely enough", I have to wonder what in the hell people are working on. Even runni…

One data point: when I was consulting a year ago, I had to run two fully virtualized desktops just to use the client's awful VPNs and enterprise software. Those VMs, plus a regular developer workload, made my 16GB laptop unusable. Upgrading to 32GB fixed it completely.

Desktops can use less memory than folks many folks think. I have a VM of Windows 10 in 3.5 GB running a VPN, Firefox, Java DB app, and ssh/git. For single use, memory could be decreased.

I think the art of reducing the memory footprint has been lost. Whenever I configure a VM for example, I disable/remove all the unused services and telemetry as the first step. This approaches an XP memory footprint.

Re: 16-inch MBP 2x slower than M1 MacBook Air in a real-world Rust compile

#353

Post by rhinoceraptor »

perardi wrote: post #300
bartread wrote: post #275

Earlier quoted context omitted.

This is a fair point, but it's certainly a very peculiar - and somewhat offputting - dynamic where the bottom of the range outperforms the top end.

These machines are Apple’s volume in Macs. The MacBook Air, in particular. And today, Apple gets to tout their best-seller is dramatically faster and has dramatically better battery life. Makes marketing sense to me.

It also gives them a nice profit win since they're not paying Intel anything anymore on their most popular Macs.

Re: 16-inch MBP 2x slower than M1 MacBook Air in a real-world Rust compile

#355

Post by kcartlidge »

sudhirj wrote: post #214
aunetx wrote: post #182

Earlier quoted context omitted.

I may be wrong, but the ecosystem does not really change here right? I mean, memory management should be roughly the same between x86_64 and arm regarding the amount of ram used, so I guess 16gb of ram under old macbooks is the same as 16gb under the new ones

All else being equal, yes, but the memory is faster, closer to the chip, has less wiring to go through, and because of vertical integration they can pass by reference instead of copying values internally on the hardware. The last one is big - because all the parts of the SoC trust each other and work together they can share memory withing having to copy data over the bus. That coupled with superfast SSDs means that c…

I'm not a hardware person, but I do software for a living. Your comment makes things much clearer.

You're saying that the effective difference in having the shared memory is that you get more data passed by reference and not by value at the lower levels?

If that's true, then you get extra throughput by only moving references around instead of shuffling whole blocks of data, and you also gain better resource usage by having the same chunks of allocated memory being shared rather than duplicated across components?

Re: 16-inch MBP 2x slower than M1 MacBook Air in a real-world Rust compile

#356

Post by epistasis »

sfblah wrote: post #338
epistasis wrote: post #202

Earlier quoted context omitted.

I'm no expert, but the only big architectural differences are a massively larger decoder and a reorder buffer that's several times as large as x86 designs. If these are actually the reasons for the performance difference, and it's difficult to do these on x86 because of the instruction set, it seems to this amateur that ARM64 really does have an advantage over x86.

Couldn't Intel just come out with a new set of reduced-complexity instructions that run on a per-process basis based on some bit being flipped on context switches? Then legacy apps would run fine, but the new stuff would work too. This seems not that hard to address.

As I understand it, the challenge to making wider x86 chips is the mere existence of some instructions. Adding new instructions can't help with that. But I'm just repeating what I heard elsewhere:

> Other contemporary designs such as AMD’s Zen(1 through 3) and Intel’s µarch’s, x86 CPUs today still only feature a 4-wide decoder designs (Intel is 1+4) that is seemingly limited from going wider at this point in time due to the ISA’s inherent variable instruction length nature, making designing decoders that are able to deal with aspect of the architecture more difficult compared to the ARM ISA’s fixed-length instructions.

https://www.anandtech.com/show/16226/apple-silicon-m1-a14-de...

Re: 16-inch MBP 2x slower than M1 MacBook Air in a real-world Rust compile

#357

Post by sfblah »

swiftcoder wrote: post #126
peteradio wrote: post #84

Earlier quoted context omitted.

What uses most of your ram when you need 16GB+?

Chrome. Slack. VSCode. The proliferation of desktop software that are just more Chrome processes in disguise has been punishing on memory usage. My work machine used to fully lockup on a daily basis with 16 GB of RAM. 32 GB seems to be the sweet spot right now.

People claim if you switch off to Safari the memory footprint goes down. Of course, if you're an FE dev, that comes with more ... challenging ... dev tools. YMMV.

Re: 16-inch MBP 2x slower than M1 MacBook Air in a real-world Rust compile

#358

Post by mixmastamyk »

jeffbee wrote: post #105
whalesalad wrote: post #48

I love everything about the move to Apple Silicon with the exception of the decision to put memory on-die or in-package (not sure how it is configured). They call it 'Unified Memory'. It makes a lot of sense but I don't know if they are going to be able to pack enough memory in there. A lot of folks are fixated on CPU performance lately (which is rad) but I think that there is a tendency to ignore memory. I have 32gb…

I agree completely since for large projects 16GB is barely enough to run Bazel. I know that's kind of sad but often Bazel wants to load large graphs into memory. Combined with the fact that the graphics are stealing part of main memory, I don't think I'm going to be happy with 16GB. I ordered one anyway, but I don't expect to be too psyched about the reality of it when it gets here.

Sounds like the build needs to be optimized.

Re: 16-inch MBP 2x slower than M1 MacBook Air in a real-world Rust compile

#359

Post by zerkten »

andy_ppp wrote: post #68
whalesalad wrote: post #48

I love everything about the move to Apple Silicon with the exception of the decision to put memory on-die or in-package (not sure how it is configured). They call it 'Unified Memory'. It makes a lot of sense but I don't know if they are going to be able to pack enough memory in there. A lot of folks are fixated on CPU performance lately (which is rad) but I think that there is a tendency to ignore memory. I have 32gb…

Is the new architecture better or worse with memory usage than x86 macs?

Memory usage shouldn't change that much for a similar task. It's just that paging stuff in and out is much more performant when the system is under pressure. Right now with the least amount of M1 native software available, most of it will be allocating memory natively without garbage collection.

Apple's strategy has been to avoid generational/tracing GC which reaps big benefits in terms of memory usage. It'll be interesting to see more feedback from devs running a broader range of software. It's likely people will hit apps on the long tail that use GC, and similar schemes, which will cause them to complain about memory issues. Running old apps under Rosetta 2 will be another source of complaints.

These machines are optimized for the mass market. Although they can out perform many existing machines with 8 and 16 GB of RAM, there is the huge opportunity and demand for 32GB+.

Re: 16-inch MBP 2x slower than M1 MacBook Air in a real-world Rust compile

#360

Post by The_Colonel »

spullara wrote: post #339
The_Colonel wrote: post #232

Earlier quoted context omitted.

> I think the bigger question is what does this spell for x86-64? Not much? People are acting like M1 destroys x86, but as AnandTech showed in the recent benchmark, M1 is trading blows with Zen 3 in single thread performance while having much larger core and process advantage (5nm vs. 7nm) thus being actually more expensive to produce.

The price of the 5950X is nearly the same as the Mac Mini. Estimates on actual cost of the M1 is around $75-100.

They could have used 5600X with virtually the same single core performance as well.

You also can't compare manufacturing cost and retail cost. But given AMD cores are both smaller and manufactured on older process, it's probably safe to assume AMD ones are cheaper to manufacture.

Post reply on HN