Live data from Hacker News

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

twitter.com

361–370 of 529 posts

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

#361

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…

How about compiling WebKit?

https://techcrunch.com/wp-content/uploads/2020/11/webkit-com...

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

#362
post #231

Earlier quoted context omitted.

> can't stick enough memory in one Sorely disappointed that the Mini is limited to 16GB. That alone makes it feel obsolete, because 16GB is the new 8GB with as much desktop virtualization I find myself doing.

I don't believe Air's M1 has any virtualization support at all.

It does. The developer kits, however, did not.

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

#363

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

Can’t you just instruct the compiler to compile for Intel on ARM and vice versa? We do this all the time, build ARM artifacts on an x86 CPU with GCC.

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

#364
The title is wrong. Tweet Author issued a correction - he tested an i7, not an i9:

"Ok twitter sucks for corrections BUT: The chip i tested is the: Intel 9750H and this is an i7 NOT an i9. However the single core compute is about the same, and i'm not maxing out on cores. So the ballpark speed increase is quite similar."

https://twitter.com/rikarends/status/1328796685280088065

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

#365
post #81

Earlier quoted context omitted.

Huh? Apple is quite the opposite of fanless... They have literally the most devoted fanbase among computer vendors.

They mean fans as in the spinning plasticky thing that goes vroom

That’s ridiculous people are not made out of plastic

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

#366
post #20

Does anyone know what the state of Linux on Mac is since the introduction of the T2 chip and now this? Do people still run Linux on Mac and how has the experience been?

Can't run Linux, can't run Windows 10 either - so it's not for me.

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

#367

Earlier quoted context omitted.

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

The only Zen 3 chips are desktop class, so Apple’s first generation ultra book oriented processor is trading blows with the best line of desktop processors. That’s a pretty big deal!

Note that apple has a process advantage here. AMD's 5nm chips will probably see a decent perf boost.

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

#368
post #357

Earlier quoted context omitted.

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.

People claim if you switch off to Safari the memory footprint goes down. Of course, if you're an FE dev, that comes with more ... challenging ... dev tools. YMMV.

I run Slack as a tab in Safari because it avoids the pain of running the electron app, and reduces my memory footprint.

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

#369
post #9

The real competition is no longer Intel. Its AMD. Or if you're just buying Apple because you like them then there is no competition, you buy what they offer. I like fanless systems so I'll be watching Apple closely.

I can't help but chuckle whenever I read these comments on HN about how doomed Intel is. Intel just does this . Every now and then, they get so far ahead that the rest of the market just totally disintegrates, which allows them to screw around and juice up their margins while failing to actually innovate. Their brand is so strong it takes years for it to erode, even when they do suck, and when they have actual compet…

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.

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

#370
post #338

Earlier quoted context omitted.

Couldn't Intel just come out with a new set of reduced-complexity instructions that run on a per-process basis based on some bit being flipped on context switches? Then legacy apps would run fine, but the new stuff would work too. This seems not that hard to address.

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.
Post reply on HN