Earlier quoted context omitted.
I use an M1 powered 16GB MacBook Air and I've never seen any freezing, even under heavy load. I don't use Google Chrome though. Also, system is writing to the SSD with the same rate of my Linux machines: 4TB/year.
Heavy load in my case is a few dozen terminal tabs, six of which are running TPU training jobs, 40 chrome tabs, a few of which are playing twitch streams and YouTube videos, a half dozen instances of pycharm, one webstorm, one clion, around 35 macvim windows, and a few dozen PDFs open in Preview. I’m not exactly representative, but I think the stddev of usage patterns is high across developers. The unfortunate part i…
Apple’s M1 Positioning Mocks the Entire x86 Business Model
881–890 of 942 posts
Re: Apple’s M1 Positioning Mocks the Entire x86 Business Model
#882Earlier quoted context omitted.
Apple’s goal is to eliminate technical specifications from marketing: tech specs are an excuse - make it good enough that few care what those specs are.
I can't think of a technological product where that mentality applies. Can you? In fact, it seems that the opposite is true; as a product gets better, people care more about the specs. Whether you're buying a Wusthof knife or a luxury car, you want to know what makes the product good enough to justify its price and position in the market.
Insofar as people do consider specs, it’s usually because the specs are injected into the conversation, customers being taught to care by salesman trying to baffle them into choosing their product.
Most customers want it to just work. Apple is pursuing that.
Re: Apple’s M1 Positioning Mocks the Entire x86 Business Model
#883Earlier quoted context omitted.
I don’t think “impressive iteration” begins to describe it. I am very rarely impressed by new tech these days, and the M1 is the first piece of new hardware I’ve seen in years that seems downright magical. My previous laptop was a 2016 MBP with an i7, and the M1 destroys it. I can build large projects like LLVM or WebKit fast and it doesn’t even get hot. I’ve also been running Linux VMs with the new Parallels and the…
It's not a helpful comparison if you compare a chip from 2016 with a chip from 2020. You would need to benchmark it against a current chip from someone else.
Re: Apple’s M1 Positioning Mocks the Entire x86 Business Model
#884Earlier quoted context omitted.
Is the the 8GB model? I had the same issue with my workload and found that it was always under high memory pressure, upgrading to a 16GB model fixed it for me.
It’s the 16GB. The memory pressure is indeed the issue. I find it hilarious that Apple accidentally inverted their LRU into an MRU and constantly swaps for no reason, yet it’s still so fast that nobody even noticed during QA. Mine has already read/wrote 48TB in the first three weeks; at this rate the SSD will be dead in three years. (If you haven’t looked into SSDGate yet, be sure to check your smartmon to see whethe…
Re: Apple’s M1 Positioning Mocks the Entire x86 Business Model
#885Earlier quoted context omitted.
> I've always thought Intel's marketing was a bit confused - i7 stays the same over 10+ years I think that is because the performance has been the same for the past 10+ years.
I am continually astounded that the quad core sandy bridge core-i7 I bought in January 2011 is still completely serviceable for pretty much all tasks outside of gaming. The bezel and overall form factor is clownishly large by todays standards, and the screen is starting to look a bit faded, but as a portable but mostly stationary PC it still works great alongside my main laptop I use for work. I knew back in 2011 I w…
Re: Apple’s M1 Positioning Mocks the Entire x86 Business Model
#886Earlier quoted context omitted.
Heavy load in my case is a few dozen terminal tabs, six of which are running TPU training jobs, 40 chrome tabs, a few of which are playing twitch streams and YouTube videos, a half dozen instances of pycharm, one webstorm, one clion, around 35 macvim windows, and a few dozen PDFs open in Preview. I’m not exactly representative, but I think the stddev of usage patterns is high across developers. The unfortunate part i…
This is heavy load for any machine unless it's configured as a bona fide workstation. Any machine, any OS (with M1 MacBook Air's HW configuration) would trash its SSD while swapping in that case, IMHO. > I’m not exactly representative, but I think the stddev of usage patterns is high across developers. When I'm in development mode with all cylinders firing, I have a single Eclipse window in CDT perspective, a couple…
Re: Apple’s M1 Positioning Mocks the Entire x86 Business Model
#887You get an M1 with the new iPad Pro as well! I hadn't thought of the situation as the article presents. When shown in that light, it made me pause to reflect. The M1 doesn't make sense when its in every darn product. The only differentiator is screen size, RAM, and OS? I will admit that I switched to Thinkpad and Win10 about two years ago when I had to return my butterfly for the 5th time. I am not looking back eithe…
> The only differentiator is screen size, RAM, and OS? I think that's the point. Until now, buying a computer has always been focused on the CPU and RAM stats. If you wanted faster/bigger you had to spend more. With Apple's new strategy you almost don't even care about CPU/RAM stats. They are focusing on providing value in other ways; larger screen, lighter weight, different colors, more ports, etc. I think this is t…
Re: Apple’s M1 Positioning Mocks the Entire x86 Business Model
#888Earlier quoted context omitted.
This is heavy load for any machine unless it's configured as a bona fide workstation. Any machine, any OS (with M1 MacBook Air's HW configuration) would trash its SSD while swapping in that case, IMHO. > I’m not exactly representative, but I think the stddev of usage patterns is high across developers. When I'm in development mode with all cylinders firing, I have a single Eclipse window in CDT perspective, a couple…
Thrash is an odd word for an SSD... I mean, there's no moving parts, so I can't imagine how it's thrashing about.
Re: Apple’s M1 Positioning Mocks the Entire x86 Business Model
#889Earlier quoted context omitted.
The CPU microarchitecture is truly a quantum leap ahead of x86 processors. The fixed-width nature of arm instructions means there's way more front-end bandwidth for decode, which can then feed a much larger out-of-order engine. Having memory so close is also a huge win. TBH, I don't know what wizardry they have managed to get power consumption so low, but wow. 15W TDP and trouncing desktop processors pulling 12x that…
That is the talk yes, but we don't know how much of the actual performance improvements is simply due to the lower process size. And process size is independent of if it is ARM or x86, but instead depends on manufacturers getting production slots in the chip foundries. Currently Apple is hogging up all the production capabilities of the smallest process that TSMC have.
Neither of those would get x86 anywhere close to m1 in either performance or power consumption.
Re: Apple’s M1 Positioning Mocks the Entire x86 Business Model
#890Earlier quoted context omitted.
The CPU microarchitecture is truly a quantum leap ahead of x86 processors. The fixed-width nature of arm instructions means there's way more front-end bandwidth for decode, which can then feed a much larger out-of-order engine. Having memory so close is also a huge win. TBH, I don't know what wizardry they have managed to get power consumption so low, but wow. 15W TDP and trouncing desktop processors pulling 12x that…
micro architecturally is M1 really a leap? In terms of decoding bandwidth I'm not sure how many instructions it can actually sustain but it's not like it's 10x - M1 is a basically a very wide version of a tried and tested formula rather than a wholely new thing.
ARMs all 32-bit instructions make the decoder trivial in comparison. To parallelize 10kb worth of instructions across 8 decoders means read 32 bytes into the decoders, jump 32 more bytes and do it again (yes, it’s slightly more complex than that, but not too much).
x86 instructions are 1-15 bytes. How do you split up to ensure minimal overlap and that one decoder isn’t bottlenecking the processor? How do you speed up parsing one byte at a time? uOp cache and some very interesting parsing strategies help (there’s a couple public papers of those topics from x86 designers). They can’t eliminate the waste or latency issues though.
What is amazing to me is their efficiency despite the limitations. When you look at their massive 64-core chips and account for all the extra cache, IO, and interconnect necessary, it seems like scaling up the M1 to those levels would result in a less power efficient chip by (20% or so).