FastAI.jl: FastAI for Julia
forums.fast.ai
FastAI.jl: FastAI for Julia
1–10 of 24 posts
Re: FastAI.jl: FastAI for Julia
#2This is interesting to me but the motivation behind this is unclear. Since FastAI.jl uses Flux, and not PyTorch, functionality has to be reimplemented. FastAI.jl has vision support but no text support yet.
What does this mean for the development of fastai?
What is the timeline for FastAI.jl to achieve parity?
When should I choose FastAI.jl vs fastai?
Re: FastAI.jl: FastAI for Julia
#3This is interesting to me but the motivation behind this is unclear. Since FastAI.jl uses Flux, and not PyTorch, functionality has to be reimplemented. FastAI.jl has vision support but no text support yet. What does this mean for the development of fastai? What is the timeline for FastAI.jl to achieve parity? When should I choose FastAI.jl vs fastai?
> When should I choose FastAI.jl vs fastai?
Unless you're following the course, you probably shouldn't use either.
Re: FastAI.jl: FastAI for Julia
#4This is interesting to me but the motivation behind this is unclear. Since FastAI.jl uses Flux, and not PyTorch, functionality has to be reimplemented. FastAI.jl has vision support but no text support yet. What does this mean for the development of fastai? What is the timeline for FastAI.jl to achieve parity? When should I choose FastAI.jl vs fastai?
> When should I choose FastAI.jl vs fastai? Unless you're following the course, you probably shouldn't use either.
Why not? Honest question--I haven't used fastai myself but my understanding is it's just a high-level wrapper API for PyTorch. Any particular reason why you wouldn't want to use it outside of the course?
Re: FastAI.jl: FastAI for Julia
#5Earlier quoted context omitted.
> When should I choose FastAI.jl vs fastai? Unless you're following the course, you probably shouldn't use either.
Why not? Honest question--I haven't used fastai myself but my understanding is it's just a high-level wrapper API for PyTorch. Any particular reason why you wouldn't want to use it outside of the course?
We use it for training some of the models we use in production environments serving millions of requests per day, so there's no reason to exclude it completely IMO. As you say, it's a wrapper for Pytorch with a few extras tacked on.
With Pytorch you would either use pure torch, FastAI or something like Lightning most of the time. Unless you're using completely mainstream models such as the ones you could get from the Transformers library.
Re: FastAI.jl: FastAI for Julia
#6Looking forward to trying this out!
Re: FastAI.jl: FastAI for Julia
#7This is interesting to me but the motivation behind this is unclear. Since FastAI.jl uses Flux, and not PyTorch, functionality has to be reimplemented. FastAI.jl has vision support but no text support yet. What does this mean for the development of fastai? What is the timeline for FastAI.jl to achieve parity? When should I choose FastAI.jl vs fastai?
It does seem to actually be an unofficial implementation in Julia. So it shouldnt have any impact on the actual development?
Im kinda wondering if Jeremy Howard has ok'ed using their name on a library that they're not in charge of? I didnt find a clear answer to that. Particularly troubling since it seems like the FluxML organization is behind this, not some random dude
Re: FastAI.jl: FastAI for Julia
#8This is interesting to me but the motivation behind this is unclear. Since FastAI.jl uses Flux, and not PyTorch, functionality has to be reimplemented. FastAI.jl has vision support but no text support yet. What does this mean for the development of fastai? What is the timeline for FastAI.jl to achieve parity? When should I choose FastAI.jl vs fastai?
Having tried fastai for a "serious" research project and helped (just a bit) towards FastAI.jl development, here's my take:
> motivation behind this is unclear.
Julia currently has two main DL libraries. Flux, which is somewhere between PyTorch and (tf.)Keras abstraction wise, and Knet, which is a little lower level (think just below PyTorch/around where MXNet Gluon sits). Frameworks like fastai, PyTorch Lightning and Keras demonstrate that there's a desire for higher-level, more batteries included libraries. FastAI.jl is looking to fill that gap in Julia.
> Since FastAI.jl uses Flux, and not PyTorch, functionality has to be reimplemented. FastAI.jl has vision support but no text support yet.
This is correct. That said, FastAI.jl is not and does not plan to be a copy of the Python API (hence "inspired by"). One consequence of this is that integration with other libraries is much easier, e.g. https://github.com/chengchingwen/Transformers.jl for NLP tasks.
> What is the timeline for FastAI.jl to achieve parity?
> When should I choose FastAI.jl vs fastai?
This depends on your use cases and how comfortable you are with a) Julia b) having to roll some of your own code. For the first, I'd recommend poking around with the language before as well as using the linked dev channel in TFA to get an informed opinion.
FastAI.jl itself is composed of multiple constituent packages that can and are used independently, so there's also the option of mixing and matching. For example, https://github.com/lorenzoh/DataLoaders.jl is completely library agnostic.
Re: FastAI.jl: FastAI for Julia
#9This is interesting to me but the motivation behind this is unclear. Since FastAI.jl uses Flux, and not PyTorch, functionality has to be reimplemented. FastAI.jl has vision support but no text support yet. What does this mean for the development of fastai? What is the timeline for FastAI.jl to achieve parity? When should I choose FastAI.jl vs fastai?
It does seem to actually be an unofficial implementation in Julia. So it shouldnt have any impact on the actual development? Im kinda wondering if Jeremy Howard has ok'ed using their name on a library that they're not in charge of? I didnt find a clear answer to that. Particularly troubling since it seems like the FluxML organization is behind this, not some random dude
From TFA:
> We’ll also be hosting a Q&A session 02.08., 10PM UTC (03.08., 12AM CEST | 8AM AEST). Jeremy will be there, too. Meeting link will follow soon.
My understanding is that he's at least been aware of this since early development (just over a year), so make of that what you will.
Re: FastAI.jl: FastAI for Julia
#10Earlier quoted context omitted.
It does seem to actually be an unofficial implementation in Julia. So it shouldnt have any impact on the actual development? Im kinda wondering if Jeremy Howard has ok'ed using their name on a library that they're not in charge of? I didnt find a clear answer to that. Particularly troubling since it seems like the FluxML organization is behind this, not some random dude
From TFA: > We’ll also be hosting a Q&A session 02.08., 10PM UTC (03.08., 12AM CEST | 8AM AEST). Jeremy will be there, too. Meeting link will follow soon. My understanding is that he's at least been aware of this since early development (just over a year), so make of that what you will.
Well, that's great then! :) Guess i should have actually read the post instead of jumping to the github page...