Require an autoscheduler for build_gradient_module()/GRADIENT_DESCENT#8525
Require an autoscheduler for build_gradient_module()/GRADIENT_DESCENT#8525steven-johnson wants to merge 1 commit intomainfrom
Conversation
Currently we just emit a warning... which may be hidden by CMake/Bazel. This really needs to be an error, though, because an unscheduled gradient-descent module can be immense and take ~forever to compile.
steven-johnson
changed the title
|
If you're asking for the derivative of an element wise thing (e.g. a generator that just does relu), then requiring an autoscheduler to run is a bit ridiculous. Is there any way to insert a manual schedule somewhere when using this build mode? Also we should really make cmake not swallow warnings. That defeats the entire purpose of warnings. |
Nope.
I'll defer to Alex on that. |
|
Part of the footgun here is that you can ask for this on any arbitrary Generator and we'll try our best; while looking at #8393 I just modified the Python build rules to do gradients for all the Python generators (per the discussion) and found that without an autoscheduler, my system allocated ~250GB of virtual address space. |
| passing `-d 1` at the generator command line. Note that you *must* also specify | ||
| an autoscheduler (via the `AUTOSCHEDULER` argument) when specifying this | ||
| argument. |
There was a problem hiding this comment.
We should check this in HalideGeneratorHelpers.cmake
There was a problem hiding this comment.
First we should get buy-in from everyone as to whether this change is a good one.
3 participants
Currently we just emit a warning... which may be hidden by CMake/Bazel. This really needs to be an error, though, because an unscheduled gradient-descent module can be immense and take ~forever to compile. (Addresses part of #8393 but not a complete fix.)