When Apple releases a MacBook Pro with 64GB of unified memory (assuming they will) — won’t that be amazing for machine learning? I am under the impression that GPU memory is a huge factor in performance. Also, is there any way that the neural engine can accelerate training — or is it just for executing trained models faster?
Apple Silicon M1: Black Magic Fuckery
91–100 of 1001 posts
Re: Apple Silicon M1: Black Magic Fuckery
#92Earlier quoted context omitted.
I know it's a fast Arm CPU - I've read the Anandtech analysis etc - and that there is lots of extra hardware on the SoC. But the specific point was why is it a Swift machine. What makes it particularly suited to running Swift?
The exact reason is out of my depth, but the original quote makes it clear that there is something. Memory bandwidth would be one possibility.
1. "weak" memory ordering (atomic Aquire/Release loads/stores)
2. low memory latencies between cache and system memory (so dirty pages in caches are faster updated etc.)
3. potential a coherency impl. optimized for this kind of atomic access (purely speculative: e.g. maybe sometimes updating less then a page in a cache when detecting certain atomic operations which changed a page or maybe wrt. the window marked for exclusive access in context of ll/sc-operations and similar)
Given that it's common for a object to stay in the same thread I'm not sure how much 2. matters for this point (but it does matters for general perf.). But I guess there is a lot in 3. where especially with low latency ram you might be able to improve performance for this cases.
Re: Apple Silicon M1: Black Magic Fuckery
#93Re: Apple Silicon M1: Black Magic Fuckery
#94Re: Apple Silicon M1: Black Magic Fuckery
#95At 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 d…
> 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 y…
I'm using Fedora 33 on my personal laptop with nvidia drivers. And never needed to install any drivers for my work laptop.
Upgraded both laptops 3 times from Fedora 30 without a hitch.
And it's a one step process using a graphical interface [1].
What I'm saying is that (in my own experience), linux of today is very different from linux of 10 or 20 years ago. I've had my share of problems before, installing drivers for graphic cards and modems back in the "00"s but I think that most linux distros have come a long way since then.
Linux may not be the best choice "getting stuff done" for an average user. But, from my own experience, for a software developer it's a good choice. And in the company I work for, most developers have hp elitebooks with fedora installed. (I'm picking software developers for the comparison because they represent a significant portion of macbook pro users).
[1]: https://docs.fedoraproject.org/en-US/quick-docs/upgrading/
Re: Apple Silicon M1: Black Magic Fuckery
#96You know the thing I worry about next: how are apps going to inevitably bloat in inefficiency and claw back the improvements in CPU?
Are you suggesting that companies shouldn't make, and consumers buy, faster hardware?
If consumers are replacing their computers to do things they couldn't do ten years ago, then great, that's a good use of resources!
If consumers are replacing their computers because today's IM clients are 10x slower than the perfectly good clients we had ten years ago, that's a problem!
Re: Apple Silicon M1: Black Magic Fuckery
#97I 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 batc…
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 physic…
Re: Apple Silicon M1: Black Magic Fuckery
#98Re: Apple Silicon M1: Black Magic Fuckery
#99I know very little, so perhaps someone could enlighten me. But I am curious how Apple Silicon will be for machine learning. When Apple releases a MacBook Pro with 64GB of unified memory (assuming they will) — won’t that be amazing for machine learning? I am under the impression that GPU memory is a huge factor in performance. Also, is there any way that the neural engine can accelerate training — or is it just for ex…
I think Apple is aiming more at either training small models, or running pre-trained models. For example Photoshop is starting to integrate neural filters, so NN inference performance can be important for some desktop applications.
Re: Apple Silicon M1: Black Magic Fuckery
#100This 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…
How does this work? Isn't reference counting a lot of +1 and -1?