3 ms·
The Nx architecture is quite good. I started work on a backend that avoids requiring jvm/bazel/python toolchain (substituting in a zig toolchain): https://git
by dnautics 6y ago
The Nx architecture is quite good. I started work on a backend that avoids requiring jvm/bazel/python toolchain (substituting in a zig toolchain):
https://github.com/ityonemo/ez https://github.com/ityonemo/ez
the two languages feel like they were made for each other. Despite the verbosity of doing some things in zig (the dynamic tensor broadcast function is a bit of a beast), due to both language's similar compile-time metaprogramming facilities, getting to the point of plugging in Nx's tensor addition + tensor multiplication is about 200 LoC.
- jeffreysmith 6y agoCool project. I'd never heard of Zig, but it looks like an interesting solution to the need you've identified. I'd definitely agree that it seems valuable to have an Nx version that comes with a smaller, simpler install for development purposes. XLA is amazing, but it's not obvious that you want to have that toolchain setup for local development in all scenarios. Would be great to see several different backends created for Nx as a way of exploring what feature sets are really needed and ensuring that the integration mechanisms are sufficiently simple and general to support multiple solutions.
- dnautics 6y agoWell another place is for elixir nerves. You probably don't want to figure out how to shipping the xla architecture to your embedded device (I think it has to JIT the code); with nerves you can trivially cross-compile the nif shared library with zigler and deploy to arm architecture. But kudos to José for building an architecture at a very good level of abstraction, you know, just in case xla falls out of favor (it is a Google project), nx won't have a hard dependency, and there will be trivial migration paths out. I think there could be some other interesting nx backends, like "remote computation", or "transpile elixir and run on a Julia worker node"