本文始发于个人公众号【两猿社】。
声明，为保证比赛公平，本文不会提供比赛源码，仅提供思路与踩坑经验。
他来了，他来了，他带着面试绿卡走来了。
他来了，他来了，他带着20w大奖走来了。
一年一度的华为软件秃头挑战赛如约而至，为了帮大家踩坑，社长又一次参赛了，你还不来吗？
2月下旬，我写过一篇有关华为软挑参赛经验的推文：O准备如何苟进复赛圈？华为软挑开挂指南（附赛题预测），本以为这样的题目能吸引不少的读者，甚至找大佬公众号转载过，不曾想阅读量依旧十分惨淡。
但，实话实话，里面还是有点东西，比如有关赛题的预测、时间的预测，相信今年的参赛者会会心一笑。
除此之外，还有满满的参赛经验，如果还没读过的同学，建议读一下。虽然不会保证你进复赛，但至少可以让你在冲往复赛的路上，多一些信心，少一些遗憾。
- 00 新赛制吐槽
- 01 赛题解析
- 02 代码反馈
- 03 思路分享
- 04 并行讨论
- 05 好言相劝
00 新赛制吐槽
今年的赛制与往年不同，多了一个**“热身赛”**，这在流程上繁琐了不少，不遗余力推广鲲鹏平台的目的却明显了许多。
热身赛分为两个阶段，知识竞答和编程闯关全程都围绕鲲鹏处理器展开。不过，推广自家产品也是人之常情嘛。
说回比赛本身，知识竞答和编程闯关是递进式比赛，其中知识竞答取得80分，满两个小时后，自动进入编程闯关。
这种赛程设定，社长目前还不能领会赛方的用意，难道是打广告？那这广告是不是硬了点啊…
最后吐槽一下，比赛官网和评分系统。我完全相信华为公司的技术实力，但热身赛刚开始，却颇有一种大家都来找bug的韵味。
- 细数系统上线至今的Bug
- 第一阶段达到80分两个小时后，却无法在第二阶段上传代码
- 上传了代码，过了一天却没有任何评分和反馈
- 登录界面跳转延迟
- 定时更新时，提交代码延迟
（不过，能用就好了，不能要求太多…）
01 赛题解析
赛题摘录
- 在本次比赛中，我们准备了已经做好了特征工程处理的数据和对应的样例代码，您需要优化模型提升准确率和性能。
- 请您结合对机器学习算法的理解并结合鲲鹏处理器的特点对其进行优化，我们将会利用您的代码针对训练数据进行建模，并对测试数据进行预测。
运行要求与判题指标
- 建模+预测要求在15分钟之内完成。
- 模型准确率低于70%不计分，高于70%分为四档，最终执行时间最短者胜出。
- 准确率在 [70%,80%) 之间，其中最终执行时间为实际时间乘以200%。
- 准确率在 [80%,90%) 之间，其中最终执行时间为实际时间乘以150%。
- 准确率在 [90%,95%) 之间，其中最终执行时间为实际时间乘以120%。
- 准确率在 >=95% ，其中最终执行时间为实际时间乘以100%。
赛题解读
- 之前的赛题预测，我提到过，为了照顾参赛者，刚开始不会全线上AI和机器学习。这次的热身赛数据，虽然披着机器学习的外衣，但对参赛者真的是保姆式照顾。跳过数据清洗和特征工程步骤，直接将提取好的特征作为赛题输入，极大的降低了参赛者门槛。
- 通俗讲，赛题打算通过研究现有数据的规律，然后对新数据进行二分类。
- 赛题数据
- 训练数据8000条，1001列。 其中，前1000列为特征，特征数据为浮点型。最后一列表示二分类结果，数据为整型，0和1。
- 测试数据2000条，1000列，全部表示特征，数据为浮点型，正负样本比例接近3:7。
- 判题指标
- 代码运行时，从文件读取开始，经过模型训练和模型测试，到生成结果文件为止。
- 后台对新数据的分类结果进行测试，最终比赛结果以运行时间进行排名。
- 只要够快，70准确率的算法也可以打败100准确率的算法。
- 示例代码
- 完整且规范的输入输出
- 基础的逻辑回归算法实现
02 代码反馈
面对提交后的代码反馈，很多初次提交代码的同学表示疑惑不解。这里，社长对各个参数进行简单介绍。
反馈信息
- 31% THE RESULT IS INCORRECT.
- 这种情况得分为无，表示没有分数。
- 31%，表示测试集的通过率。按判题要求，31小于70，模型准确率低于70%不计分。
- 83% PASSED.
- 这种情况下，有分数。
- 具体的，按照四档要求，与运行时间挂钩。
- 0% TIME LIMIT EXCEEDED.
- 这种情况下，表示超时。
- 有两种情况，其一是你的模型线上时间过长，超过15分钟；其二是你修改了官方路径。
日志下载
- 平时写代码习惯了，都是查看日志来调试。
- 但这里的日志下载，目前来看没什么用。比赛群里答疑专家也说，不提供日志下载。
恕我直言，那，你放个选项在这里有什么用？
假装有日志，黑盒调试？
03 思路分享
始终坚信：最好的成绩可能不是最牛的算法，但肯定是对赛题和业务理解最深入的算法。
线上能有成绩并不难，难的是，有成绩了，却发现读个文件都比别人跑完的时间长。
- 阅读理解要做好
- 官方的题目要求：我们准备了已经做好了特征工程处理的数据和对应的样例代码，您需要优化模型提升准确率和性能。
- 很多人以为只能在官方示例上调试，硬着头皮看LR，到头来终于看懂了，却发现大清亡了，前十都冲进5秒了。
- 建议目光不要被逻辑回归吸引，那只是示例代码，没有说只能对LR优化。目前可以弃疗，着手看看其他算法了。
- 逆向工程大法好
- 之前的推文里有提到逆向工程，比如18年的判题公式漏洞，19年的解死锁判题器。今年，我们同样可以从判题规则出发，开展逆向工程，将规则深入剖析。
- 判题规则提到，正确率区间内，按运行时间计算分数。那么，两者到底是什么关系？“热身2群”里有位参赛者提出了这样的疑问：(acc0.7, 10s*200%) < (acc0.85, 1min*150%) < (acc0.95, 5min*120%) < (acc 0.99, 10min*100%)，最终0.7准确率胜出。所以，相比之下，程序运行时间更有用。
- 在正确率区间内，尽可能调整模型训练参数以降低运行时间。另外，提交的程序中不要有任何输出，比如cout，printf。
- 时间就是生命
- 哪里最耗时，就消灭哪里。以C++为例，通过CLOCK函数对程序各模块运行时间进行监测，找出耗时的痛点，一举解决掉它。
- 上传路径不要动。
- 官方Demo中的各个文件路径，不要修改。否则，会出现0% TIME LIMIT EXCEEDED. 警告。
- 版本控制要做好
- 本来，我以为到正式比赛才会出现这种情况。但昨天下午，群里就有小伙伴发现改不回原来的版本了。这里，社长再啰嗦几句，版本控制一定要做好。
- 不要过于依赖保姆
- 今年赛方真的是一站式保姆的典范，示例中文件的输入输出都写的非常完整。
- 但，官方写的规范但不够大胆，如果最后触及到了I/O瓶颈，一定要记得拿它开刀。
以下是不推荐的做法，这里权当反面教材。
如果这样做，很有可能最后被判定为作弊，切莫以身试法。
- XJB算法之随机调参
- 各届软挑大赛中流传已久的打法，老油条们应该不陌生，无章无法，自成一派。
- 相信大家都知道了线上数据集中的分布，1类接近69%，0类接近31%。所以能不能设置随机种子，随机生成类别？万一呢？
- 线下调参线上用
- 这种打法适用于线上和线下数据集相似的情况，换了数据也不怕。
- 19年有团队线下训练练习赛地图参数，在正式比赛直接读入参数，输入车辆信息，输出规划的路径。然而，最后被踢出榜单了。
- 今年比赛，线下数据集和线上数据集特征维度相同，正负样本比例相似，所以？
04 并行讨论
听信群友传言，社长也对代码做了多线程和多进程处理。
但现实太骨感了，使用欧拉系统线下有效，却线上爆表，说多了都是泪啊…
Base0和Base1均是单进程单线程的处理模式。- 多线程0在
Base0基础上进行改进，两个线程，相较于单线程的时间不降反增。由于多线程涉及上下文切换与线程切换，从结果来看，多线程的切换开销，相较于比单线程所减少的处理时间而言，得不偿失。- 多进程0在
Base0基础上进行改进，父子进程通过共享内存通信，相较于单进程时间上升幅度过大。经过后面分析，发现我在子进程里写了睡眠时间20s，发现判题系统中会跟踪所有进程，不是仅计算父进程的运行时间，这一点大家尤其要注意。- 多进程1在
Base1基础上进行改进。修改上述多进程的问题后，发现时间还是在增大。从结果来看，多进程所涉及的进程切换开销较大，仍是得不偿失。
这里对判题系统和多线程，多进程的使用讨论一下，希望能对各位小伙伴有帮助。
并行与并发
- 并行
- 在处理器上，可以同时运行多条指令。
- 可以同时处理多个任务。
- 并发
- 在处理器上
- 可以处理多个任务，但不是同时。
进程和线程
- 进程的调度和资源分配是操作系统负责
- 线程的调度和资源分配是CPU负责
- 进程是操作系统资源分配(包括cpu、内存、磁盘IO等)的基本单位，一个CPU同时刻只能执行一个进程
- 单核CPU实现多进程，并发。 通过操作系统的进程调度算法，单核CPU进行进程调度的时候，需要读取上下文+执行程序+保存上下文，即进程切换。
- 多CPU实现多进程，并行。 不同的进程运行在不同的CPU上。
- 线程是CPU调度和资源分配的基本单位，一个CPU核心同时刻只能执行一个线程
- 单核CPU实现多线程，并发。 不同线程为了使用CPU核心，则会进行线程切换，但是由于共享了程序执行环境，这个线程切换比进程切换开销少了很多。
- 多核CPU实现多线程，并行。 CPU可以将不同线程分配到不同的CPU核心处理器中。
- 单CPU中进程只能是并发，多CPU计算机中进程可以并行。
- 单CPU单核中线程只能并发，单CPU多核中线程可以并行。
- 并行有上限，进程与CPU个数，线程与CPU核心个数有关，并不是所有线程和所有进程都能同时运行
欧拉判题系统分配的资源是单CPU，4核，8G内存。
根据上面的分析，判题系统上可以实现进程并发，线程并行。
多线程和多进程对比
首先，多进程和多线程没有一劳永逸的应用场景，必须要结合实际情况来判断。
- 多进程
- 数据共享难，需要用到进程间通信
- 同步简单
- 内存占用较多
- CPU利用率低
- 切换开销大
- 创建销毁复杂，速度较慢
- 编程与调试简单
- 多线程
- 共享进程的数据
- 同步复杂，需要用到锁
- 内存占用较少
- CPU利用率高
- 切换开销小
- 创建销毁简单，速度较快
- 编程与调试复杂
大量计算会频繁切换CPU，如有并行处理的必要，建议使用多线程。
具体使用情况，由小伙伴自己决定哦。
读文件到底要不要开多线程
个人理解，读文件触及的是I/O的瓶颈，跟CPU是否并行关系不大，而且本来I/O操作就不怎么耗费CPU，所以仅仅读文件，不建议开启多线程。
- 如果非要使用呢？
- 先忽略线程切换消耗的时间。不同线程切换读文件不同位置的时候，导致磁盘的磁头重新定位就需要一定时间。
- 读取文件到内存进行存储时，要用到互斥锁，锁竞争也会消耗一定时间。
当然，以上都是理论，具体的，可以代码实战哦。
05 好言相劝
之前的推文，有对参赛经验的总结。这里挑选两个重要的，希望对参加热身赛的各位小伙伴有帮助。
- 尽量多划水
- 划群划水划论坛。 划水同学们的福音。混迹八大赛区的群和论坛，与大佬们交流，你总能找到奇思妙想，我是认真的。
- 步步为营
- 先完成，再完美。 比赛一开始，不要考虑过于苛刻的条件和因素。基本思路是魔改基础算法+tips，做好阅读理解，先简化条件，提交一个有成绩代码。在此基础上，再继续迭代算法，相信我，你的心态会完全不一样。
最后，预祝大家都能取得理想的成绩。
欢迎骚扰社长，戳文末二维码与社长交流哦。
完。
如果你喜欢这篇文章，不妨顺手关注下面公众号哦。
