Live data from Hacker News

Apple M1 support for TensorFlow 2.5 pluggable device API

developer.apple.com

51–60 of 124 posts

Re: Apple M1 support for TensorFlow 2.5 pluggable device API

#51
post #41
post #5

M1 and AMD GPU support. I'm personally more interested in the latter as I haven't yet upgraded my MacBook Pro and I expect that my Vega 20 to be faster than M1 at ML training. The raw compute power of M1's GPU seems to be 2.6 TFLOPS (single precision) vs 3.2 TFLOPS for Vega 20. This can give you an estimate of how fast it would be for training. Just for reference Nvidia's flagship desktop GPU(3090)'s FP32 performance…

So Apple would need 16x its GPU Core, or 128 GPU Core to reach Nvidia 3090 Desktop Performance. Or roughly 480mm2 Die Size, 192W TDP excluding memory controller and interconnect. Doesn't look too bad for Nvidia, especially when you consider 3090 is still on Samsung 8nm, which is equivalent to TSMC 10nm, compared to 5nm on Apple M1.

This won't scale like this, also for deep learning CUDA and CUDNN will be still probably 2-5x faster then AMD/Metal drivers as was proven before (in case of AMD shitty deep learning drivers)

Re: Apple M1 support for TensorFlow 2.5 pluggable device API

#52
I'm still trying to find a way to monitor the Neural Engine on my Macbook air M1, but the APIs are non-existent, there's barely anything in the docs and no answer from Apple. My models train fast, 3x faster than most i7 computers with GPU, which is excellent for a fanless ultraportable computer but I wish Apple would treat the NE as a 1st class citizen on these machines, with Mac SDK APIs and usage visualization in the Activity Monitor.

Re: Apple M1 support for TensorFlow 2.5 pluggable device API

#53

I find the benchmarks confusing. If we normalize, is Apple close to beating Nvidia?

Not on M1. However as M1 is a chiplet design, it's pieces are stackable like legos (to some degree).

It is then supposed that with enough stacking, apple could get close to a dedicated GPU performance.

However this is speculative.

Re: Apple M1 support for TensorFlow 2.5 pluggable device API

#55
post #46

Earlier quoted context omitted.

`pip install --upgrade pip` fixed this for me. (not in tensorflow directly, but while installing something else on my M1 last week which required numpy)

OK, so we’re in mid-2021, why is installing Python THAT HARD? I think the only reason Node is so popular is because it JUST WORKS. Windows, Mac, doesn’t matter. One-click installer and you got NPM as well and access to thousands of packages.

While I don't think the problem is as bad as you describe, we should note that Node's initial release was in 2009, while python's was 1991. They pioneered a lot and Node was thus able to spring from quite hefty shoulders.

Re: Apple M1 support for TensorFlow 2.5 pluggable device API

#56
post #46

Earlier quoted context omitted.

`pip install --upgrade pip` fixed this for me. (not in tensorflow directly, but while installing something else on my M1 last week which required numpy)

OK, so we’re in mid-2021, why is installing Python THAT HARD? I think the only reason Node is so popular is because it JUST WORKS. Windows, Mac, doesn’t matter. One-click installer and you got NPM as well and access to thousands of packages.

As someone using nvm for work, I disagree. NPM can't be installed from normal package repositories, because it's outdated the moment any long-term support distribution accepts it. Then there's yarn, which is fighting for command line dependency management supremacy, with the exact same problem. I'm still not sure what npx does but I think it comes with NPM, unlike nvm which you use to manage NPM installs. I'm hoping I don't need to learn it because I expect some new javascript tool to replace NPM and yarn any day now, as those did bower and grunt before them.

I've also had to use nvm to install an old version of NPM for a specific project because otherwise one of the NPM dependencies couldn't compile a certain C++ executable that I apparently needed? There was also an incompatibility with some binary that another dependency downloaded that required me to mess with soft links to libraries in specific places.

I don't think either NPM or PIP are inherently hard to use as long as you keep them updated (which is exactly what the parent comment is suggesting to do) and as long as you don't need binary dependencies. When you end up in binary territory, which this type of software eventually will, you'll run head-first into stuff that requires arcane commands to get stuff to run.

Re: Apple M1 support for TensorFlow 2.5 pluggable device API

#57
post #22

Earlier quoted context omitted.

Kinda silly to use Rosetta when the whole point of this is native support for TensorFlow on M1.

Maybe, but lots and lots of software applications are not even close to being hardware constrained or in this specific case Rosetta constrained. If you're trying to get work done and you have the computational overhead available, this absolutely sounds like the right solution. Even if it's less efficient, I can easily imagine situations where "I need this to work without thinking about it" could win out.

Yeah I am not running code which is hardware constrained and numpy was a real doozy tto get working because of pep517. I found Rosetta pretty fast anyway. Certainly faster than my Ryzen 2600 on arch Linux at running the same code.

Re: Apple M1 support for TensorFlow 2.5 pluggable device API

#58
post #19
post #8

Earlier quoted context omitted.

I run everything python under Rosetta. Easiest way is to install home brew for Intel processors then make an alias to that version for managing rosetta stuff

> I run everything python under Rosetta. So basically the software that you require to run and do your work is still not available for Apple Silicon? In this case, Apple Silicon support for Python libraries. The whole point of Apple Silicon is to supersede its Intel Mac counterparts and to run software natively with a noticeable performance increase, especially with software with high performance requirements. In the…

There's no need to be so angry about a hypothetical situation in which you by a laptop that you never wanted. I just prefer simplicity right now. I'm a PhD student and I don't need the code to be super fastz just need it to work right now. As it stands j just got it all to run under native so I guess my slight modicum of patience you don't have lags dividends :)

Re: Apple M1 support for TensorFlow 2.5 pluggable device API

#59

https://github.com/tensorflow/tensorflow/releases/tag/v2.5.0 (Linked from Apple's article) Wow, that list of CVEs is 110 lines.

And it was released almost a month ago with the CVEs saying "these fixes will be backported to previous branches that are still supported" but releases for those branches haven't happened yet, so if you're on an older version and just want to get the security fixes you have a problem.

Re: Apple M1 support for TensorFlow 2.5 pluggable device API

#60
post #35
post #7

I have found the M1 air fine for web browsing but kind of hard to install software on. Following the instructions: ----- python -m pip install tensorflow-macos ... ERROR: Failed building wheel for numpy Failed to build numpy ERROR: Could not build wheels for numpy which use PEP 517 and cannot be installed directly ----- (base) dave@daves-air ~ % uname -a Darwin daves-air.lan 20.5.0 Darwin Kernel Version 20.5.0: Sat M…

I would love to hear more from other devs regarding where we're at with M1 for development. How is Node/React development, for example. Last I heard, Postgres was good to go on native M1. I know Node 14 is good natively. Are there commonly encountered problems? I hate my 2017 MBP and am desperate to upgrade.

Everything webdev works great, Docker is the only thing in my workflow that is still a bit of a hassle but that is quickly improving.
Post reply on HN