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

471–480 of 529 posts

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

#471

Post by diebeforei485 »

zerkten wrote: post #321
diebeforei485 wrote: post #263

Earlier quoted context omitted.

I don't think the M1 chip is a great choice for the 16" MacBook Pro. It's designed for lower power devices. It may do well on certain workloads like compilation, but may even regress (in terms of performance, not performance-per-watt) on other workloads. Their future iterations would be much better suited to a higher power device. It does create this weird short-term demand planning issue, but plenty of corporate cus…

> I don't think the M1 chip is a great choice for the 16" MacBook Pro. It's designed for lower power devices. It may do well on certain workloads like compilation, but may even regress (in terms of performance, not performance-per-watt) on other workloads. What workloads do you think won't run better in some manner (faster, lower power consumption, etc.)? It's a general purpose CPU. Apple's own benchmarks talked abou…

Apple's own benchmarks of the M1 are not compared against the 16" MacBook Pro. They aren't yet offering Apple Silicon on the 16" because it isn't clearly better than the current Intel version, and would have elicited comparisons that aren't as glowing.

I'm thinking specifically games, CAD, and video editing. Even Final Cut Pro workloads (running natively) seem to be faster on a 16" MacBook Pro than on an M1 13" MacBook Pro based on the initial reviews on YouTube today. Sure, an M1 machine could do it consuming less power, but who cares? People buy a 16" because they want speed.

I think they will need redesigned high-performance cores for the 16" and the higher-end 13" [or 14"]. Simply using more of them probably won't cut it.

And MacBooks are not just used in dev environments. They're used in education, finance, media, government, and many other sectors - and some of them do want to be the last to switch. If the performance gains aren't dazzling, they can't be convinced to switch sooner. And if they stay on Intel, they can even be convinced to move back to Windows.

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

#472

Post by leptons »

robotresearcher wrote: post #299
leptons wrote: post #266

Earlier quoted context omitted.

No. That's a stupid idea for desktop. Not everyone needs 64GB of RAM, but some of us do - and that would be an expensive and awful upgrade to have to throw out your CPU with 32GB RAM on-chip just to put in the same CPU with 64GB on-chip. It makes absolutely no sense.

I'd tolerate that if it runs usefully faster every day. Could save money overall. There are several parts in a workstation that are already monolithic packages. Most GPU+GRAM cards, for example.

So you're talking about taking a $300 CPU chip and turning into a $500 or $800 chip depending on how much RAM is on the SOC. But the fact still remains that the vast majority of the RAM sits idle while the CPU processes through relatively small chunks of it at a time, which is what cache is for. If anything I'd rather see more cache RAM on the CPU itself than having to pay for a CPU + RAM on the same SOC. The performance gain from combining CPU + RAM on the same "SOC" is not that great enough to warrant doing that as an approach for all computers - Apple is doing this mostly because it saves them money. There's a lot of push back from power users about expandability not even being an option anymore. But 99% of Apple's customer base doesn't have any need for expandability or power-user features, or having the fastest silicon available because they only use it for facebook, facetime, or a few other basic applications. And that's fine. I won't be buying one though.

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

#473

Post by DeRock »

mft_ wrote: post #308
Someone wrote: post #276

Earlier quoted context omitted.

Laptop or desktop: likely, but even if the next Apple Watch will be faster, which I doubt, their smart speakers and headphones probably can do with a slower CPU for the next few years.

Is there a name for this trait of bringing unnecessary precision to a discussion, I wonder? I mean, contextually it’s obvious that the previous poster meant this is the slowest Apple Silicon that will ever exist in a relevant and comparable use case - i.e. a laptop or desktop. And the clarification that yes, slower Apple Silicon may exist for other use cases didn’t really add value to the discussion. And I’m not even…

It sounds like the word you’re looking for is ‘pedantic’.

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

#474

Post by sudhirj »

kcartlidge wrote: post #355
sudhirj wrote: post #214

Earlier quoted context omitted.

All else being equal, yes, but the memory is faster, closer to the chip, has less wiring to go through, and because of vertical integration they can pass by reference instead of copying values internally on the hardware. The last one is big - because all the parts of the SoC trust each other and work together they can share memory withing having to copy data over the bus. That coupled with superfast SSDs means that c…

I'm not a hardware person, but I do software for a living. Your comment makes things much clearer. You're saying that the effective difference in having the shared memory is that you get more data passed by reference and not by value at the lower levels? If that's true, then you get extra throughput by only moving references around instead of shuffling whole blocks of data, and you also gain better resource usage by…

That’s how I understand it, yes. I’m not into hardware either, going by engineering side of the event. In the announcement, there some parts shot at the lab/studio, where the engineers explain the chip. Ignore the marketing people with their unlabelled graphs, the engineers explain it well.

But yes, they’re basically saying because this is “unified memory”, there’s no copying. No RAM copies between systems on the SoC, no copies between RAM and VRAM, etc. because the chips are working together, they put stuff on the RAM in formats they can all understand, and just work off that.

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

#475

Post by sudhirj »

andrekandre wrote: post #432
sudhirj wrote: post #214

Earlier quoted context omitted.

All else being equal, yes, but the memory is faster, closer to the chip, has less wiring to go through, and because of vertical integration they can pass by reference instead of copying values internally on the hardware. The last one is big - because all the parts of the SoC trust each other and work together they can share memory withing having to copy data over the bus. That coupled with superfast SSDs means that c…

> because of vertical integration they can pass by reference instead of copying values internally on the hardware. got any links about that?

Going by the engineering explanations in the announcement video. See the segments shot in the “lab” set. They’re actually pretty proud of this and are explaining the optimisations quite candidly.

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

#476

Post by sudhirj »

wmf wrote: post #216
aunetx wrote: post #182

Earlier quoted context omitted.

I may be wrong, but the ecosystem does not really change here right? I mean, memory management should be roughly the same between x86_64 and arm regarding the amount of ram used, so I guess 16gb of ram under old macbooks is the same as 16gb under the new ones

"Controlling the ecosystem" and "integration" and such are just wishful-thinking rationalizations. Chrome and Electron will use however much RAM they use; Apple can't magically reduce it. If you need 32GB you need 32GB.

Yeah, that’s partly true. Applications that allocate 1000GB will need to get what they ask for. No getting around bad applications. The benefits are more in terms of lower level systems communicating by sharing memory instead of sharing memory by communicating, which is always faster and needs less memory, but needs full trust and integration.

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

#477

Post by unixfg »

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.

A single core being able to fully saturate LPDDR4X bandwidth seems pretty advantageous.

https://www.anandtech.com/show/16252/mac-mini-apple-m1-teste...

“One aspect we’ve never really had the opportunity to test is exactly how good Apple’s cores are in terms of memory bandwidth. Inside of the M1, the results are ground-breaking: A single Firestorm achieves memory reads up to around 58GB/s, with memory writes coming in at 33-36GB/s. Most importantly, memory copies land in at 60 to 62GB/s depending if you’re using scalar or vector instructions. The fact that a single Firestorm core can almost saturate the memory controllers is astounding and something we’ve never seen in a design before.”

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

#478

Post by KingOfCoders »

gok wrote: post #329
KingOfCoders wrote: post #36

My Ryzen 3900 is also so much faster than my (former dev machine) iMacPro with a Xeon and fast SSD (Rust compiles, TypeScript builds). Tech moves on. But the main thing for me is Linux, as it feels much more responsive than current OS X versions on the iMacPro. (the reason for dropping the iMacPro was no AI learning though not performance).

What do you use for AI learning?

Currently some 2080s. Probably 3090s next year.

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

#479

Post by vladvasiliu »

oarsinsync wrote: post #251
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.

I was until I tried doing the test myself. It takes 82 seconds to compile on my i5-4200M. I'm not sure this test is deserving of the breathless headline and commentary, especially since the original tweeter later follows up with: > Extra info: The M1 macbooks (air/pro) can't drive 2 external screens, and the air throttles a bit after 3+ minutes sustained compute (20-30%) https://twitter.com/rikarends/status/132875317…

I think this just shows how little improvement there has been over the last years. However, getting twice the performance with a fanless design looks interesting, even if there is throttling after a while. For what I do, I don't regularly wait for compiles that take ages, but having a silent computer without losing performance is a net win.

Curiosity got the best of me too and I ran the test on my late 2013 MBP, 2.3 GHz i7, 16 GB ram. Compilation took 44 seconds and the fans didn't even spin up (with 23 ºC ambient temperature).

A little further down the thread [0] he gives the actual numbers, which are around 20s on the M1, which puts the i7 [1] at around 40s.

I'm not sure how much of this is Rust specific, but for my own projects I haven't noticed a big difference between my mbp, an old i7-3930k and a newer i5-8500. The MBP is somewhat slower, but it only has 4 cores while the others have 6.

[0] https://twitter.com/rikarends/status/1328706132752347138?s=2...

[1] A tweet corrects the MBP CPU as being an i7 and not an i9.

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

#480

Post by sbeckeriv »

merb wrote: post #354
mlakkadshaw wrote: post #279

I just compiled it on i9-10900 inside of WSL, and it took 15.80s to compile. https://imgur.com/5FtPJe5

mac i/o at it's finest... it's probably also faster on linux.

Dell xp15 i7-9750H ubuntu 20.04 v1.50.0-nightly

cargo clean && cargo build -p makepad --release

   Compiling makepad v0.1.0 (/home/becker/trash/makepad/makepad)
    Finished release [optimized] target(s) in 23.64s
Post reply on HN