WIP: ISC比赛的相关说明待更新
Student Cluster Competition（学生超算竞赛）是一系列在指定功耗限制（3 kW）内，以现实科学计算问题作为计算任务，在限定时间内考量学生队伍表现的比赛。主要包括ASC（Asia Student Supercomputing Challenge）、ISC（ISC-HPCAC Student Cluster Competition，ISC-HPCAC是一个顶级学术会议）和SC（SC Student Cluster Competition，SC同样地也是一个顶级学术会议）三项，我们队伍历年来主要参加后两项。
ISC和SC SCC都在对应的顶会兼大型展览上举办。赛场即会场，比赛的区域便是展厅一角，展览开放期间也会有不少参观者路过、驻留围观，很是热闹。不过很可惜的是队员们绝对没有那个心情和精力去和他们闲聊~
话归正题。这一比赛的主要形式，是在赛前近半年给出比赛题目（一些用作计算任务的应用，通常是成型的开源项目等），学生从此时开始组队、分析应用、设计集群、联系vendor装配集群，进行比赛的准备。到赛场上后，组装好机器，然后开始三天每天8小时（ISC）或连续近48小时（SC）的比赛。虽然赛题在赛前给出，但具体的输入数据（算例）直到赛场才会提供，因此是不可伪造的。
以SC为例，这一比赛的主要考察内容有以下几点：
应用分析和优化。
SC作为下半年的比赛在六月份到八月份会陆续发放赛题，现在来说是两个应用和一个论文复现任务。无论哪个，它们的主要内容都是要对一个软件有着足够的了解，让它能高效地在你配置的集群上以不超过功耗上限3kW的情况下运行。也就是说，我们赛前有大约半年的时间对应用进行分析和优化。
主要的步骤如下：
- 编译执行。无论如何，我们都需要先让这个软件能够正常地工作，我们才能了解它的功能，测试它的性能特征。不要小看这一步工作，它也许会是非常复杂的；因为赛方出的应用很可能就是研究界甚至工业界常用的大型框架，百万行乃至千万行的代码都并不少见，依赖关系也会非常复杂。
- 试着运行应用，理解应用的运行模式。它有哪些主要组件，这些组件如何交互，通过阅读文档、代码和实际运行，就可以理解项目的结构。
- 寻找合适的算例。算例在科学计算当中非常重要，因为它才是计算的核心。我们有要处理的输入数据，它的特征将会影响我们的计算任务，从各方面特征到最终的性能。我们需要理解赛方出题的含义，分析可能的算例特征，找到合适的数据作为输入。
- Profiling。大家可能对profiling这个东西不是很熟悉，它其实是对一个程序的性能进行观察，核算出每段代码所占的时间比例，也会考虑不同的调用链。通过profiling，我们可以确认程序当中最耗时间的部分在哪，可以知道这时他在做什么，也可以知道它为什么花去了很多时间，从而允许我们进一步针对性地优化和调整。通常的profiling工具有Intel VTune Amplifier，Paramon，Allinea Forge和针对GPU的NVIDIA (Visual) Profiler。
- 优化。主要分两个方向：
- 结合经验测试各种可能带来性能提升的编译选项、运行配置，测试它们的性能，选择最优的方式去执行；这种方法一般用于代码没什么可优化的点的时候。需要注意的是，运行配置不仅仅是软件配置（多少线程、多少进程、进程如何分配NUMA、运行时版本……），还有一个很重要的事情则是硬件配置。不同的硬件可能会带来差别巨大的效果。
- 核心/热点代码优化。有些应用代码量小，可以很容易地抓到核心，并且核心部分优化提高的空间很大。这时候就需要动用自己关于体系结构的知识、和各种编程模型的了解，比如说SIMD向量化，OpenMP的多线程并行计算，MPI的多进程网络并行，CUDA的GPU计算，来对这部分花时间最长的代码进行优化。
- 回到
4.，循环迭代尽可能多的次数，直至赛前。（很不幸的是通常一轮都做不完）
配置决策。
这一步实际上是和应用分析优化同时进行的。应用分析好后，了解了它的特征，才能确定最适合它的硬件（CPU、GPU甚至KNL和FPGA）；而初步确定了配置，才可以进行进一步的优化，例如选定了GPU后进行CUDA版本的测试和优化。
而最终的决策中，需要包含的内容大致有：
- 硬件配置。是否使用GPU？使用多少、什么型号的GPU？什么型号的CPU？使用几个节点、每个节点配置多少计算资源？节点的机型？高速互连网络使用什么样的（虽然一般都是最新的Mellanox Infiniband……）？
- 软件配置。操作系统版本？驱动版本？负载管理器（关键！！SC17因没有这样的管理环境吃了不少亏）？Intel & CUDA运行时版本？共享文件系统解决方案（NFS/OrangeFS…）？
时间策略。我们有48个小时，怎么分配？这48小时一开始，所有的应用任务就一股脑地放了下来，如何很好地调度这些时间，避免浪费，就非常关键。这实际上取决于各个应用的特征。
宣传准备，也就是海报的制作。海报当中要包含的信息量十分巨大，如何在规定的版面内优雅而清晰地容纳下这些内容，是一个需要仔细思考设计的问题。
赛场应变。以上内容全都是赛前的准备，但赛场上才会将它们一一表现出来。硬件故障、软件故障、算例特征偏离预期、SC17新加入的Poster Session（站在外面英文给路人和评分人员讲解海报两个小时）、Conference Engagement（参加会议的一些报告，会问一些相关的问题；对我们来说近似于听力题）、Interview（每个应用的作者来和队员交流、了解我们的工作），这些都是赛场上才会碰到、需要当场解决的事情。
以上内容基本整理自这一PPT。
一点经验：
集群开始运输前让供应商提供精细到节点内主要零件的组件清单表。确认是否包含足数的以下项目：
- 计算部件，包括CPU和GPU等（SC16最开始没有拿到CPU）
- 内存
- 硬盘
- 节点机箱和其中的主板等
- 风扇（SC17全程没有GPU风扇，非常痛苦）
供电线缆和Infiniband线缆（ISC16所有线都没有带，借用其他队伍的了）
如果以后有吃更多奇葩的亏，请更新到以上列表；都是血和泪的教训啊（望天
Poster的制作一定要留出充足的时间。最好在各个应用已经初具头绪的时候就开始准备。
Conference Engagement中一定要录音、做笔记！那可是听力题！（SC16的时候还是很正常的观后感，SC17就变成了英语听力，对非英语国家队伍恶意满满）
时间策略一定要明确，不要摇摆不定，决定了如何跑就不要犹豫。（SC17中MrBayes经验谈）
当任务量大而零碎时，一定要使用负载管理器。不要信任自己随手写的脚本。（SC17中Born经验谈）
一定要考虑IO压力，就算是一开始IO不是负载重点，你优化了计算部分后也会出现问题。自己测试的时候因为有操作系统对算例的缓存，需要清理缓存才能体现真实负载。（SC17中Born经验谈）