Live data from Hacker News

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

twitter.com

491–500 of 529 posts

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

#491

Earlier quoted context omitted.

I would turn that around. What kind of development are you doing where you feel 32GB is "Barely enough"? Right now I primarily work on a very complex react based app. I've also done Java, Ruby, Elixir, and Python development and my primary machine has never had 32GB. More RAM is definitely better, but when I hear phrases like "32GB is barely enough", I have to wonder what in the hell people are working on. Even runni…

One data point: when I was consulting a year ago, I had to run two fully virtualized desktops just to use the client's awful VPNs and enterprise software. Those VMs, plus a regular developer workload, made my 16GB laptop unusable. Upgrading to 32GB fixed it completely.

That's not what this discussion is about. 16GB is definitively limiting if you run VMs but 32GB should be plenty. If you need more then either you are running very specialized applications which means your own preferences are out of touch with the average developer or you are wasting all of the RAM on random crap.

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

#492

Earlier quoted context omitted.

14nm was delayed, 10nm was massively delayed, 7nm is delayed again. That's a fairly long run of underperformance. Sure, they sit on enough money that they can recover if they do it right. But there currently aren't any signals that they're getting things right.

Delays aren't necessarily underperformance. Let me offer an example. If Boeing had delayed the rollout of the MAX 8, or even simply reduced the production rate, it may have been able to identify and rectify the MCAS failure mode, thus preventing suspension of the MAX aircraft. In retrospect, they could have delivered more aircraft prior to the pandemic and avoided many of the order cancellations that it brought. Some…

It is an underperformance relative to their previously published roadmaps. There may be other reasons than just mismanagement for those delays, but they're still delays.

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

#493
post #152

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

This is more of a failing of the runtime that Electron uses and how it (ab)uses that runtime. Browsers were never meant to be run once per application. Sciter JS was supposed to be an Electron replacement but it didn't pan out. With some luck c-smile will stay motivated enough to finish it and once it gains traction there will be another attempt to opensource it.

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

#494

Earlier quoted context omitted.

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.

It's seems wasteful, but RAM is so cheap, who cares? 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.

RAM is only cheap because people don't waste it. If every application was written with Electron or every executable was a Java program (including CLI commands) you would cry and beg for more memory efficiency.

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

#495

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.

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

This should be a higher up. A fairer comparison would be compiling for the same target

There could be all manner of processor optimisations that are taking time to process. Like for like would be much more indicative

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

#496

Earlier quoted context omitted.

>> 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 in the same ballpark of power efficiency as AMD's x86 chips. It's slightly more efficient because of 7nm vs 5nm but if you scale it up to desktop frequencies it's going to consume the same amount of power as Ryzen CPUs.

Yes but the point is that Apple doesn't need to scale the M1 up to desktop frequencies, because it already is faster than x86 in single-threaded workloads, at lower clocks and significantly lower power. To scale up the multithreaded performance they just have to increase the core count and scale the cooling system accordingly, ie: exactly like you would have to for x86. A decent desktop cooler can dissipate enough heat to run CPU's with 100+ Watt TDP's, while the M1 in the current Mac Mini sits around ~20W estimated if you discount the RAM.

So again, what would make anyone think that an M1 with decent cooling would not be able to maintain the current ST performance indefintely, or a hypothetical 8+8 or even 16+16 core M1X or M2 with a TDP of 100W and top-notch cooling solution would be impossible?

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

#497
post #361

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…

How about compiling WebKit? https://techcrunch.com/wp-content/uploads/2020/11/webkit-com...

It's a shame we have a headline proudly announcing that the M1 is 2x faster, when the reality is it's about 8% faster when doing a similar real world test for longer.

What's also hugely impressive is that under better cooling conditions, it's also 25% faster.

None of these numbers capture headlines like 2x sadly, but that's still massively impressive.

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

#498
post #354

Earlier quoted context omitted.

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

I'm on a macbook pro 2019 16" and I don't want to post my results here...

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

#499

Anyone else worried that while these performance improvements are really good, that this is further locking people into Apple's ecosystem? No self-repairs, no bootcamp support, etc

Unless apple buys TSMC and every other digital foundry then yeah that's a distinct possibility. Otherwise no, there are many reasons to use a slower, outdated architecture whether for its open nature or support.

I feel bad for intel if anything. While they're not out, it doesn't bode well for their future.

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

#500

Earlier quoted context omitted.

Intel in 2020 is IBM in 1980.

No Intel is back to 2002 with it p4. Give them a year or 2 and they are back with a new cpu. Don't forget that they have enough in their r&d pockets.

Overlooking much of TSMC and Current Intel Fabs issues.
Post reply on HN