[Maybe Bug]指定搜索空间不起作用

[hbsun2113]

在5_Automatic_Program_Optimization中，无论是否使用space=ms.space_generator.ScheduleFn(stochastic_schedule_mm), sch_tuned.trace的输出都是相同的。
即以下两个code piece:
sch_tuned = ms.tune_tir( mod=MyModule, target="llvm --num-cores=1", config=ms.TuneConfig( max_trials_global=64, num_trials_per_iter=64, ), space=ms.space_generator.ScheduleFn(stochastic_schedule_mm), work_dir="./tune_tmp", task_name="main" )

sch_tuned = ms.tune_tir( mod=MyModule, target="llvm --num-cores=1", config=ms.TuneConfig( max_trials_global=64, num_trials_per_iter=64, ), work_dir="./tune_tmp", task_name="main", )

它们的print(sch_tuned.trace)都是：
b0 = sch.get_block(name="C", func_name="main") b1 = sch.get_block(name="root", func_name="main") sch.annotate(block_or_loop=b0, ann_key="meta_schedule.tiling_structure", ann_val="SSRSRS") l2, l3, l4 = sch.get_loops(block=b0) v5, v6, v7, v8 = sch.sample_perfect_tile(loop=l2, n=4, max_innermost_factor=64, decision=[1, 1, 128, 1]) l9, l10, l11, l12 = sch.split(loop=l2, factors=[v5, v6, v7, v8]) v13, v14, v15, v16 = sch.sample_perfect_tile(loop=l3, n=4, max_innermost_factor=64, decision=[1, 4, 1, 32]) l17, l18, l19, l20 = sch.split(loop=l3, factors=[v13, v14, v15, v16]) v21, v22 = sch.sample_perfect_tile(loop=l4, n=2, max_innermost_factor=64, decision=[16, 8]) l23, l24 = sch.split(loop=l4, factors=[v21, v22]) sch.reorder(l9, l17, l10, l18, l23, l11, l19, l24, l12, l20) b25 = sch.cache_write(block=b0, write_buffer_index=0, storage_scope="global") sch.reverse_compute_at(block=b25, loop=l17, preserve_unit_loops=True) sch.annotate(block_or_loop=b1, ann_key="meta_schedule.parallel", ann_val=16) sch.annotate(block_or_loop=b1, ann_key="meta_schedule.vectorize", ann_val=64) v26 = sch.sample_categorical(candidates=[0, 16, 64, 512], probs=[0.25, 0.25, 0.25, 0.25], decision=0) sch.annotate(block_or_loop=b1, ann_key="meta_schedule.unroll_explicit", ann_val=v26) sch.enter_postproc() b27 = sch.get_block(name="root", func_name="main") sch.unannotate(block_or_loop=b27, ann_key="meta_schedule.parallel") sch.unannotate(block_or_loop=b27, ann_key="meta_schedule.vectorize") sch.unannotate(block_or_loop=b27, ann_key="meta_schedule.unroll_explicit") b28, b29 = sch.get_child_blocks(b27) l30, l31, l32, l33, l34, l35, l36, l37, l38, l39 = sch.get_loops(block=b28) l40 = sch.fuse(l39) sch.vectorize(loop=l40) l41, l42, l43, l44 = sch.get_loops(block=b29) b45 = sch.get_block(name="C", func_name="main") l46, l47, l48, l49, l50, l51, l52, l53, l54, l55 = sch.get_loops(block=b45) b56 = sch.decompose_reduction(block=b45, loop=l50)

请问这个是expected的吗？

[hbsun2113]

vs.

output:

[Hzfengsy]

按照 Notes 的执行结果来看，space=ms.space_generator.ScheduleFn(stochastic_schedule_mm)是生效的。

有一种可能会出现这个问题是因为你可能复用了work_dir，导致后续复用了之前的log记录。因为默认的space是最优的，课程为了简化问题提出了一个简单的space，所以默认space的性能是会优于stochastic_schedule_mm。而相同的work_dir的记录是累加而不是覆盖，所以可能会读取到非当次的log（如果历史记录更快的话）

[hbsun2113]

增加一个option指定是累加还是覆盖，更合理？

[Hzfengsy]

一般情况下累加是更合理的，因为tuning本身就是为了在更多的search过程中寻找最优。在这个case里可以通过with tempfile.TemporaryDirectory() as temp_dir:来保证每次的work_dir是独立的