[deleted]
Apple Silicon M1: Black Magic Fuckery
251–260 of 1001 posts
Re: Apple Silicon M1: Black Magic Fuckery
#252Re: Apple Silicon M1: Black Magic Fuckery
#253Earlier quoted context omitted.
It’s pretty trivial to disable most animations (and more importantly transparency!). I’ve been doing that on new MacOS installs since Jaguar and it only takes a few minutes. If you want to move quickly you’re probably already using keyboard shortcuts and ignoring the dock and toolbars. For less technically adept users (ie. most users) the animations and spacings mostly seem to help them understand what’s going on. I…
The animations on the iPhone are what made me return to Android. On iPhones, you can only "reduce motion", which still has the "moving through molasses" feeling, replacing them with a fade in/out. Can you truly disable most animations in MacOS, or are they simply replaced with fade in/out animations?
Counter point: I only just noticed my iPhone animates things after I read this comment and went to find some.
Re: Apple Silicon M1: Black Magic Fuckery
#254This 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 i…
The bit about reference counting being the reason that Macs and iOS devices get better performance with less ram makes no sense. As a memory management strategy, reference counting will always use more ram because a reference count must be stored with every object in the system. Storing all of those reference counts requires memory.
A reference counting strategy would be more efficient in processor utilization compared to garbage collection as it does not need to perform processor intensive sweeps through memory identifying unreferenced objects. So reference counting trades memory for processor cycles.
It is not true that garbage collection requires more ram to achieve equivalent performance. It is in fact the opposite. For programs with identical object allocations, a GC based system would require less memory, but would burn more CPU cycles.
Re: Apple Silicon M1: Black Magic Fuckery
#255This is not only Apple. All modern mobile ARM processors, ones that are used in Androids, too, they all are far ahead of Intel in TDP to performance ratio, almost by order of magnitude. Just make bigger ARM chips with more high-perf cores, and they will destroy Intel.
Qualcomm hasn't been able to "just make bigger ARM chips with more high-perf cores" and destroyed Intel for many years now - and not for lack of trying to displace Intel in the laptop market. Same with other ARM manufacturers. Apple did something unique with M1. I don't know what it is but at their current rate of improving in-house silicon the M2 is likely to be the best performing single thread chip in the world regardless of company, architecture, or power envelope. And that's not done by being the same as everyone else except the clever idea to "just make it bigger".
Re: Apple Silicon M1: Black Magic Fuckery
#256Earlier quoted context omitted.
Someone please correct me for the sake of all of us if I’m wrong, but it sounds like Apple is using specialized hardware for “NSObject” retain-and-release operations, which may bypass/reduce the impact on general RAM.
I saw that point brought up on Twitter and I don't know how it it makes more efficient use of RAM. Specifically, as I understood it is that Apple software (written in objective C/Swift) uses a lot of retain/release (or Atomic Reference Counting) on top of manual memory, for memory management rather than other forms of garbage collection (such as those found in Java/C#), which gives Objective C programs a lower memory…
Tfa says the hardware optimization for ARC is to the point of being bespoken. Hardware will always beat software optimization. Further, the other GCs have much higher ram overheads than this combined, bespoke system.
Apple has decades of proven experience producing and shipping massively over engineered systems. I believe em when they say these processors do ARC natively.
Re: Apple Silicon M1: Black Magic Fuckery
#257For those of us who just don't where MacOS is concerned, what are the prospects for Linux on an M1?
Maybe better to wait for good ARM chips on a PC. Now that there is a demand for it, I'm sure some ARM vendor will step up if not Qualcomm
Re: Apple Silicon M1: Black Magic Fuckery
#258What does it mean to be an 8-core GPU? 8-CPU I can understand. But I thought GPUs were supposed to have a lot more cores for parallelism.
Re: Apple Silicon M1: Black Magic Fuckery
#259Earlier quoted context omitted.
Pretty sure you'll end up with exactly the same in an NSArray? ObjC is excellent but it's not doing anything fundamentally magic there
Theoretically Java should be more memory efficient because it makes fewer guarantees and can move memory around. The advantage of Swift/ARC is not that it uses less memory per se but that it has a lower high water mark because memory is freed much sooner.
> Theoretically Java should be more memory efficient because it makes fewer guarantees and can move memory around.
Java makes a lot of memory guarantees that are hard to make efficient. Specifically in that it becomes extremely hard to have a scoped allocation. Escape analysis helps, but the nature of Java's GC'd + no value types means it's basically never good at memory efficiency. Memory performance can be theoretically good, but efficiency not really. That's just part of the tradeoff it's making. And nearly everything is behind a reference, making everything far larger than it could be.
Compaction helps reduce fragmentation, but it comes at the cost of necessarily doubling the size of everything being compacted. Only temporarily, but those high-water spikes are what kicks things to swap, too.
Re: Apple Silicon M1: Black Magic Fuckery
#260Technology seems to swing like pendulum between running remote and running locally as technology evolves. Recently I purchased an RTX 3090, and between my Ryzen with 24 threads, and the 64 GB of memory I bought for a few hundred dollars it was really occuring to me how much power my PC has for really not that much money. I don't need to be spending so much cash on cloud services when my local machine has more than enough horses to do everything I need.
I think the M1 is one more force towards the pendulum swinging back. I suspect that as developers port applications to ARM people will rediscover the benefits of native installations as new software starts to take full advantage of this new hardware.