3 ms·

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 (re

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).

throwawaymaths 3y ago
> a new performant language that can call Python 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). - project-local dependencies with no shenanigans
- itissid 3y ago
  > control layer/data layer separation principle 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?
  - throwawaymaths 3y ago
    Ugh. I misremembered terms. Look up control plane and data plane. This is well understood.