-
Notifications
You must be signed in to change notification settings - Fork 50
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
MLX - potential adoption? #719
Comments
Very interesting, thanks for sharing @lucascolley. It looks reasonably close, since it's modeled on NumPy. There hasn't been any discussion about it yet. Based on the issues, which were all opened in the last 24 hours, this was just publicly launched. The thing that stands out to me is unified memory, allowing execution on GPU without having to move the data. That's a very interesting capability, which may also have impact on the UX of the library. |
It looks like the biggest issue is that it doesn't have
So there are also some missing functions and methods, and some places where they use numpy names instead of array API ones. |
Yes if they use Metal then they have very limited support for numerical types (ex: no double) |
I wonder if we should have more concessions for missing dtypes. The standard says they all have to be implemented but in practice quite a few libraries or devices are missing some (at any rate, even if we don't change the spec, the test suite should be lenient about this). |
Aren't we (@oleksandr-pavlyk) already pushing for missing dtype support? What's missing that we haven't captured? I am aware we still need one or two PRs to finalize it. |
Thank you for bring the new array library to our attention, @lucascolley, though I don't think there's anything actionable on our (Data API Consortium) side. @lucascolley if you can bring array API standard to the MLX folks attention, it'd be great. (Even better is to have an MLX person come and share their feedbacks with us, should they consider adopting the standard.) I suggest to close this issue and move the remaining discussions (test updates, missing dtypes, ...) to perspective issues. |
I don't think there's an issue for it yet (there's #672 but that's a little different). |
👍 for continuing the discussion around missing dtypes (probably in #640). PyTorch has the MPS device, which lets you use the GPU builtin to modern MacBooks and there you already have the issue of missing I think the idea of unified memory is something we should get used to and think about, in terms of what this means for the Array API standard. The result of thinking and coming to a conclusion on this would probably be a few edits to https://data-apis.org/array-api/latest/design_topics/device_support.html |
Yes, the reality is that some implementations may not provide support for certain data types mandated by the standard, be it for a particular class of devices (MPS, or The standard should not consider such data type support gaps violations of the spec in my opinion, but must equip end-users with ways to check for required support. In case of |
👍 (see ml-explore/mlx#48 for further updates) |
https://github.com/ml-explore/mlx
How close does MLX look to the standard? Has there been any discussion about this so far?
The text was updated successfully, but these errors were encountered: