[MetaSchedule][UX] Make `Database` with-able #12520

junrushao · 2022-08-21T08:25:45Z

ApplyHistoryBest right now plays a role as the database adaptor to query inside the database. In fact, the logic could be simplified and users only have to deal with Database instead of this extra object.

Add EnterWithScope/ExitWithScope/Current to Database
Migrate te_filter_func => "tir_filter" in Relay's pass context
Migrate f_take_tuning_record => "Database.query_tuning_record"
Migrate TECompiler to use Database
Remove apply-history-best

Next PR:

Migrate f_direct_dispatch (potentially unify with apply_fixed_schedule?)

cc @Hzfengsy @junrushao1994

junrushao · 2022-08-26T16:22:31Z

CC: @masahi @Hzfengsy @spectrometerHBH @vinx13

junrushao · 2022-08-26T17:56:20Z

Also CC @sunggg @YuchenJin for updates on Relax side

MasterJH5574

Some tiny nits :-)

include/tvm/meta_schedule/database.h

MasterJH5574

Another problem I’m thinking about is.. What will happen if we have code

with database_0, database_1:
    ...

If we query the best record in the “with” body, looks like the current impl will only looking for records in database_2, rather than looking for record from both databases?

masahi · 2022-08-26T20:11:54Z

Another problem I’m thinking about is.. What will happen if we have code
with database_0, database_1:
    ...
If we query the best record in the “with” body, looks like the current impl will only looking for records in database_2, rather than looking for record from both databases?

I think if we have a way to merge several databases, we can agree that we only support with database: (one database).

masahi

I really like this change! Modulo the issue raised by @MasterJH5574, LGTM.

zxybazh

Generally LGTM and we may want to add function to distinguish between targets, which should be a minor problem for now.

include/tvm/meta_schedule/database.h

src/meta_schedule/database/database.cc

sunggg

Thank you for the great work!
Overall, LGTM. A few questions and nits.

python/tvm/meta_schedule/relay_integration.py

python/tvm/meta_schedule/database/database.py

src/relay/backend/te_compiler_cache.cc

src/relay/backend/utils.cc

junrushao · 2022-08-26T23:05:23Z

Another problem I’m thinking about is.. What will happen if we have code
with database_0, database_1:
    ...
If we query the best record in the “with” body, looks like the current impl will only looking for records in database_2, rather than looking for record from both databases?
I think if we have a way to merge several databases, we can agree that we only support with database: (one database).

@MasterJH5574 @masahi Great discussion here! We will introduced JoinedDatabase in the near future to cater such needs

`ApplyHistoryBest` right now plays a role as the database adaptor to query inside the database. In fact, the logic could be simplified and users only have to deal with `Database` instead of this extra object. - [x] Add `EnterWithScope`/`ExitWithScope`/`Current` to Database - [x] Migrate `te_filter_func` => "tir_filter" in Relay's pass context - [x] Migrate `f_take_tuning_record` => "Database.query_tuning_record" - [x] Migrate `TECompiler` to use `Database` - [x] Remove apply-history-best Next PR: - Migrate `f_direct_dispatch` (potentially unify with `apply_fixed_schedule`?)

MasterJH5574 · 2022-08-27T02:52:34Z

Another problem I’m thinking about is.. What will happen if we have code
with database_0, database_1:
    ...
If we query the best record in the “with” body, looks like the current impl will only looking for records in database_2, rather than looking for record from both databases?
I think if we have a way to merge several databases, we can agree that we only support with database: (one database).
@MasterJH5574 @masahi Great discussion here! We will introduced JoinedDatabase in the near future to cater such needs

@junrushao Sounds a great idea. Thanks in advance!

tqchen · 2022-08-27T14:21:11Z

One minor nit on naming :) Join have a separate meaning and in this case perhaps concat(or merge) is more appropriate. Try lookup the terminology in pandas

Following apache#12520, this PR introduces `ScheduleFnDatabase`, a mocked database to allow injecting handcrafted schedules provided by a schedule function. The schedule function comes with the following signature: ```python def schedule_fn( sch: tir.Schedule, ) -> bool: task_name = sch.mod.attrs["task_name"] # ^^^ provides an optional name of the task queried ... ``` This mocked database helps incorporate the existing testing utility `apply_fixed_schedule` more formally into the MetaSchedule-Relay build pipeline, and allows further extension to Relax with the same interface. Next as another follow-up, we will introduce ConcatDatabase that allows mixing multiple databases, including the mocked and ones from JSON files.

junrushao · 2022-08-27T23:21:29Z

@tqchen Sure join doesn't look like a proper name. Perhaps ms.database.MergedDatabase sounds better?

Following up apache#12520 and apache#12626, this PR introduces `MergedDatabase`, which allow users to compose multiple databases so that the high-level IR could select the best tuning records among them. The `MergedDatabase` also comes with an extra field `preferred` to allow users to override tuning records from other databases. A classic usecase of the `preferred` parameter is through handcrafted schedule functions: ```python def schedule_fn(sch: tir.Schedule) -> bool: if "nn_conv2d" in sch.mod.attrs["task_name"]: handcrafted_scheduling(sch) return True return False with ms.database.MergedDatabase( databases=[database], preferred=ms.database.ScheduleFn(schedule_fn), ): lib = relay.build(...) ```

Following #12520, this PR introduces `ScheduleFnDatabase`, a mocked database to allow injecting handcrafted schedules provided by a schedule function. The schedule function comes with the following signature: ```python def schedule_fn( sch: tir.Schedule, ) -> bool: task_name = sch.mod.attrs["task_name"] # ^^^ provides an optional name of the task queried ... ``` This mocked database helps incorporate the existing testing utility `apply_fixed_schedule` more formally into the MetaSchedule-Relay build pipeline, and allows further extension to Relax with the same interface. Next as another follow-up, we will introduce ConcatDatabase that allows mixing multiple databases, including the mocked and ones from JSON files.

Following up apache#12520 and apache#12626, this PR introduces `MergedDatabase`, which allow users to compose multiple databases so that the high-level IR could select the best tuning records among them. The `MergedDatabase` also comes with an extra field `preferred` to allow users to override tuning records from other databases. A classic usecase of the `preferred` parameter is through handcrafted schedule functions: ```python def schedule_fn(sch: tir.Schedule) -> bool: if "nn_conv2d" in sch.mod.attrs["task_name"]: handcrafted_scheduling(sch) return True return False with ms.database.MergedDatabase( databases=[database], preferred=ms.database.ScheduleFn(schedule_fn), ): lib = relay.build(...) ```

Following up apache#12520 and apache#12626, this PR introduces `MergedDatabase`, which allow users to compose multiple databases so that the high-level IR could select the best tuning records among them. The `MergedDatabase` also comes with an extra field `preferred` to allow users to override tuning records from other databases. A classic usecase of the `preferred` parameter is through handcrafted schedule functions: ```python def schedule_fn(sch: tir.Schedule) -> bool: if "nn_conv2d" in sch.mod.attrs["task_name"]: handcrafted_scheduling(sch) return True return False with ms.database.MergedDatabase( preferred=ms.database.ScheduleFn(schedule_fn), # ^^^^ override scheduling decisions databases=[database], fallback=libtorch_database, # ^^^^ fallback to libtorch ): lib = relay.build(...) ```

Following up apache#12520 and apache#12626, this PR introduces two database classes: `UnionDatabase` and `OrderedUnionDatabase`, both of which allow users to organically compose multiple databases together, so that the high-level IR (Relay, Relax) could select the best tuning records according to running time or a preferred order given by users. To each query, `UnionDatabase` returns the best record among all the databases given; Instead, `OrderedUnionDatabase` returns he record from the first database that responds to the query. Used together, users may specify complicated dispatching patterns like below: ```python def schedule_fn(sch: tir.Schedule) -> bool: if "nn_conv2d" in sch.mod.attrs["task_name"]: if some_other_tir_conditions(sch.mod): handcrafted_scheduling(sch) return True return False with ms.database.OrderedUnionDatabase( ms.database.ScheduleFn(schedule_fn), # hand-override some scheduling ms.database.Union( # existing databases db_for_matmul, db_for_conv2d, db_for_softmax, ) libtorch_database, # fallback to libtorch ): lib = relay.build(...) ```

Following up apache#12520 and apache#12626, this PR introduces two database classes: `UnionDatabase` and `OrderedUnionDatabase`, both of which allow users to organically compose multiple databases together, so that the high-level IR (Relay, Relax) could select the best tuning records according to running time or a preferred order given by users. To each query, `UnionDatabase` returns the best record among all the databases given; Instead, `OrderedUnionDatabase` returns he record from the first database that responds to the query. Used together, users may specify complicated dispatching patterns like below: Examples below demonstrate the usecases of and difference between UnionDatabase and OrderDatabase. Assumption: * db1, db2 do not have tuning records for the target workload. * Each of db3, db4, db5 has tuning records r3, r4, r5 for target workload respectively. ```python merged_db = ms.database.UnionDatabase( db1, # no record db2, # no record db3, # has r3 db4 # has r4 ) merged_db.query_tuning_record(..., target_workload) merged_db = ms.database.OrderedUnionDatabase( db1, # no record db2, # no record db3, # has r3 db4 # has r4 ) merged_db.query_tuning_record(..., target_workload) merged_db = ms.database.UnionDatabase( db1, # no record db2, # no record db3, # has r3 ms.database.OrderedUnionDatabase( # returns r4 db4, # has r4 db5, # has r5 ) ) merged_db.query_tuning_record(..., target_workload) merged_db = ms.database.UnionDatabase( db1, # no record db2, # no record db3, # has r3 ms.database.UnionDatabase( # returns best one between r4 and r5 db4, # has r4 db5, # has r5 ) ) merged_db.query_tuning_record(..., target_workload) merged_db = ms.database.OrderedUnionDatabase( db1, # no record db2, # no record ms.database.UnionDatabase( # returns best one between r3 and r4 db3, # has r3 db4, # has r4 ) db5, # has r5 ) merged_db.query_tuning_record(..., target_workload) ``` Co-authored-by: sunggg <49998730+sunggg@users.noreply.github.com>

Following up apache#12520 and apache#12626, this PR introduces two database classes: `UnionDatabase` and `OrderedUnionDatabase`, both of which allow users to organically compose multiple databases together, so that the high-level IR (Relay, Relax) could select the best tuning records according to running time or a preferred order given by users. To each query, `UnionDatabase` returns the best record among all the databases given; Instead, `OrderedUnionDatabase` returns he record from the first database that responds to the query. Used together, users may specify complicated dispatching patterns like below: Examples below demonstrate the usecases of and difference between UnionDatabase and OrderDatabase. Assumption: * db1, db2 do not have tuning records for the target workload. * Each of db3, db4, db5 has tuning records r3, r4, r5 for target workload respectively. ```python #### Case 1. `UnionDatabase`: merged_db = ms.database.UnionDatabase( db1, # no record db2, # no record db3, # has r3 db4 # has r4 ) # returns the better one between r3 and r4 merged_db.query_tuning_record(..., target_workload) ### Case 2. `OrderedUnionDatabase` merged_db = ms.database.OrderedUnionDatabase( db1, # no record db2, # no record db3, # has r3 db4 # has r4 ) # returns r3 merged_db.query_tuning_record(..., target_workload) ### Case 3. Mix-use scenario merged_db = ms.database.UnionDatabase( db1, # no record db2, # no record db3, # has r3 ms.database.OrderedUnionDatabase( # returns r4 db4, # has r4 db5, # has r5 ) ) # returns the better one between r3 and r4 merged_db.query_tuning_record(..., target_workload) ### Case 4. Another mix-use scenario merged_db = ms.database.UnionDatabase( db1, # no record db2, # no record db3, # has r3 ms.database.UnionDatabase( # returns the better one between r4 and r5 db4, # has r4 db5, # has r5 ) ) # returns the best one among r3, r4 and r5 merged_db.query_tuning_record(..., target_workload) ### Case 5. Yet another mix-use scenario merged_db = ms.database.OrderedUnionDatabase( db1, # no record db2, # no record ms.database.UnionDatabase( # returns the better one between r3 and r4 db3, # has r3 db4, # has r4 ) db5, # has r5 ) # returns the better one between r3 and r4 merged_db.query_tuning_record(..., target_workload) ``` Co-authored-by: sunggg <49998730+sunggg@users.noreply.github.com> # Please enter the commit message for your changes. Lines starting # with '#' will be kept; you may remove them yourself if you want to. # An empty message aborts the commit. # # Date: Sat Aug 27 17:36:54 2022 -0700 # # On branch feature/2022-08-27/merged-database # Your branch and 'origin/feature/2022-08-27/merged-database' have diverged, # and have 1 and 1 different commits each, respectively. # (use "git pull" to merge the remote branch into yours) # # Changes to be committed: # modified: include/tvm/meta_schedule/database.h # modified: python/tvm/meta_schedule/database/__init__.py # new file: python/tvm/meta_schedule/database/ordered_union_database.py # new file: python/tvm/meta_schedule/database/union_database.py # modified: src/meta_schedule/database/json_database.cc # new file: src/meta_schedule/database/ordered_union_database.cc # new file: src/meta_schedule/database/union_database.cc # modified: src/meta_schedule/utils.h # modified: tests/python/unittest/test_link_params.py # modified: tests/python/unittest/test_meta_schedule_database.py # # Please enter the commit message for your changes. Lines starting # with '#' will be kept; you may remove them yourself if you want to. # An empty message aborts the commit. # # Date: Sat Aug 27 17:36:54 2022 -0700 # # On branch feature/2022-08-27/merged-database # Your branch and 'origin/feature/2022-08-27/merged-database' have diverged, # and have 1 and 1 different commits each, respectively. # (use "git pull" to merge the remote branch into yours) # # Changes to be committed: # modified: include/tvm/meta_schedule/database.h # modified: python/tvm/meta_schedule/database/__init__.py # new file: python/tvm/meta_schedule/database/ordered_union_database.py # new file: python/tvm/meta_schedule/database/union_database.py # modified: src/meta_schedule/database/json_database.cc # new file: src/meta_schedule/database/ordered_union_database.cc # new file: src/meta_schedule/database/union_database.cc # modified: src/meta_schedule/utils.h # modified: tests/python/unittest/test_link_params.py # modified: tests/python/unittest/test_meta_schedule_database.py # # Please enter the commit message for your changes. Lines starting # with '#' will be kept; you may remove them yourself if you want to. # An empty message aborts the commit. # # Date: Sat Aug 27 17:36:54 2022 -0700 # # On branch feature/2022-08-27/merged-database # Your branch and 'origin/feature/2022-08-27/merged-database' have diverged, # and have 1 and 1 different commits each, respectively. # (use "git pull" to merge the remote branch into yours) # # Changes to be committed: # modified: include/tvm/meta_schedule/database.h # modified: python/tvm/meta_schedule/database/__init__.py # new file: python/tvm/meta_schedule/database/ordered_union_database.py # new file: python/tvm/meta_schedule/database/union_database.py # modified: src/meta_schedule/database/json_database.cc # new file: src/meta_schedule/database/ordered_union_database.cc # new file: src/meta_schedule/database/union_database.cc # modified: src/meta_schedule/utils.h # modified: tests/python/unittest/test_link_params.py # modified: tests/python/unittest/test_meta_schedule_database.py #

Following up apache#12520 and apache#12626, this PR introduces two database classes: `UnionDatabase` and `OrderedUnionDatabase`, both of which allow users to organically compose multiple databases together, so that the high-level IR (Relay, Relax) could select the best tuning records according to running time or a preferred order given by users. To each query, `UnionDatabase` returns the best record among all the databases given; Instead, `OrderedUnionDatabase` returns he record from the first database that responds to the query. Used together, users may specify complicated dispatching patterns like below: Examples below demonstrate the usecases of and difference between UnionDatabase and OrderDatabase. Assumption: * db1, db2 do not have tuning records for the target workload. * Each of db3, db4, db5 has tuning records r3, r4, r5 for target workload respectively. ```python #### Case 1. `UnionDatabase`: merged_db = ms.database.UnionDatabase( db1, # no record db2, # no record db3, # has r3 db4 # has r4 ) # returns the better one between r3 and r4 merged_db.query_tuning_record(..., target_workload) ### Case 2. `OrderedUnionDatabase` merged_db = ms.database.OrderedUnionDatabase( db1, # no record db2, # no record db3, # has r3 db4 # has r4 ) # returns r3 merged_db.query_tuning_record(..., target_workload) ### Case 3. Mix-use scenario merged_db = ms.database.UnionDatabase( db1, # no record db2, # no record db3, # has r3 ms.database.OrderedUnionDatabase( # returns r4 db4, # has r4 db5, # has r5 ) ) # returns the better one between r3 and r4 merged_db.query_tuning_record(..., target_workload) ### Case 4. Another mix-use scenario merged_db = ms.database.UnionDatabase( db1, # no record db2, # no record db3, # has r3 ms.database.UnionDatabase( # returns the better one between r4 and r5 db4, # has r4 db5, # has r5 ) ) # returns the best one among r3, r4 and r5 merged_db.query_tuning_record(..., target_workload) ### Case 5. Yet another mix-use scenario merged_db = ms.database.OrderedUnionDatabase( db1, # no record db2, # no record ms.database.UnionDatabase( # returns the better one between r3 and r4 db3, # has r3 db4, # has r4 ) db5, # has r5 ) # returns the better one between r3 and r4 merged_db.query_tuning_record(..., target_workload) ``` Co-authored-by: sunggg <49998730+sunggg@users.noreply.github.com>

Following up #12520 and #12626, this PR introduces two database classes: `UnionDatabase` and `OrderedUnionDatabase`, both of which allow users to organically compose multiple databases together, so that the high-level IR (Relay, Relax) could select the best tuning records according to running time or a preferred order given by users. To each query, `UnionDatabase` returns the best record among all the databases given; Instead, `OrderedUnionDatabase` returns he record from the first database that responds to the query. Used together, users may specify complicated dispatching patterns like below: Examples below demonstrate the usecases of and difference between UnionDatabase and OrderDatabase. Assumption: * db1, db2 do not have tuning records for the target workload. * Each of db3, db4, db5 has tuning records r3, r4, r5 for target workload respectively. ```python #### Case 1. `UnionDatabase`: merged_db = ms.database.UnionDatabase( db1, # no record db2, # no record db3, # has r3 db4 # has r4 ) # returns the better one between r3 and r4 merged_db.query_tuning_record(..., target_workload) ### Case 2. `OrderedUnionDatabase` merged_db = ms.database.OrderedUnionDatabase( db1, # no record db2, # no record db3, # has r3 db4 # has r4 ) # returns r3 merged_db.query_tuning_record(..., target_workload) ### Case 3. Mix-use scenario merged_db = ms.database.UnionDatabase( db1, # no record db2, # no record db3, # has r3 ms.database.OrderedUnionDatabase( # returns r4 db4, # has r4 db5, # has r5 ) ) # returns the better one between r3 and r4 merged_db.query_tuning_record(..., target_workload) ### Case 4. Another mix-use scenario merged_db = ms.database.UnionDatabase( db1, # no record db2, # no record db3, # has r3 ms.database.UnionDatabase( # returns the better one between r4 and r5 db4, # has r4 db5, # has r5 ) ) # returns the best one among r3, r4 and r5 merged_db.query_tuning_record(..., target_workload) ### Case 5. Yet another mix-use scenario merged_db = ms.database.OrderedUnionDatabase( db1, # no record db2, # no record ms.database.UnionDatabase( # returns the better one between r3 and r4 db3, # has r3 db4, # has r4 ) db5, # has r5 ) # returns the better one between r3 and r4 merged_db.query_tuning_record(..., target_workload) ``` Co-authored-by: sunggg <49998730+sunggg@users.noreply.github.com>

`ApplyHistoryBest` right now plays a role as the database adaptor to query inside the database. In fact, the logic could be simplified and users only have to deal with `Database` instead of this extra object. - [x] Add `EnterWithScope`/`ExitWithScope`/`Current` to Database - [x] Migrate `te_filter_func` => "tir_filter" in Relay's pass context - [x] Migrate `f_take_tuning_record` => "Database.query_tuning_record" - [x] Migrate `TECompiler` to use `Database` - [x] Remove apply-history-best Next PR: - Migrate `f_direct_dispatch` (potentially unify with `apply_fixed_schedule`?)

Following apache#12520, this PR introduces `ScheduleFnDatabase`, a mocked database to allow injecting handcrafted schedules provided by a schedule function. The schedule function comes with the following signature: ```python def schedule_fn( sch: tir.Schedule, ) -> bool: task_name = sch.mod.attrs["task_name"] # ^^^ provides an optional name of the task queried ... ``` This mocked database helps incorporate the existing testing utility `apply_fixed_schedule` more formally into the MetaSchedule-Relay build pipeline, and allows further extension to Relax with the same interface. Next as another follow-up, we will introduce ConcatDatabase that allows mixing multiple databases, including the mocked and ones from JSON files.

…he#12628) Following up apache#12520 and apache#12626, this PR introduces two database classes: `UnionDatabase` and `OrderedUnionDatabase`, both of which allow users to organically compose multiple databases together, so that the high-level IR (Relay, Relax) could select the best tuning records according to running time or a preferred order given by users. To each query, `UnionDatabase` returns the best record among all the databases given; Instead, `OrderedUnionDatabase` returns he record from the first database that responds to the query. Used together, users may specify complicated dispatching patterns like below: Examples below demonstrate the usecases of and difference between UnionDatabase and OrderDatabase. Assumption: * db1, db2 do not have tuning records for the target workload. * Each of db3, db4, db5 has tuning records r3, r4, r5 for target workload respectively. ```python #### Case 1. `UnionDatabase`: merged_db = ms.database.UnionDatabase( db1, # no record db2, # no record db3, # has r3 db4 # has r4 ) # returns the better one between r3 and r4 merged_db.query_tuning_record(..., target_workload) ### Case 2. `OrderedUnionDatabase` merged_db = ms.database.OrderedUnionDatabase( db1, # no record db2, # no record db3, # has r3 db4 # has r4 ) # returns r3 merged_db.query_tuning_record(..., target_workload) ### Case 3. Mix-use scenario merged_db = ms.database.UnionDatabase( db1, # no record db2, # no record db3, # has r3 ms.database.OrderedUnionDatabase( # returns r4 db4, # has r4 db5, # has r5 ) ) # returns the better one between r3 and r4 merged_db.query_tuning_record(..., target_workload) ### Case 4. Another mix-use scenario merged_db = ms.database.UnionDatabase( db1, # no record db2, # no record db3, # has r3 ms.database.UnionDatabase( # returns the better one between r4 and r5 db4, # has r4 db5, # has r5 ) ) # returns the best one among r3, r4 and r5 merged_db.query_tuning_record(..., target_workload) ### Case 5. Yet another mix-use scenario merged_db = ms.database.OrderedUnionDatabase( db1, # no record db2, # no record ms.database.UnionDatabase( # returns the better one between r3 and r4 db3, # has r3 db4, # has r4 ) db5, # has r5 ) # returns the better one between r3 and r4 merged_db.query_tuning_record(..., target_workload) ``` Co-authored-by: sunggg <49998730+sunggg@users.noreply.github.com>

junrushao mentioned this pull request Aug 21, 2022

[UX][MetaSchedule] Tuning Interface tlc-pack/relax#203

Closed

9 tasks

junrushao force-pushed the feature/2022-08-20/query-in-database branch 9 times, most recently from d2b1e90 to e506714 Compare August 26, 2022 04:35

junrushao marked this pull request as ready for review August 26, 2022 16:20

github-actions bot requested a review from Hzfengsy August 26, 2022 18:52

MasterJH5574 reviewed Aug 26, 2022

View reviewed changes

include/tvm/meta_schedule/database.h Outdated Show resolved Hide resolved

include/tvm/meta_schedule/database.h Outdated Show resolved Hide resolved

MasterJH5574 reviewed Aug 26, 2022

View reviewed changes

masahi approved these changes Aug 26, 2022

View reviewed changes

zxybazh approved these changes Aug 26, 2022

View reviewed changes

include/tvm/meta_schedule/database.h Outdated Show resolved Hide resolved

src/meta_schedule/database/database.cc Show resolved Hide resolved

sunggg reviewed Aug 26, 2022

View reviewed changes

junrushao force-pushed the feature/2022-08-20/query-in-database branch from e506714 to 2221492 Compare August 26, 2022 22:54

junrushao force-pushed the feature/2022-08-20/query-in-database branch from 2221492 to 8f74866 Compare August 26, 2022 23:08

MasterJH5574 merged commit 370abe6 into apache:main Aug 27, 2022

junrushao mentioned this pull request Aug 27, 2022

[MetaSchedule] Introduce ScheduleFnDatabase #12626

Merged

junrushao mentioned this pull request Aug 28, 2022

[MetaSchedule] Introduce Union and OrderedUnion in Database #12628

Merged

leandron mentioned this pull request Sep 8, 2022

[Bug] Meta-scheduler tests failing in test_meta_schedule_integration.py #12732

Closed

zxybazh mentioned this pull request Sep 19, 2022

[MetaSchedule] PyDatabase Complete Function Reload Support #12838

Merged

AndrewZhaoLuo mentioned this pull request Oct 4, 2022

TVM v0.10.0.rc0 Release Candidate Notes #12979

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

[MetaSchedule][UX] Make `Database` with-able #12520

[MetaSchedule][UX] Make `Database` with-able #12520

junrushao commented Aug 21, 2022 •

edited

Loading

junrushao commented Aug 26, 2022

junrushao commented Aug 26, 2022

MasterJH5574 left a comment

MasterJH5574 left a comment

masahi commented Aug 26, 2022 •

edited

Loading

masahi left a comment

zxybazh left a comment

sunggg left a comment

junrushao commented Aug 26, 2022

MasterJH5574 commented Aug 27, 2022

tqchen commented Aug 27, 2022

junrushao commented Aug 27, 2022

[MetaSchedule][UX] Make Database with-able #12520

[MetaSchedule][UX] Make Database with-able #12520

Conversation

junrushao commented Aug 21, 2022 • edited Loading

junrushao commented Aug 26, 2022

junrushao commented Aug 26, 2022

MasterJH5574 left a comment

Choose a reason for hiding this comment

MasterJH5574 left a comment

Choose a reason for hiding this comment

masahi commented Aug 26, 2022 • edited Loading

masahi left a comment

Choose a reason for hiding this comment

zxybazh left a comment

Choose a reason for hiding this comment

sunggg left a comment

Choose a reason for hiding this comment

junrushao commented Aug 26, 2022

MasterJH5574 commented Aug 27, 2022

tqchen commented Aug 27, 2022

junrushao commented Aug 27, 2022

[MetaSchedule][UX] Make `Database` with-able #12520

[MetaSchedule][UX] Make `Database` with-able #12520

junrushao commented Aug 21, 2022 •

edited

Loading

masahi commented Aug 26, 2022 •

edited

Loading