Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Apple’s M1 Positioning Mocks the Entire x86 Business Model

extremetech.com

Post reply on HN
Print view View original

821–830 of 942 posts

Re: Apple’s M1 Positioning Mocks the Entire x86 Business Model

#821

Post by skohan »

slver wrote: post #448
astrange wrote: post #335

Earlier quoted context omitted.

That's right. M1 doesn't have specific Objective-C optimizations.

An interesting realization that it could, though. Overwhelming majority of MacOS/iOS software is written on Obj C and Swift, which have the same underlying semantics. That said ARC doesn't have such a great impact on performance as some people (esp. fans of Java's GC etc.) would convince you. Most ++/-- operations on the refcount are eliminated by the compiler.

The worst case performance is very bad though. I have done some playing around with pushing Swift in terms of performance, and it's very hard because of ARC.

Re: Apple’s M1 Positioning Mocks the Entire x86 Business Model

#822

Post by rualca »

kevin_thibedeau wrote: post #758
brewdad wrote: post #634

Earlier quoted context omitted.

The other main improvement in the past 10 years is the power draw. You can get more than 10 hours of battery life in a machine that weighs less than 3 lbs. That would have been unthinkable a decade ago. CPU improvements are only part of the story in making that happen but the are certainly far ahead of where things were in the not so distant past.

10 hour battery life was achievable 15 years ago on Pentium M provided you under-volted, under-clocked, and had a high capacity battery.

> (...) provided you under-volted, under-clocked, and had a high capacity battery.

The fact alone that you're talking about using/adding a nonstandard and exceptional battery is more than enough to throw out that claim.

Re: Apple’s M1 Positioning Mocks the Entire x86 Business Model

#823

Post by rualca »

kevin_thibedeau wrote: post #807
edvinbesic wrote: post #774

Earlier quoted context omitted.

How far does this goalpost go?

The point is that the technology for long life laptops has been ready for a long time. It's just that Intel marketing calls all the shots and they only wanted to sell multicore space heaters with space heater memory to sweeten the deal. With this burden on chipset side, it was impossible to compensate with extra amp hours and maintain portable weight.

> The point is that the technology for long life laptops has been ready for a long time.

You're desperately moving the goal post to ridiculous places. It's like claiming that walking on the moon is supposed to be considered normal just because the technology has been ready for a long time.

That claim is irrelevant, isn't it? I mean, what good does a "technically it's possible" claim do if a) no, it's clearly not possible outside exceptionally rare circumstances b) the average consumer device is way behind any of those outlandish claims.

Re: Apple’s M1 Positioning Mocks the Entire x86 Business Model

#824

Post by bredren »

smolder wrote: post #797
bredren wrote: post #359

Earlier quoted context omitted.

I had wondered what their first Apple Silicon powered data center would be. I thought the company would wait and deploy a later gen chip. Though with the standardization of M1 across such a wide array of products makes me think it is going to be the M1.

Given the competition for fab capacity at TSMC, I'm not so sure Apple would want to use that capacity to supply servers. If things were less tight in that department I'd agree the time is right.

I can see this playing into the constraints, to this end, perhaps there is efficiency to making the most out of a single system type and assembly?

Also do you know how many machines it would take to outfit a reasonable demonstration scale facility?

Is that number so large that it constrains the ability to just go that much further?

Re: Apple’s M1 Positioning Mocks the Entire x86 Business Model

#825

Post by ThrowawayR2 »

baybal2 wrote: post #653
stjohnswarts wrote: post #606

Earlier quoted context omitted.

Trust me, it does not have 40 years of architectural advantage, just an advantage. It's not going to take Intel "40 years to catch up" give me break. I have an M1 mini anad it's a great little desktop machine for browsing and light development but it's not 40 years ahead of intel.

This is not the point. 40 years of architectural advantage is X86 electing to forego results of 40 years of advances, and improvements that every other sane ISA had, and instead trying to add them by increasingly complex "workarounds." Giant transistors counts go to allow X86 cores to not to break ISA compatibility with a 40 years old chip, while trying make new ISA features to live along with it.

Nope. If that were actually true, Alpha, PA-RISC, UltraSPARC, or even Itanium would've killed x86 earlier.

Re: Apple’s M1 Positioning Mocks the Entire x86 Business Model

#826

Post by spurgu »

spurgu wrote: post #816
mvanbaak wrote: post #814

Earlier quoted context omitted.

That’s a personal preference thing. Personally I think chrome UI/UX is horrible and slow. Ut I’m a safari user so again: personal preference.

Sure, I've never used Safari enough myself to have an opinion (since it's never been an option for me due to various things), it might be equal to Chrome or even better (I like Safari's clean UI). I'm mostly comparing it to Firefox which is quite clunky in my opinion (I've given it many chances). And I'm actually typing this on Safari now and it looks like the issue has been fixed - Bitwarden now works in private mod…

Whoa.

Maybe an hour into testing Safari and I look at Activity Monitor and see that https://calendar.google.com is consuming 1 GB of RAM and https://docs.google.com 865 MB. :o

Don't know if the numbers are comparable but in Chrome's Task Manager the numbers are 224 MB and 121 MB respectively.

Edit: This might be an old (unfixed) issue https://discussions.apple.com/thread/6640430 ... This sucks because I have a specific doc and the calendar that I always keep open in pinned tabs. There are some other sites with seemingly quite high RAM usage as well. Well at least nothing is lagging so I guess I'll just chug on and see what happens.

Edit2: This behavior is just insane. I closed those two tabs and suddenly Gmail shoots up from out of the blue to 1.22 GB?! Then I reopen the two previous tabs (doc/calendar) again and Gmail stays the same while Calendar goes on a diet and sits at 187 MB (doc at 983). This is super weird. I'll just keep them open and see how it behaves overall, might just be wonky numbers?

Re: Apple’s M1 Positioning Mocks the Entire x86 Business Model

#827

Post by baybal2 »

ThrowawayR2 wrote: post #825
baybal2 wrote: post #653

Earlier quoted context omitted.

This is not the point. 40 years of architectural advantage is X86 electing to forego results of 40 years of advances, and improvements that every other sane ISA had, and instead trying to add them by increasingly complex "workarounds." Giant transistors counts go to allow X86 cores to not to break ISA compatibility with a 40 years old chip, while trying make new ISA features to live along with it.

Nope. If that were actually true, Alpha, PA-RISC, UltraSPARC, or even Itanium would've killed x86 earlier.

All of above were beating X86 on transistor count/performance for their time. Beating X86 on that was their very point.

Their commercial demise had nothing to do with their hardware.

Re: Apple’s M1 Positioning Mocks the Entire x86 Business Model

#828

Post by foobiekr »

zerkten wrote: post #549
oblio wrote: post #484

Earlier quoted context omitted.

> This makes M1 type chips really interesting for any manufacturer who want to make devices that span a huge scale of performance requirements, from slow kiosks performance range to the decent laptop range. This is purely theoretical. Apple will > sell its chips to other companies. So if you were expecting Apple Silicon on its own to start a revolution, that's never going to happen.

The poster stated "M1 type chips". That is not setting an expectation that Apple will sell their chips. Microsoft already have a Surface product with an ARM chip that didn't get updated in this round AFAIK. It already has solid ARM performance, but it's not as good as M1. It was let down with how well x86 emulation worked, but there seem to have been improvements including x64 support. If they focused on improvements…

While a lot of the M1 advantage over Intel and AMD is process node, the advantage over the rest of the ARM and RISCV ecosystem is substantially more than that.

The team that built the M1 is a collection of top tier ASIC designers that came from several acquisitions, from PA Semi forward. The Qualcomms and Caviums and so on just aren't in the same league. Lord spare me another tarball of garbage and random kernel patches called an "SDK." They don't really have the same bench and don't pay top dollar and it shows.

It is unlikely that there will be an M1 equivalent from any of those guys. Intel? AMD? Absolutely.

Re: Apple’s M1 Positioning Mocks the Entire x86 Business Model

#829

Post by foobiekr »

skohan wrote: post #821
slver wrote: post #448

Earlier quoted context omitted.

An interesting realization that it could, though. Overwhelming majority of MacOS/iOS software is written on Obj C and Swift, which have the same underlying semantics. That said ARC doesn't have such a great impact on performance as some people (esp. fans of Java's GC etc.) would convince you. Most ++/-- operations on the refcount are eliminated by the compiler.

The worst case performance is very bad though. I have done some playing around with pushing Swift in terms of performance, and it's very hard because of ARC.

Code in the fastpath must not generate substantial garbage whether using ARC or a gc. That's just a coding error.

Re: Apple’s M1 Positioning Mocks the Entire x86 Business Model

#830

Post by scoopertrooper »

hiq wrote: post #564
scoopertrooper wrote: post #307

Earlier quoted context omitted.

I'm typing this response on a 8GB M1. It's great, but its no magic. Its limitations do start to show in memory intensive and heavily multi-threaded workloads. Getting some down votes, which I attribute to reasonable skepticism, so hopefully this will allay your concerns. https://ibb.co/VM4Z1DY

> memory intensive and heavily multi-threaded workloads Such as?

One example, I was trying download all the dependencies for the Kafka project via Gradle with IntelliJ while watching a video on YouTube and working on another project in Visual Studio Code. The video started to stutter then stopped and Visual Studo Code became responsive. I basically had to shut a bunch of stuff down and go to lunch.

I haven't seen a modern computer struggle with that kind of workload before.

Post reply on HN