附：脚本的Input和Output，及相关截图：

Input：“yaml参数文件”、“负载执行命令”、“能效判别阈值x”、“至少应被选中的y%的参数”、

             “运行记录文件的输出路径”、“被选中参数的yaml文件输出路径”；


运行记录文件：



运行过程的log：

另外，该脚本会根据用户输入的阈值输出yaml文件。


-----------------------------------------------------------------------------------------------
Best Regard, LI C：
李俊祺，20级研究生，华南理工大学计算机科学与工程学院 
ChunKi LI，Grade 2020 graduate student，South China University of Technology
研究方向：基于群智能的云计算调度优化和节能技术
-----------------------------------------------------------------------------------------------


------------------ 原始邮件 ------------------
发件人: "20研李俊祺" <2506534280@qq.com>;
发送时间: 2020年11月20日(星期五) 中午11:34
收件人: "a-tune"<a-tune@openeuler.org>;
抄送: "linweiwei"<147868463@qq.com>;"胡康立"<conli_who@foxmail.com>;
主题: 关于今天SIG上提出的遍历选参脚本

A-Tune的各位开发人员你们好，关于刚才SIG会议上提到的abtest调参算法同样是遍历思想来完成的问题，我有以下看法：

1、固定其他参数，不断修改参数值以获取当前参数的最优值，然后固定该最优值，再调整后面的参数，这个在少量参数需要调整的时候
     应该是可以快速做到这一点的。

     但是，当参数数量达到100+以上的时候，abtest算法可能就要运行很长一段时间了。而我们的选参脚本是针对多个参数（几乎
     涵盖tunning_param_all.yaml文件里面的所有参数）进行选参（不是调参），负载执行次数相对来说会比较少。

     我们的选参脚本可以解决的就是，避免abtest算法需要穷举所有参数的所有范围来运行导致优化时间过长的问题。
     先选出合理的参数，再交给atune的tuning算法来优化，可以省下不少的时间。如果一个参数本身某个评价指标是
     没有什么影响的，那abtest可能会花不必要的时间来改变参数运行负载。
    
2、我们的脚本是针对服务器的初始状态进行选参的，在每次修改某个参数以后，我们都会将该参数恢复为默认值，然后再
     测试下一个参数对能效的影响。而abtest每次获取到一个参数的最优值，就会吧这个参数固定在这个最优值上。我觉得有
     些参数是具有依赖性的，如果调整好前面的参数再调后面的参数，可能会对后面参数的选择造成影响（无法分辨出哪些参数
     对评价指标具有最大的影响程度）。因此，如果我们是针对选参任务来进行遍历的话，我们在遍历过程中会将参数恢复成服务器
     默认的状态，区分出参数对某一评价指标（比如能效）的重要程度，根据用户输入的阈值，筛选出最具影响力的参数，再用tuning
     的不同算法对这部分参数进行优化，是有意义的；

这就是我对我的选参脚本和abtest不同之处的分析，不知道你们怎么看呢？
    
    



-----------------------------------------------------------------------------------------------
Best Regard, LI C：
李俊祺，20级研究生，华南理工大学计算机科学与工程学院
ChunKi LI，Grade 2020 graduate student，South China University of Technology
研究方向：基于群智能的云计算调度优化和节能技术
-----------------------------------------------------------------------------------------------