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

91–100 of 529 posts

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

#91

Post by whalesalad »

peteradio wrote: post #84
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…

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

You can never have enough ram!

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

#92

Post by codys »

whalesalad wrote: post #61
TylerE wrote: post #58

Earlier quoted context omitted.

I wonder if the CPU can support mixed RAM. E.g. have the on-die 8GB of "fast" ram, and then support 2 external DIMMs or something for "overflow", file caching, etc.

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.

macos already has capabilities for compressing memory used by applications before finally giving up and paging it out. It seems plausible they could extend the code that supports that feature to push memory to external (or allocate it there in the first place if utilization isn't expected to be hot), and only pull it back after utilization indicates there is a benefit.

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

#93

Post by acdha »

tootie wrote: post #18

Nearly universal praise for the M1 versus it's predecessor but I don't see how this really changes Apple's position the way he implies. Their machines are still far more expensive than Windows and can't use high-powered GPUs like AMD/Nvidia. The people who choose PC, still have the same incentives to do so. For most users, the faster performance will probably not be very noticeable. The reduced power consumption is t…

Can we not drag the standard trolling points into another thread? Anyone who’s done the numbers for real knows that “far more expensive” hasn’t been accurate since the 2000s and, well, the AMD GPUs in many Macs would suggest that you’re not very interested in making an accurate comparison.

Most people have multiple factors in their buying decisions. This means that Apple is able to avoid giving a negative on performance for people who value battery life and heat, and the competition will, as it always has, benefit everyone by punishing Intel for the mismanagement which has left everyone getting less for their money.

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

#94

Post by schultzer »

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…

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.

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

#95

Post by usefulcat »

whalesalad wrote: post #61
TylerE wrote: post #58

Earlier quoted context omitted.

I wonder if the CPU can support mixed RAM. E.g. have the on-die 8GB of "fast" ram, and then support 2 external DIMMs or something for "overflow", file caching, etc.

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.

Pretty sure this is already a thing for NUMA systems, e.g. an Intel system with a pair of N-core processors. Each processor gets "its own" half of memory. Memory which belongs to the other processor is slower to access.

See also Linux cpusets (cset command), which can be used to control which NUMA nodes a process has access to.

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

#96

Post by jug »

akavi wrote: post #67

So are we going to see this chip in MBPs at some point, or is there a reason that's a bad idea? Furthermore, is there any reason to think there's a less throttle-happy version that might be available for the Pros?

Apple has already launched the Macbook Pro 13" M1 which does come with a fan for probably less throttling. The 16" version wasn't updated so I'm thinking they're planning something special for those.

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

#97

Post by jeffbee »

kemiller wrote: post #79
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…

My guess is that they are releasing the M1 right now because it's the smallest SoC they're going to make and its yields are just barely enough to be viable. Once they get better yields on the 5nm process, they will start making the larger, more yield-sensitive SoCs with more RAM in them.

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

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

#98

Post by hinkley »

dharmab wrote: post #14
hinkley wrote: post #4

I'm at the point where I need a new Macbook Pro and I can't help thinking I want the last generation of the x86_64 architecture, not the first generation of something new. Those have never paid off for me. At work, Intel would clearly be better. We do a growing amount of Docker work destined for Intel machines. But at home it's fuzzier, since I've been playing with k3s on a cluster of Pi clones. It's going to come do…

If you require Docker, the Apple Silicon machines are not an option, and won't be for at least a little while. https://www.docker.com/blog/apple-silicon-m1-chips-and-docke...

To be fair, a developer-worthy M1 machine is still going to be 'a little while'. But once that machine is out the previous model quickly ceases to be an option, so I have to sort it out based on speculation.

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

#99

Post by whalesalad »

trillic wrote: post #87
whalesalad wrote: post #61

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…

Thanks for the link, downloaded to read this evening :thumbsup:

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

#100

Post by quasse »

whalesalad wrote: post #61
TylerE wrote: post #58

Earlier quoted context omitted.

I wonder if the CPU can support mixed RAM. E.g. have the on-die 8GB of "fast" ram, and then support 2 external DIMMs or something for "overflow", file caching, etc.

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.

Luckily that's a problem that academics have been working on since the 1960s. https://en.wikipedia.org/wiki/Non-uniform_memory_access

You'd be surprised how many modern OSes are at least partially NUMA aware. Even Java already has a non-uniform aware allocator.

Post reply on HN