Live data from Hacker News

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

twitter.com

121–130 of 529 posts

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

#121

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…

What people seam to forget is, that SOC is the future, and an upgrade should be as simple as switching one chip. This also comes with a lot of benefit with locality and performance.

There's no way the SOC will be upgradable.

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

#122
post #56

Earlier quoted context omitted.

The Air in the article is fanless.

Right, and I think some benchmarks I've seen this morning indicate that it throttles during more intensive tasks. The Pro benchmarks better, the only difference being the fan.

According to one reviewer it takes 8 minutes before it starts to throttle.

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

#123

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…

Keep in mind that so far Apple has only started offering M1 on what are essentially entry-level computers. I think it's likely there will be a 32GB Unified Memory version for the 16" MBP (which maybe will become available on the 13" or Mac Mini too). I think M1 would not be able to achieve the performance and efficiency improvements if the RAM were not integrated, so they'll stick with Unified Memory for the time bei…

I agree with you completely. I am looking forward to the next offering and hope that they have a plan for more memory.

In the meantime I wonder if they are going to do dual (or more) socket configurations. I was just thinking to myself imagine a Mac Pro with 8 of these M1 chips in it all cooled by one big liquid heat block. That thing would rip.

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

#124
post #116
post #97

Earlier quoted context omitted.

I don't think that makes any sense, considering that the RAM is not on the same die as the processor. It's on the module, yes, but they're not making it on the same process. I realize this image is a schematic representation rather than an actual photograph, but here it is. https://www.apple.com/v/mac/m1/a/images/overview/chip__fffqz...

The point being made is that the processors that they will package with more memory are going to exist on larger dies. When you increase die size you decrease yield so you need to have a mature process.

Why does that follow? 4 cores and 32GB makes fine sense.

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

#125

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…

Not to mention the e-waste and the inability for users to upgrade their own devices. I wonder what the performance cost was of having standard memory modules. I suspect it wasn't significant and this is more of a move to prevent upgrade and increase consumption and waste. This is another reason I really don't ever want to own another Apple device. They want more and more control over the system and they keep moving t…

Even if you could boot other OSs, you forget that there are no drivers written for them. Windows and Linux both would be unusable for potentially years after launch.

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

#126

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…

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.

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

#127
Here is The Verge's test with 30 minute Cinebench loop.

It seems that from now on the only difference between Air and Pro is that Air throttles down to about 70 % in sustained mode while Pro's cooling keeps up.

And Apple's last fanless laptop, the lovely 2017 Macbook 12, has a very worthy successor. I now wonder, if/how the throttling changes when plugged into 4K display, as this caused MB12 to run out of thermal headroom in tens of seconds.

(Also, even thermally throttled M1 destroys my current 4C/8T 4 GHz Haswell i7 desktop, which is beyond powerful for everything I need. M1 = 7700 pts, M1 throttled = 5300 pts, Haswell i7 = 4600, and Macbook 12 = 1400).

https://twitter.com/keff85/status/1328740865926459400

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

#128
post #113

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 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.

I would agree if it wasn't doing double-duty as memory for the GPU. Under those circumstances, even 16gb can start to get a bit tight on some tasks.

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

#129

The next laptop I purchase for home use will be a linux laptop. Hopefully linux on a laptop has gotten a lot better than my last couple experiences with it. Apple products have just taken such a steep turn for the worse over the years, I can't justify paying that amount of money for such poor quality.

Sadly Linux on laptops isn’t that much better than it used to be. I’m using both.

However if you dislike Apple, Linux is a perfectly good choice unless you are a developer who needs to write code for Apple products.

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

#130
post #87

Earlier quoted context omitted.

That is a great idea. I think the software is going to be the hard part. You would need some kind of heuristic or software to manage moving memory between those two locations. That is just my initial thought I could be totally wrong.

Every modern general purpose computer already has multiple layers of memory. This would just be an additional layer. The virtual memory subsystems in the OS will handle this. At the end of the day it's just caches all the way down. A workstation with 16GiB of "on-chip" memory would be like a huge L4 cache for the say 512GiB of "standard" DDR4. I really like OSTEP's chapters on virtual memory if you're interested in r…

Yet, is it a requirement in a memory hierarchy to copy the lower level in the upper one? Like, all the stuff in you L1 cache has to be also in your L2 cache. E.g. if you would have 32gb of external DDR it would add only 16gb more to the packaged 16gb?
Post reply on HN