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…
It's not magic memory, it's LPDDR4X-4266 or LPDDR5-5500. These work just fine without being in-package, so it's purely a cost cutting decision.
16-inch MBP 2x slower than M1 MacBook Air in a real-world Rust compile
441–450 of 529 posts
Re: 16-inch MBP 2x slower than M1 MacBook Air in a real-world Rust compile
#442Is anyone else thinking, what the f*ck? Are we in a new era of computing? It certainly feels that way when looking at these desktop class ARM chips, where performance doubled every year or so, just like back in the 80s and 90s.
Re: 16-inch MBP 2x slower than M1 MacBook Air in a real-world Rust compile
#443I 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…
Re: 16-inch MBP 2x slower than M1 MacBook Air in a real-world Rust compile
#444Earlier quoted context omitted.
We're crossing the threshold this year where real-time ray tracing in hardware isn't just some theoretical concept, it's actually useful and available in affordable consumer hardware (NVIDIA and AMD GPUs, as well as the PS5 and new Xbox all have it). Yes, the NVIDIA 2xxx RTX series had it two years ago, but this is the year where it's actually viable and not so gimmicky.
We've been able to do realtime ray tracing in software since forever though and the shadertoys and whatnot have been full of hardware accelerated demos, that's not so interesting. I remember playing with a number of demos on my intel core 2 duo macbook (not pro) a decade ago.
Re: 16-inch MBP 2x slower than M1 MacBook Air in a real-world Rust compile
#445Is anyone else thinking, what the f*ck? Are we in a new era of computing? It certainly feels that way when looking at these desktop class ARM chips, where performance doubled every year or so, just like back in the 80s and 90s.
Note that the comparison is also compiling to ARM vs compiling to Intel, so its partly to do with the simplicity of the compilation process between the two architectures. https://twitter.com/rikarends/status/1328762958118346753
Re: 16-inch MBP 2x slower than M1 MacBook Air in a real-world Rust compile
#446Earlier 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.
Are they? I don't think this is how AMD does things—all their desktop and Threadripper processors are constructed out of 8-core chiplets. The higher-core count processors just use more chiplets per package, not necessarily larger dies. If Apple's already putting multiple chiplets on one package (core + RAM), I wonder if they'll use the same approach to scaling.
Re: 16-inch MBP 2x slower than M1 MacBook Air in a real-world Rust compile
#447Earlier quoted context omitted.
I'd say the opposite, this increases the speed of such apps to closer to what is now native speed.
I'm referring to the second point about memory that OP made. You know, having to allocate 700MB of memory in order to run an electron chat application.
You can get 16GB for $52 on Amazon. That 700MB is equivalent to $4.64 one-time payment.
There are more important things to worry about, seems to me.
Re: 16-inch MBP 2x slower than M1 MacBook Air in a real-world Rust compile
#448Earlier quoted context omitted.
But, in theory at any rate, Rosetta2 will allow you to run all that software on Apple silicon.
We already know that Rosetta2 doesn't support everything.
Edit: Looks like kernel extensions aren't supported either.
Re: 16-inch MBP 2x slower than M1 MacBook Air in a real-world Rust compile
#449Earlier quoted context omitted.
Normally this wouldn't feel so ground breaking, but the stars are in alignment and all these improvements are hitting at the same time. We're seeing years of work and investment paying off (AMD, Apple, ARM, Nvidia, Amazon), new process nodes (TSMC), and new tech (Ray Tracing, DLSS, machine learning) all hitting at the same time. And that's the big stuff! There's also the steady incremental improvements such as batter…
Intel in 2020 is IBM in 1980.
Re: 16-inch MBP 2x slower than M1 MacBook Air in a real-world Rust compile
#450Earlier quoted context omitted.
Normally this wouldn't feel so ground breaking, but the stars are in alignment and all these improvements are hitting at the same time. We're seeing years of work and investment paying off (AMD, Apple, ARM, Nvidia, Amazon), new process nodes (TSMC), and new tech (Ray Tracing, DLSS, machine learning) all hitting at the same time. And that's the big stuff! There's also the steady incremental improvements such as batter…
Not to forget that apparently some of the people driving that scrappy team that had a big part in Intel's resurgence has been working on the M1. This actually reminded me of how I got skeptical comments from people when I told them that my small and scrappy Pentium-M (P-M -> M1, HAH!) based laptop was almost as fast as their desktop P4 monsters in compiling code.