[HN Gopher] Apple Silicon M1: Black. Magic. Fuckery
___________________________________________________________________
Apple Silicon M1: Black. Magic. Fuckery
Author : singhkays
Score : 51 points
Date : 2020-11-24 19:36 UTC (3 hours ago)
(HTM) web link (www.singhkays.com)
(TXT) w3m dump (www.singhkays.com)
| kradeelav wrote:
| > looks at 2010 MBP that's working, but starting to have firefox
| issues.
|
| ... This may be the actual upgrade moment. I just hope time
| machine is compatible. likewise old (CS5) versions of Photoshop
| since I'm not into this subscription BS.
| brundolf wrote:
| > cries in 2020 MBP
|
| We may need to start a support group
| berkut wrote:
| I don't quite understand how 'retain' and 'release' can be more
| _memory_ efficient on Apple Silicon than x86.... I can understand
| how they can be more efficient from a performance standpoint in
| terms of more efficient reference counting, but I don 't
| understand how that translates to less memory usage which is
| apparently what's being argued... ?
|
| Unless on x86 some of the 'free's when the ref counts hit 0 were
| being batched up and deferred, and that doesn't need to happen
| now?
| Teknoman117 wrote:
| I read that as 'retain' and 'release' aren't more memory
| efficient on Apple Silicon, they're just faster due to hardware
| choices of some kind. The argument of memory efficiency is
| about reference counting versus garbage collection.
| saagarjha wrote:
| I believe it was being brought up as an example of "Apple has
| designed their hardware around their software" and then that
| translates to "Apple's software does well on machines with less
| memory".
| berkut wrote:
| Compared to something like Android, sure, I get that, but
| compared to ObjectiveC/Swift on x86 (which I think was being
| argued - i.e. against the Intel Macs)?
|
| I guess it makes reference counting in general more
| efficient, I'm just saying I don't see why that would mean
| Apple Silicon Macs running ObjectC/Swift code would have less
| memory usage than the same code compiled and running on x86.
| saagarjha wrote:
| I'm not necessarily convinced by the posted argument. That
| being said, I tend to think that people running a bunch of
| VMs and Electron apps and Docker cause them to use a bunch
| more RAM than I would consider to be "reasonable", and
| they've lost sight of how much you can do in a lesser
| amount of memory. (Typing this from a computer with 8 GB of
| RAM, which I have repeatedly been told is "below adequate"
| for development.)
| ianhowson wrote:
| I don't think retain/release perf has anything to do with
| memory consumption, but I _have_ seen a bunch of reviews
| claiming that 8GB is perfectly fine.
|
| This is fascinating to me, because:
|
| (a) every 8GB Mac I've used in the past has been unusably slow
|
| (b) since upgrading my 32GB Hackintosh to Big Sur, my usual
| 40GB working set is only about 20GB.
|
| (c) My 2015 16GB MBPr with Big Sur is also using about half as
| much physical memory on the same workload. Swappiness is up a
| little, but I haven't noticed.
|
| So my guess it that something in Big Sur has dramatically
| reduced memory consumption and that fix is being commingled
| with the M1 announce.
| jdminhbg wrote:
| iPhones and iPads also have relatively small amounts of RAM
| compared to Android devices in the same class, so I wonder if
| Apple is doing something smart with offloading memory to fast
| SSD storage in a way that isn't noticeable to the user.
| trevyn wrote:
| They stuff the reference count in the unused bits of the 64-bit
| pointers.
| berkut wrote:
| So just tagged pointers essentially? That's possible on x86
| isn't it (unless it's an endian-thing)?
| yardie wrote:
| I'm typing this from a 2014 i7-4980HQ 15" MBP. This machine would
| have been replaced in 2017 but I wasn't impressed with that years
| model. I had planned to upgrade in 2020 but the announcement of
| the M1 basically quashed that. I've been on this planet long
| enough to know when Apple changes course like this the old
| architect is already obsolete. 68k -> PPC -> x86_64 -> ASi. The
| PPC G5 got exactly 1 OS upgrade (10.5) before it was EOL'd.
|
| If the reports are to be believed on performance and Rosetta than
| this upgrade may be one of the smoothest in Apple history. The
| Intel CPU has had an incredibly long run, 15 years, at Apple. If
| they are confident they can make the leap and not leave their
| users in the lurch more power to them.
|
| I'm still on the fence on buying an M1 laptop. Apple users know
| you pay an Apple tax and a v1 tax. My MBP is getting so long in
| the tooth I may have to ignore my own advice of not getting first
| generation Apple hardware.
| supernova87a wrote:
| You know the thing I worry about next is: how are apps going to
| inevitably bloat in inefficiency and take claw back the
| improvements in CPU?
| singhkays wrote:
| I don't understand. Don't those two things seem antithetical?
| Like why would you make your app inefficient at the same time
| you optimize it for the CPU?
| Jtsummers wrote:
| https://en.wikipedia.org/wiki/Parkinson's_law
|
| Parkinson's Law: Work expands so as to fill the time
| available for its completion.
|
| Applied to computers, if you double the CPU speed, the
| program can be half as efficient with no apparent loss to the
| user. Similar with memory. If you can assume your typical
| gamer has a 2TB (or now much larger) storage capacity, you
| can ship a 250GB game. But then it gets complicated when
| _everyone_ does the same thing. If every program is half as
| efficient as it could be (in CPU usage or memory), then there
| has been no gain with the new system.
| sidpatil wrote:
| I think they're saying that devs won't spend as much time
| optimizing, since they know that the CPU is faster.
| singhkays wrote:
| That makes sense and is to be expected. A faster hardware
| does take away some of the incentive. As the old adage goes
| - "Necessity is the mother of invention"
| supernova87a wrote:
| Simple historical observation -- any time a performance jump
| happens, the underlying uses of it expand to fill up the
| improvement in processing.
| jonny_eh wrote:
| Are you suggesting that companies shouldn't make, and consumers
| buy, faster hardware?
| vmception wrote:
| weren't the old exploits on the intel processors patched by
| essentially making many operations slower? like they had to
| disable some cpu instructions which were previously innovative
| and this debilitated the irreparable processors.
|
| so a new architecture with better versions of the same
| instructions would feel very fast, since we went two steps back
| first.
| Areading314 wrote:
| Yes, these were due to the Spectre and Meltdown vulnerabilities
| qz2 wrote:
| Even as a miserable pessimist I just bought an M1 Mini today. It
| cost two months of train season tickets which I don't have to pay
| for any more!
| brundolf wrote:
| This is fascinating:
|
| > Retain and release are tiny actions that almost all software,
| on all Apple platforms, does all the time. ..... The Apple
| Silicon system architecture is designed to make these operations
| as fast as possible. It's not so much that Intel's x86
| architecture is a bad fit for Apple's software frameworks, as
| that Apple Silicon is designed to be a bespoke fit for it ....
| retaining and releasing NSObjects is so common on MacOS (and
| iOS), that making it 5 times faster on Apple Silicon than on
| Intel has profound implications on everything from performance to
| battery life.
|
| > Broadly speaking, this is a significant reason why M1 Macs are
| more efficient with less RAM than Intel Macs. This, in a
| nutshell, helps explain why iPhones run rings around even
| flagship Android phones, even though iPhones have significantly
| less RAM. iOS software uses reference counting for memory
| management, running on silicon optimized to make reference
| counting as efficient as possible; Android software uses garbage
| collection for memory management, a technique that requires more
| RAM to achieve equivalent performance.
| neilpanchal wrote:
| I just got one. I'm blown away by the speed as well. Chrome runs
| insanely fast! Alas, it's not developer ready yet. Brew is a
| mess. Docker doesn't work. PyCharm is WIP although can use x86
| version. I was skeptical of the hype but this little laptop has
| made me realize how slow everything else is.
|
| Unfortunately, while the hardware has accelerated far beyond
| expectations, the software - specifically MacOS BigSur is a major
| step backward. So many fucking animations. Everything feels fluid
| like operating in molasses. The UI changes seem to be shoe horned
| into a desktop that doesn't need giant white space for fat
| fingers. Menu bars are twice as tall taking up precious space.
| Top bar was already crammed with a lot of icons. Now, they've
| made them sparsely spaced by adding padding between the icons.
| Everything is baby-like with rounded corners and without borders.
| Segmentation UI elements are no more. I want to ask Apple's UI
| team: WHY!? What is currently wrong with macOS Catalina UI? Until
| you can satisfactorily answer that, there shouldn't be any
| change. Stop changing the UI like you're working at Hermes. It's
| not fashion. If the reason is to unify everything, all screen
| sizes, then you're sacrificing all three. Perhaps making it easy
| to develop apps for all 3 platforms is a plus, but as a _user_ ,
| this all feels like a regression. I've lost hope in modern UI
| engineering. It's not engineering anymore.
|
| I want macOS that has a UI of Windows 95. That would be totally
| insane on Apple Silicon.
| DennisP wrote:
| Ugh. Back in the 90s our supercomputers were way less powerful
| than today's laptops. I want to feel that. Never mind
| animations, just make everything happen instantly.
| fassssst wrote:
| Seems pretty obvious that some future Macs will have touch
| screens or larger iPads will run MacOS.
|
| I'd buy a Surface Studio style iMac in a heartbeat.
| robaye wrote:
| This was my thought too.
| goatinaboat wrote:
| _It's not fashion._
|
| Unfortunately you are wrong. Everything we call tech is in fact
| driven by fashion.
|
| My older version Mac is badgering me to upgrade to Bug Sur. Top
| feature: 100 new emojis. That is what Apple prioritised. Why
| the hell are emojis even part of the OS let alone its top
| feature!
|
| Truth is GUIs are done, were a decade or more ago. All there is
| left now is change for the sake of change. And Apple can't
| think of anything more to do in the real OS either!
| saagarjha wrote:
| https://www.apple.com/macos/big-sur/ says it's the new
| design.
| jrm4 wrote:
| At the risk of being that (Linux) guy --
|
| What is gained here if we're just still applying faster cycles to
| Apple-esque wasteful (and perhaps harmful, as we're apparently
| learning re: their telemetry) software?
|
| If people really dig their Apple stuff, great. But I think its
| worth thinking about the likelihood that a "slower" computer
| running Linux could probably serve the actual user better in
| terms of "getting stuff done." Moreover, I think we're pretty
| close to "beauty" parity here as well. Apple's advantage now is
| probably _mostly_ the networked devices, i.e. unity between phone
| and pc messages, etc.
| joshstrange wrote:
| > But I think its worth thinking about the likelihood that a
| "slower" computer running Linux could probably serve the actual
| user better in terms of "getting stuff done." Moreover, I think
| we're pretty close to "beauty" parity here as well.
|
| This is just not true. I'm sorry but I've used linux on the
| desktop many times, using many different distros, and many
| different desktop environments. It's shiny and pretty when you
| first install and then very quickly you run into apps that
| don't follow that design methodology and it takes you out of
| it. Desktop linux is not ready for average users and honestly
| it may never be. Also "getting stuff done." and desktop linux
| do not belong in the same sentence. I've personally spent and
| watched coworkers spend hours and hours tinkering with graphics
| cards drivers or other random quirks. Linux is amazing, don't
| get me wrong, it's a workhorse with immense power and the
| ability to tinker to your heart's content BUT most users,
| myself included, don't want to put in the upfront and ongoing
| work to keep it in tip-top condition.
|
| I will forever use linux on servers and enjoy every minute of
| it but for the desktop linux is nowhere near ready for
| primetime. I've watched too many people online and in-person
| preach about linux on the desktop and then watched them having
| to spend tons of time tinkering with it so they can "get stuff
| done". Is it possible to be productive on the linux desktop?
| Absolutely but I value my time way too highly to spend the
| effort to make that a reality.
| jozzy-james wrote:
| depends on what you do, for most people - chromeOS would be
| plenty fine for 'getting stuff done'
| sjmulder wrote:
| I found the macOS desktop much more responsive than GNOME which
| feels like a beast. Now I use MATE which is nice and simple but
| it's no where near as nice as macOS.
| sigzero wrote:
| I have never lacked for "getting stuff done" on a Mac.
| Jtsummers wrote:
| macOS has been my daily driver since 2006, fully since 2010
| (when I got rid of my desktop which I dual booted between
| Windows for gaming and Linux for development). It's perfectly
| suitable for "getting stuff done". In the rare case where macOS
| doesn't run something that I need that another *nix or Windows
| supports I spin up a VM or VPS.
| azangru wrote:
| Another linux guy here, on the market for a new linux laptop.
|
| After reading the article, which linux-compatible laptops,
| would you say, come the closest to compete with the new
| generation of Apple products? Long battery life, plenty of
| power, good screen, good speakers? Is it the inevitable Dell
| XPS 13 and Thinkpad X1 Carbon, or are there any other darlings
| among the linux community?
___________________________________________________________________
(page generated 2020-11-24 23:00 UTC)