You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Do you think it would be possible to make arrayfire optional? The benefits of arrayfire are enormous, but it also seems like a huge handicap that anyone using the crate will be forced to download and install the arrayfire binaries. This also means that if I use mushin in my crate, my crate will also dependent on arrayfire, which is kind of a turn off.
I guess making it optional would require making several versions of all operations and complicating the code with some abstraction over arrayfire/alternative, which would be a lot of work.
The text was updated successfully, but these errors were encountered:
Hey! As you say it is going to be a bit of pain indeed to make that abstraction but it might be worth it.
Also if we choose the right alternative we might be able to have this crate to be #![no_std] compatible. What would you propose as an alternative to arrayfire?
My first suggestions for an alternative would be ndarray. It's purely CPU (I think?), but i don't know any non-CPU solutions that don't require external software.
I've used it for my own neural networks and it's great to work with.
I want to first make a few improvements to get to something really usable in ML, like adding optimisers and parameter freezing, but once I get to that MVP for sure I will look into making the underlying "array" library replaceable with most probably ndarray as default.
Do you think it would be possible to make arrayfire optional? The benefits of arrayfire are enormous, but it also seems like a huge handicap that anyone using the crate will be forced to download and install the arrayfire binaries. This also means that if I use mushin in my crate, my crate will also dependent on arrayfire, which is kind of a turn off.
I guess making it optional would require making several versions of all operations and complicating the code with some abstraction over arrayfire/alternative, which would be a lot of work.
The text was updated successfully, but these errors were encountered: