FR: reorganize the autoscheduler(s) in the codebase

[steven-johnson]

From a Gitter discussion:

The 'classic' autoscheduler lives in src/.

The ML-based autoscheduler lives primarily in apps/autoscheduler; it can't quite live in Halide proper (as it depends on Halide itself) but it isn't really an app either.

It would be nice if the autoschedulers could be refactored into their own area (e.g., src/autoschedule, or a new toplevel dir, etc) to make their distinctions and dependencies clear; this might also allow for other special-purpose autoschedulers to be more easily added (e.g. a dumb compute_root everything variants).

It would make it much easier for newcomers trying to understand the codebase wrt autoscheduler(s).

(This would likely be entirely a code-shuffling and buildsystem-hacking exercise, but one worth doing for longterm code health.)

[alexreinking]

I would be eager to help with this. I've been considering opening an issue for a while to add the new autoscheduler to the distrib folder.

[steven-johnson]

Also, a much greater argument for reorganizing: the current setup effectively means that the ml-autoscheduler can't be used from a binary distribution (as it requires apps/, which isn't included); requiring build-from-source to use the ml-autoscheduler is definitely suboptimal.

EDIT: looks like my comment crossed paths with @alexreinking :-)

[alexreinking]

Also, a much greater argument for reorganizing: [...] EDIT: looks like my comment crossed paths with @alexreinking :-)

It appears so :-)

I actually agree that this is the bigger issue. The proposed refactor happens to be a great way of facilitating that.

[steven-johnson]

Just pinging on this to see if it's likely to happen anytime soon -- I'm considering adding a feature to core Halide that can (optionally) make use of the autoscheduler, but with the current setup, it seems problematic.

Are there blocking factors on the refactoring, or is it just a question of competing priorities?

[abadams]

I'm not aware of any blocking factors.

[steven-johnson]

Thoughts from a dupe I opened by mistake:

• all are plugins ('classic' shouldn't be privileged anymore)
• all live somewhere other than apps/ (e.g. a new toplevel plugins/ folder or some such)
• all are built into distrib/ folder for binary distributions
• validation testing for all of them is available as part of the normal test suite (rather than via apps/)

Note that this is arguably a bit more urgent now since we will soon also have apps/gradient_autoscheduler

[alexreinking]

@steven-johnson -- I took a couple hours to take a first crack at this today. See the autoscheduler-plugins branch.

It's in no way ready for review, but I'm making a note of its existence here in case someone else wants to push it further (really, I'm procrastinating writing a paper draft).

I was able to get the CMake build to run the correctness and auto_schedule tests and those worked correctly. The classic autoscheduler is now loaded as a plugin by default if no other exists in the map.

[BachiLi]

@steven-johnson -- I took a couple hours to take a first crack at this today. See the autoscheduler-plugins branch.

It's in no way ready for review, but I'm making a note of its existence here in case someone else wants to push it further (really, I'm procrastinating writing a paper draft).

I was able to get the CMake build to run the correctness and auto_schedule tests and those worked correctly. The classic autoscheduler is now loaded as a plugin by default if no other exists in the map.

This looks great! What else needs to be done for it?

[alexreinking]

@BachiLi -- the Makefile build hasn't been adjusted at all. I still haven't run the full test suite. I've only tried the build on Linux, not on Windows.

[alexreinking]

The CMake build in #4644 has a handful of TODOs related to this issue, but they will not be fixed until after it lands.