Live data from Hacker News

Fastai: A Layered API for Deep Learning

arxiv.org

11–20 of 43 posts

Re: Fastai: A Layered API for Deep Learning

#11
The lectures have a ton of gems in them, but I have a hard time following the lectures as a beginner/intermediate practitioner, as around 1-5 percent is relevant for me. I don't particularly like the fastai library as it feels like an obstacle between me and the underlying pytorch library. After trying to use fastai for some time, I started looking directly at pytorch and found that all the abstractions and features I liked with fastai were actually from pytorch. That said, it's a great resource and if you're doing cookiecutter stuff it seems pretty nice. Also, students of fastai have done some pretty amazing things. I like how Jeremy emphasizes the top-down view, but it's very hard for me to submit to it. I can't shake the need to understand the underlying ideas and build stuff bottom-up, even though I see my progress suffers from it.

Re: Fastai: A Layered API for Deep Learning

#12

The lectures have a ton of gems in them, but I have a hard time following the lectures as a beginner/intermediate practitioner, as around 1-5 percent is relevant for me. I don't particularly like the fastai library as it feels like an obstacle between me and the underlying pytorch library. After trying to use fastai for some time, I started looking directly at pytorch and found that all the abstractions and features…

The second part of the course (https://course.fast.ai/part2) - builds stuff bottom-up, starting from matrix multiplication all the way up to ResNets. This is a great resource even if you want only use Pytorch.

Re: Fastai: A Layered API for Deep Learning

#13
post #7

Does it still have the requirement for a GPU (driver) to be around to even run, like fastai 1.0 had? (Had to manually comment requirements and imports to have it run CPU-only...) I get it that for any serious use you'd want a GPU, but for learning and toying around you might want to be able to run and debug code on your freakin macbook! Is that too much to asks? (Some of us do code in IDEs, not in notebooks + vim on…

It is possible to run everything on CPU, even if we fastai 1.0. Only training can be 100 times slower than on GPU. Even for a toy exercises involving image processing and actual deep networks (30-150 layers) it means hours or days of training.

It is not FastAI fault though.

Re: Fastai: A Layered API for Deep Learning

#14
I like fast.ai a lot. For those who remember OpenRDF, fast.ai reminds me of how nice it was to use Sesame Sails (though sometimes you had to create your own sail components). Sails were modular semantic reasoning and triple store layers you could stack in different ways to 'make your AI ship go'.

Re: Fastai: A Layered API for Deep Learning

#15
post #6

My small complaint is that there seems to be no backwards compatibility whatsoever between fastai versions. I get it that it is supposed to be working on the very bleeding edge of deep learning technologies, but at the same time it is sold as "practical". At least I would be slightly uncomfortable doing anything in production with a library that is all but guaranteed to get no (compatible) development love whatsoever…

We're actually using fastai in production and will happily switch to v2. Sure, there are serious questions about long-term stability and we know these projects will be high maintenance.

However, they would be anyway: Core models and algorithms are quickly outdated and any change that allows us to achieve similar or better results with less effort in creating training data is easily worth the engineering work.

That said, I really hope v2 feels a bit more like other libraries: extending v1 models has been pretty painful in several occasions. E.g. making some changes to the underlying pytorch models was very straightforward but still using all the goodies for training build into fastai (in particular all the stuff based on the work of Leslie Smith, tuned for best practices inside the fastai universe) was pretty painful. It is awesome to have a library actually implement best practices from latest research, but sometimes all this greatness was pretty hard for me to transfer to changed models.

That said, it has worked for us in v1 and the benefits outweighed the problems by far.

Re: Fastai: A Layered API for Deep Learning

#16
Bleeding edge is great for fun and personal development, Jeremy (with the fast.ai team as a whole) is wonderful and all that, but you need to have your own suitable case study to make the most of such techniques and implementation... nlp for the time being, it was image processing when they were just starting and I followed their courses. In 2020 or year V, VI or VII of this new machine learning explosion, generalists cannot not do much on their own anymore imho.

Re: Fastai: A Layered API for Deep Learning

#17
post #7

Does it still have the requirement for a GPU (driver) to be around to even run, like fastai 1.0 had? (Had to manually comment requirements and imports to have it run CPU-only...) I get it that for any serious use you'd want a GPU, but for learning and toying around you might want to be able to run and debug code on your freakin macbook! Is that too much to asks? (Some of us do code in IDEs, not in notebooks + vim on…

I think the whole reason AI has become what it has is because these are “brute force” things you can’t do with a normal CPU. So functional programming and massively parallel algorithms are what make it possible. Every year it gets more accessible to a wider audience. Soon there will probably be frameworks that hide the complexity completely and you can just say here’s a massive dataset, I want to train it to be a con…

i believe OP would, for example, want to start training locally just to check for errors, then do the run somewhere remote.

Synchronizing local and remote code shouldn't take much time, but it's still at least a few seconds on the critical path for the run->fail->fix->rerun loop.

VSCode's remote mode might be a worth a try for people with such a setup.

Re: Fastai: A Layered API for Deep Learning

#18
Hi Jeremy, just wanted to say you are amazing. I've followed all your lectures and I wish I had you as a teacher for all my assignments in college. You truly have a gift to explain hard things in a very simple way. And the things you are doing with fastai are a gift to the community that is moving science forward. I'm doing my Master Thesis, and fastai is a key piece of my experiments. So again, a big thank you. Hope some day I can do a favor to you as you've done for me

Re: Fastai: A Layered API for Deep Learning

#19
post #7

Does it still have the requirement for a GPU (driver) to be around to even run, like fastai 1.0 had? (Had to manually comment requirements and imports to have it run CPU-only...) I get it that for any serious use you'd want a GPU, but for learning and toying around you might want to be able to run and debug code on your freakin macbook! Is that too much to asks? (Some of us do code in IDEs, not in notebooks + vim on…

It is possible to run everything on CPU, even if we fastai 1.0. Only training can be 100 times slower than on GPU. Even for a toy exercises involving image processing and actual deep networks (30-150 layers) it means hours or days of training. It is not FastAI fault though.

My actual use case some time ago was to run tests suites for some tricky and convoluted data wrangling code that used (by necessity since it was doing some funky tiled image loading and segmentation) fastai dataframes and stuff, locally on CPU to debug those tests... neither training, nor even inference actually, just running a useless micro-training session at the end to sanity test that data was loaded in a usable way and things didn't broke when you tried to train.

But in fastai 1.0 it was all bundled together in one big yarn, with everything depending in the end on some data loading classes that depended on GPU driver etc.

Anyway, it was really bad architecture and dev practices in the codebase I was working though, the tested behavior would probably not have matched production one 100%... I don't blame fastai much for not helping with a broken workflow, but I prefer more barebones and less opinionated frameworks, aka using tf or pytorch directly, since some times you really need to get that "broken" thing running in production before you work on a refactored version of it :P Fastai seems very research-oriented and opinionated.

I'll definitely look into fastai 2.0 though :)

Post reply on HN