I guess their argument is the reason those things suck is because they are hooking in some c++ monstrosity (tensorflow) or making rpcs to an external daemon (redis, horovod).
So rather than writing another Python wrapper over c++ they are making a new performant language that can call Python.
To me it makes sense as torch is great and hard to compete with, but everything feeding into it is a mess today (Data loading, distribution logic).
don't forget the control layer/data layer separation principle. Performance mostly only matters at the data layer, and I don't believe that python ML really has a substantial problem with this, aside from not having a real distribution story. So "having a more performant python" doesn't really solve that much.
I'll tell you what could make the control layer better.
- no gil
- better async primitives
- immutability of passed parameters
- better testing story
- better documentation story (python is quite good at documentation, well, when python devs actually do it, which they usually don't).
Could you explain or give references to what you exactly mean by this? I've heard of separation of concerns, but is this a specific realization of that principle?
So rather than writing another Python wrapper over c++ they are making a new performant language that can call Python.
To me it makes sense as torch is great and hard to compete with, but everything feeding into it is a mess today (Data loading, distribution logic).