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

391–400 of 529 posts

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

#391

Post by Tagbert »

threeseed wrote: post #250
bartread wrote: post #204

I think Apple have screwed themselves over a bit here by sticking ARM-based Apple silicon in their lower-end/entry level devices first. I mean what's the point in spending £5k on a fully tricked out 16-inch MBP, as I'd been considering, when an entry level Macbook Air or Mac Mini is going to run rings around it? The reason I'm not going to buy one of these lower end Macs (the Mini would be the best fit) is that I can…

No they didn't. There is simply too much complex, professional software that will take time to be ported to ARM versus the relative straightforward needs of entry-level users e.g. Go, Photoshop, Docker. And they need a large install base to push developers to invest the necessary resources.

Adobe has a native M1 Photoshop in beta now and plans to port Premiere after the first of the year. You may be overestimating the effort to “port” to M1. For most apps, it is just a new compile target and a bunch of regression testing.

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

#392

Post by epistasis »

xbar wrote: post #384
epistasis wrote: post #303

Earlier quoted context omitted.

I guess my point is that any such gains are temporary and will soon disappear with the next release of software, or with the next website redesign. MS Office apps, for example, are horrifically unresponsive on Macs. Switching the ribbon to a new view has 700-1000ms of lag on my 2.4 GHz i5. Maybe an M1 brings it to 350ms. Once MS developers start developing on an M1 laptop, the developers will change code, and it will…

I run MS Office local apps on my 2018 MBP 15" 6-core. They are slow. I agree the M1 will never make them feel better. Neither will the M2 or M3. They will always be slow. If they were ever going to be fast, they would already be fast. They are a software problem unto their own.

Searching on the Costco website has a 2-3 second delay between each entry for me.

I think there are two routes to making software faster for users: 1) intense education of developers and rewarding them properly for keeping software responsive, and 2) only letting them develop on 5-10 year old hardware. I'm not really sure 1) would work with many teams, but I'm pretty sure 2) would.

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

#393

Post by wil421 »

tempest_ wrote: post #170
whalesalad wrote: post #149

Earlier quoted context omitted.

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.

Larry Ellison proposed a thin client that was basically a dumb computer with a monitor and nic that connected to a powerful server in the mid 1990s.

For a while we had a web browser which was kinda like a dumb client connected to a powerful server. Big tech figured out they could push processing back to the client by pushing JavaScript frameworks and save money. Maybe if arm brings down data center costs by reducing power consumption we will go back to the server.

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

#394

Post by rbanffy »

wmf wrote: post #205
throwaway894345 wrote: post #195

Earlier quoted context omitted.

I’m guessing the performance improvements derive from integrating the memory onto the same chip (instead of using external memory), not from ARM (although power savings come from ARM). So we will probably see a new era of laptop SoCs, but that also means coupling RAM with CPU (or maybe you can mix and match the on-chip RAM with external RAM?).

I’m guessing the performance improvements derive from integrating the memory onto the same chip Nope, LPDDR4x-4266 is LPDDR4x-4266. Apple, Intel, and AMD all have access to the same RAM. The Firestorm core is the real advantage.

Isn't it attached via a wider bus?

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

#395

Post by Symmetry »

The_Colonel wrote: post #232
harrygeez wrote: post #198

Earlier quoted context omitted.

Qualcomm chips are not that far behind Apple's, and Microsoft has Windows on ARM ready for a while now. Those performance advantage won't be there for long. I think the bigger question is what does this spell for x86-64?

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

Do we have numbers on how big the M1 is in square mm terms?

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

#396

Post by mikechen233 »

herf wrote: post #237
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…

Anandtech is reporting 62GB/sec memcpy, and the way-faster Geekbench results are the memory-bound ones (e.g., Gaussian blur is 4x faster!) So I think the speedups like these are largely due to memory architecture.

It's not due to the on package or the united memory. M1 is using industry standard 128bits lpddr4. On package is still using regular dram chips. What seemingly is the advantage is the firestorm cpu has much wider pipeline and capable doing more load and store in-flight at the time. Also the cache is also able to provide low latency and the bandwidth numbers. Intel or amd is able to achieve similar performance in memory bound workloads if they designed the logic on cpu for that workload.

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

#397

Post by csjr »

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.

It certainly feels that way! Also, imagine if they keep pushing it like the A series.

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

#398

Post by Symmetry »

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…

It's certainly in package rather than on the same chip. The process required to make DDR is different from what you use to make the core's logic. The DRAM chips might be literally stack on top of the CPU chip, though. Apple does things that way in the iPhone IIRC.

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

#399

Post by Tagbert »

bartread wrote: post #275
smallnamespace wrote: post #217

Earlier quoted context omitted.

Apple’s ‘low end’ segment is the lion’s share of both revenue and profit. A decade ago, the Intel Mac Pro also came out after the rest of the product line. For awhile you could only get a Powermac G5.

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.

Yes, but that a temporary situation and likely to be resolved in 6-12 months.

Some customers will still choose the older models due to various concerns. -Some customers will hold off out of fear of incompatible software. -Others will hold off because they need to run boot camp or x86 VMs. -Others will need extra RAM or Ports.

Others will have no such concerns and will embrace the new.

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

#400

Post by epistasis »

skrtskrt wrote: post #387
epistasis wrote: post #303

Earlier quoted context omitted.

I guess my point is that any such gains are temporary and will soon disappear with the next release of software, or with the next website redesign. MS Office apps, for example, are horrifically unresponsive on Macs. Switching the ribbon to a new view has 700-1000ms of lag on my 2.4 GHz i5. Maybe an M1 brings it to 350ms. Once MS developers start developing on an M1 laptop, the developers will change code, and it will…

MS Office apps have always been (possibly intentionally?) horrifically bad on Mac. Not a great benchmark IMO. The average Joe user just uses a browser and something like Spotify. Even most word processing by college students is in Google Docs now - very few people I knew bought MS Office for their Macs when I was in college 5 years ago, even with a $99 student license through the school.

It's a perfect benchmark because even 20 years later performance is only getting worse, rather than better.

Developers will use all available resources until their is pressure to be more efficient. This is not a critique of developers, this is the nature of software. Unless critical development time is spent making sure that software is responsive, it will only ever have barely acceptable performance.

Which is why new, faster CPUs have very little effect on users. Any performance gains will be gobbled up by new software frameworks that promise better use of developer time, but which may come at an absolutely tremendous cost of UI responsiveness.

Spotify, Slack, Office on Mac, hyper complex JavaScript web frameworks... all will continue to take more and more CPU cycles that are available.

Post reply on HN