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

381–390 of 529 posts

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

#381

Post by ogre_codes »

selectodude wrote: post #291
ogre_codes wrote: post #244

Earlier quoted context omitted.

Yes, ARM is one piece of many. (Commented about this above) Though I suspect if Qualcomm were able to source a TSMC 5nm chip, it would be more competitive with Apple than Intel is at this point though. Apple has a lot of other things going for it where Qualcomm lags (the Secure Enclave, graphics performance, audio and photo processing, the neural engine etc etc)

Debatable. Qualcomm operates under a strict transistor budget because their chips lack a dedicated customer willing to pay what it costs to develop an ultra-wide CPU like this. Apple knows they're going to sell 100+ million of whatever core they make so they're able to more easily amortize and justify the costs of development. Intel gets no such benefit of the doubt. I have no idea what on earth is going on over ther…

Agreed.

What I was trying to get at is that the ARM designs plus the TSMC fabs are a big part of Apple's success here. The pieces are out there where someone else could put together an ARM based package that's more competitive with Apple. In retrospect, maybe it's more likely to see something like this from Nvidia than Qualcomm.

Even then, it's hard to say how competitive that CPU would be. Just based on Microsoft's Surface with it's half-assed Qualcomm CPU, it seems feasible though.

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

#382

Post by Nullabillity »

w0utert wrote: post #280
oarsinsync wrote: post #251

Earlier quoted context omitted.

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…

>> We already know the A-series of chips performs incredibly in short workloads. We have no information yet on how it performs under sustained workloads. What makes you think that given sufficient cooling, it will not perform exactly the same as the M1 in the MBA but sustained? It’s not like the ARM architecture changes anything in the thermodynamics of cooling cpus compared to an x86 chip, right? I’d wager that unde…

It's an Apple chip that will only ever be in Apple computers.

Asking about how it would do in a computer with sufficient cooling is about as relevant as asking how it would do in a computer with a usable keyboard or OS.

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

#383

Post by kube-system »

jeffbee wrote: post #350
kube-system wrote: post #318

Earlier quoted context omitted.

Having a throttling mechanism != the throttling mechanism is engaged With enough cooling, you can operate a CPU at full tilt and never engage the throttle.

If your CPU always runs at its steady-state temperature that means it sucks and it leaving performance on the table. A CPU that can run at a steady 3 GHz (or whatever) should be capable of 5+ GHz momentarily given the right initial conditions.

Thermals are not the only factor that limits clock speeds. For instance, gate switching times are also a factor.

Although if you're saying the M1's performance "sucks", I can't wait to see the next iteration.

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

#384

Post by xbar »

epistasis wrote: post #303
xbar wrote: post #248

Earlier quoted context omitted.

I do not agree. Look at the AnandTech Speedometer 2.0 metric. https://www.anandtech.com/show/16252/mac-mini-apple-m1-teste... The 8GB Macbook Air at $899 educational is faster, and will feel faster, than any laptop that anyone has owned or thought of owning at that price point. Millions of buyers who need laptops for *-at-home activities will sing its performance praises on Sheets and Salesforce. The "I need 16GB cro…

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.

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

#385

Post by Symmetry »

ant6n wrote: post #370
epistasis wrote: post #356

Earlier quoted context omitted.

As I understand it, the challenge to making wider x86 chips is the mere existence of some instructions. Adding new instructions can't help with that. But I'm just repeating what I heard elsewhere: > Other contemporary designs such as AMD’s Zen(1 through 3) and Intel’s µarch’s, x86 CPUs today still only feature a 4-wide decoder designs (Intel is 1+4) that is seemingly limited from going wider at this point in time due…

I find that odd. Don’t they have some sort of icache? Intel could decode into a fixed width Alternative instruction set inside the icache, then use a wider decode when actually executing.

Yes, they have a cache for decoded operations. It'll hold a certain number but it's sort of inefficient because the fixed width decoded instructions are a lot larger than the variable length instructions so it doesn't hold too many. Because it doesn't help on code with large footprints and not too much time in inner loops you don't necessarily want the number of ops you can get form it to be too much more than the width of the rest of the system if you want a balanced design.

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

#387

Post by skrtskrt »

epistasis wrote: post #303
xbar wrote: post #248

Earlier quoted context omitted.

I do not agree. Look at the AnandTech Speedometer 2.0 metric. https://www.anandtech.com/show/16252/mac-mini-apple-m1-teste... The 8GB Macbook Air at $899 educational is faster, and will feel faster, than any laptop that anyone has owned or thought of owning at that price point. Millions of buyers who need laptops for *-at-home activities will sing its performance praises on Sheets and Salesforce. The "I need 16GB cro…

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.

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

#388

Post by eyelidlessness »

rhinoceraptor wrote: post #353
perardi wrote: post #300

Earlier quoted context omitted.

These machines are Apple’s volume in Macs. The MacBook Air, in particular. And today, Apple gets to tout their best-seller is dramatically faster and has dramatically better battery life. Makes marketing sense to me.

It also gives them a nice profit win since they're not paying Intel anything anymore on their most popular Macs.

I don’t think it will make a huge difference for their profits unless the (modest for the mini, significant for the 13” MBP, nonexistent for the MBA) price cuts significantly move more volume. Apple is notorious for sticking to consistent profit margins and stuffing in as much value as they can to meet their target price points. I would expect that their margins on the MBA are ~20-25%, and ~30% on the rest of the Mac line, just as it’s been since at least the original iMac.

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

#389

Post by sitkack »

epistasis wrote: post #202
bryanlarsen wrote: post #183

Earlier quoted context omitted.

IMO, this has little to do with it being ARM. 30 years ago ARM had a significant micro architectural advantage in performance per watt, but in this era of 10 billion transistor chips, that advantage has disappeared. x86_64 rationalized the x86 architecture and decode is such a small fraction of the power budget that it really doesn't matter anyways. What does matter, IMO: - assembling a killer team - 5nm process - hi…

I'm no expert, but the only big architectural differences are a massively larger decoder and a reorder buffer that's several times as large as x86 designs. If these are actually the reasons for the performance difference, and it's difficult to do these on x86 because of the instruction set, it seems to this amateur that ARM64 really does have an advantage over x86.

The ISA differences between ARM and x86 do not account for the difference in performance, there are multiple factors here (process, ssd, memory bandwidth, cache, thermal reservoir, etc).

While this is wonderful for ARM in the now-term, we just moved from walled ISAs to a plurality of ISAs, compute just became a bulk commodity in a way that it could not with an x86 duopoly.

Anyone can now take off the shelf RISC-V designs that are currently at > 7.1 coremarks/mhz and get them fabbed on Glofo or TSMC. If you need integrator help, you can use the design services of SiFive.

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

#390

Post by Symmetry »

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.

You do get a power benefit from keeping the RAM in-socket rather than having to go out over more wires to reach the RAM.
Post reply on HN