3 ms·
> create something radically more power efficient Lots of the M1's efficiency comes from business decisions. Apple chooses to use an expensive, low clock TSMC
by brucethemoose2 3y ago
> create something radically more power efficient
Lots of the M1's efficiency comes from business decisions. Apple chooses to use an expensive, low clock TSMC node. They use a lot of expensive die area on wide cores and cache, so they can keep clocks and voltages (relatively) low. And they use packaged memory for efficiency, but at higher cost and with no modularity.
Not saying it isn't a great design, but Intel/AMD could make a far more efficient CPU if they had the right market incentives to try. We have already seen a hint of this with Van Gogh (the Steam Deck chip) and their rumored "premium" laptop chips with big GPUs and an M1 Pro-like memory bus.
- tracker1 3y agoI don't know enough technically to comment on, but am curious how this plays into the mobile gaming device SOC/CPUs from AMD. I can say, really like my M1 air, generally good enough battery life and great i/o responsiveness in general. Of course, then I price out a M2 mini, and once I add enough storage/ram it's no longer feels worth the price. Why they even sell a model with under 512gb storage or 16gb memory other than to have a lower "starting from", and even getting to 1tb disk and 16gb or 32gb memory already feels like way too much of a price hike.
- brucethemoose2 3y ago> mobile gaming device SOC/CPUs from AMD There are none! Van Gogh (in the Steam Deck) was the first and last one! AMD had a whole family of low power (~9W), graphics heavy chips on their roadmap... And when the time for the first one came, not a single laptop maker picked it up. So AMD seemingly canceled the line, but Valve swooped in and used the only survivor in their handheld. What you see in the ROG Zephyrus and such are rebranded high power laptop chips, which is why they suck so much battery compared to the Steam Deck (even though the Deck chip is much older).
- vlovich123 3y agoA not insignificant part comes from the fact that they can better parallelize instruction decoding because ARM is simpler and more regular than x86. x86's compressed variable length representation hurts it here. They try to make up for it but there's meaningful benefit from Apple's approach. The other bit is that ARM concurrency is better aligned with how HW wants to work/better able to optimize performance than x64 is (ability for acquire/release semantics vs sequential) That being said, it's not like we're talking about deprecating that part of the instruction set which they really should do (i.e. build your application for x64.risc which tells the CPU the instruction set is going to be an alternate fixed-representation x64). Could maybe even have a special instruction where you can switch out of it temporarily so that you have back-compat with normal assembly to give software writers time to port. I'm all in favor of this though. Getting rid of cruft that's more than 20 years old is well beyond time.