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

161–170 of 529 posts

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

#161

Post by whizzter »

bmurphy1976 wrote: post #69
cercatrova wrote: post #26

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

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.

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

#162

Post by sudhirj »

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…

One, this is repeating the iPhone vs Android comparisons. iPhones with 4GB RAM feel faster and get more work done than Androids running Qualcomm ARM with double that amount of RAM. The faster IO becomes the cheaper paging becomes, and macOS and iOS have a lot of work done to handle paging well.

Two, this is the entry level processor, made for the Air, which is what we get for students, non-technical family members and spare machines. Let’s see what the “pro” version of this is, the M1X or whatever. We already know this chip isn’t going to go as is into the 16 inch MacBook Pro, the iMac Pro or the Mac Pro. I’d like to see what comes in those boxes.

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

#163

Post by speedgoose »

Paul-ish wrote: post #8

Is it fair to compare performance for different compile targets?

If the compiled application runs faster or similarly fast I think it's fair.

The point is to develop and run binaries. If X86 with SSE4 takes a lot more CPU time to compile binaries with acceptable performances compared to ARM, it's a win for the ARM architecture.

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

#164

Post by masklinn »

heisenbergs wrote: post #141
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…

According to anandtech the memory throughput is off the charts at 68.25GB/s [1]. That's twice as fast as high speed ddr4 memory (DDR4-4000 at 32GB/s). In other words: they totally trounced and took it to the next level with regards to memory, because they can. If anything, memory control is their biggest advantage. Scaling the amount of ram won't be an issue. Increasing the bandwidth perhaps, but it'll still be way q…

FWIW the latest-gen consoles supposedly have memory bandwidth in the hundreds of GB/s. The PS5 supposedly reaches 448GB/s, and the XBX 336 to 560 depending on the memory segment.

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

#166

Post by masklinn »

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.

> Chrome. Slack. VSCode.

VMs, especially since you need one to run docker on OSX, IntelliJ, Firefox, ...

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

#167

Post by ericd »

dom96 wrote: post #113
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 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.

Really depends on what you’re doing. If you’re working with large amounts of data, being able to put it in memory is super helpful.

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

#168

Post by kemiller »

zeusk wrote: post #104
kemiller wrote: post #79

Earlier quoted context omitted.

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.

The ram is not on the same chip/die as M1, it's another chip that's put in the same package. Increasing RAM will not affect apple's yields at all since the RAM dies are not made by apple and are not 5nm

Oh, I see. It's still nevertheless likely that stronger chip packages will be bundled with more RAM.

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

#169

Post by masklinn »

localhost wrote: post #65

Here's another benchmark, this time XCode, that I screencapped from Dave Lee's YouTube review: https://twitter.com/john_lam/status/1328754454930231299 The 3950X Hackintosh performed on par with the MBA.

> The 3950X Hackintosh performed on par with the MBA.

That should probably be put the other way around. It gives the impression that the MBA was the incumbent.

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

#170

Post by tempest_ »

whalesalad wrote: post #149
ogre_codes wrote: post #131

Earlier quoted context omitted.

> You can't get an M1 configuration right now larger than 16GB which is a table-stakes baseline dev requirement today. Everyone on my team has been using 15" MacBook Pros with 16GB RAM for the past 3 years. I suspect most developers run with 16GB of RAM just fine. I'm not arguing "16GB is fine for all developers everywhere!", but it's absolutely not a hard requirement. I suspect for a lot of us, the difference in per…

I think if you have a very specific role where your workload is constant it makes sense. I am an independent contractor and work across a lot of different projects. Some of my client projects require running a full Rails/Worker/DB/Elasticsearch/Redis stack. Then add in my dev tools, browser windows, music, Slack, etc... it adds up. If I want to run a migration for one client in a stack like that and then want to swit…

At some point it is easier to have something sitting in a rack somewhere. That way you dont have to cook your ultrabook to run that stuff.
Post reply on HN