6 ms·

Are you afraid that you're going to "inherit" the issues the python ecosystem has through your goal of full compatibility? Or is Mojo more like Numba, in that o

by Sukera 3y ago

Are you afraid that you're going to "inherit" the issues the python ecosystem has through your goal of full compatibility? Or is Mojo more like Numba, in that only parts of python will actually be supported for full acceleration? At least your docs[1] seem to say so.. -- [1]: https://docs.modular.com/mojo/why-mojo.html#intentional-differences-from-python https://docs.modular.com/mojo/why-mojo.html#intentional-diff...

throwawaymaths 3y ago
Agreed. I think this effort is completely missing the real pain points that ML suffers from. While python the language is easy, and in many ways great for its original purpose as a teaching language, I'll take note of the few ways that Python ML suffers: - pip hell. Really, having globally installed dependencies was great for the 90s and is terrible now that disk space is more or less a non-issue relative to dependencies. Venv/conda which do sneaky things e.g. with your shell is super dangerous (https://twitter.com/garybernhardt/status/1653171980483575808 https://twitter.com/garybernhardt/status/1653171980483575808), and a misstep can trash your system especially when it has to deal with wheels with system-level dependencies (looking at you, tensorflow -- probably half of the reason why people moved to pytorch). Poetry sounds nice. It's been a while since I've checked in with the python ecosystem. Are ML people using that yet? - Subpar deployment. Let's remember that Containerization basically exists because Python does not have an ops story. - Subpar integration with web. You are forced to either create a microservice, or, spin it up within Django (nobody really does this). Then you typically have to pull in a bunch of sidecar processes (Redis, Celery, etc.) just to get queuing of your web jobs correct. - Poor concurrency. Sure, you can run your tensorflow code in an awkward 'with' statement but I think there are very few ML practicioners who could really explain to you what that with is doing. That GPU is actually fundamentally an asynchronous entity. And god help you if you want to run and debug async python. - No distribution story. Sure, the big guys are able to spin up, e.g. Horovod, but it's not really a thing for someone with less resources for a hot second on a few machines, and again, god help you if something goes wrong and you need to debug it. Does Mojo solve any of these issues? From a cursory look, it looks like no.
- qumpis 3y ago
  Poetry and pipenv seem to be quite popular among ML researchers, especially those who care about reproducibility.
  - int_19h 3y ago
    For DS/ML, Conda is probably used more often than everything else combined.
  - freilanzer 3y ago
    I use pyenv and poetry.
- cavisne 3y ago
  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?

by Sukera 3y ago

throwawaymaths 3y ago

Agreed. I think this effort is completely missing the real pain points that ML suffers from. While python the language is easy, and in many ways great for its original purpose as a teaching language, I'll take note of the few ways that Python ML suffers: - pip hell. Really, having globally installed dependencies was great for the 90s and is terrible now that disk space is more or less a non-issue relative to dependencies. Venv/conda which do sneaky things e.g. with your shell is super dangerous (https://twitter.com/garybernhardt/status/1653171980483575808 https://twitter.com/garybernhardt/status/1653171980483575808), and a misstep can trash your system especially when it has to deal with wheels with system-level dependencies (looking at you, tensorflow -- probably half of the reason why people moved to pytorch). Poetry sounds nice. It's been a while since I've checked in with the python ecosystem. Are ML people using that yet? - Subpar deployment. Let's remember that Containerization basically exists because Python does not have an ops story. - Subpar integration with web. You are forced to either create a microservice, or, spin it up within Django (nobody really does this). Then you typically have to pull in a bunch of sidecar processes (Redis, Celery, etc.) just to get queuing of your web jobs correct. - Poor concurrency. Sure, you can run your tensorflow code in an awkward 'with' statement but I think there are very few ML practicioners who could really explain to you what that with is doing. That GPU is actually fundamentally an asynchronous entity. And god help you if you want to run and debug async python. - No distribution story. Sure, the big guys are able to spin up, e.g. Horovod, but it's not really a thing for someone with less resources for a hot second on a few machines, and again, god help you if something goes wrong and you need to debug it. Does Mojo solve any of these issues? From a cursory look, it looks like no.

qumpis 3y ago
Poetry and pipenv seem to be quite popular among ML researchers, especially those who care about reproducibility.
- int_19h 3y ago
  For DS/ML, Conda is probably used more often than everything else combined.
- freilanzer 3y ago
  I use pyenv and poetry.
cavisne 3y ago
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?