forked from ccf-ai-infra/GPUCodeForces
Gitee
commit
5d82165cf7
84
FAQ.md
84
FAQ.md
|
|
@ -1,48 +1,40 @@
|
|||
# S1 GPUCodeForces FAQ
|
||||
# 第一期S1 评测数据集生成挑战赛（GPUCodeForces） FAQ
|
||||
|
||||
# 2025/8/26
|
||||
## Q1：数据集主题是否太过宽泛？是否需要增加特定限制条件来帮助参赛者聚焦某一领域下研究？
|
||||
|
||||
Q1：数据集主题是否太过宽泛？是否需要增加特定限制条件来帮助参赛者聚焦某一领域下研究？
|
||||
## A1：不做限制，看重性能。
|
||||
|
||||
A1：不做限制，看重性能。
|
||||
**经典计算密集型任务**
|
||||
* _矩阵乘法（GEMM）_
|
||||
* _卷积（Convolution）_
|
||||
* _快速傅里叶变换（FFT）_
|
||||
* _排序（Sorting）_
|
||||
* _规约（Reduction）_
|
||||
* _扫描（Scan）_
|
||||
|
||||
**经典计算密集型任务** _矩阵乘法（GEMM）_
|
||||
**图像/视觉处理任务**
|
||||
|
||||
_卷积（Convolution）_
|
||||
* _图像滤波（高斯模糊、边缘检测）_
|
||||
* _图像变形（Warping）_
|
||||
* _光流计算_
|
||||
|
||||
_快速傅里叶变换（FFT）_
|
||||
**新兴或特定领域任务**
|
||||
|
||||
_排序（Sorting）_
|
||||
* _MoE（Mixture of Experts）中的专家路由_
|
||||
* _稀疏矩阵运算_
|
||||
* _图神经网络中的聚合操作_
|
||||
|
||||
_规约（Reduction）_
|
||||
**深度学习常见算子**
|
||||
|
||||
_扫描（Scan）_
|
||||
* _LayerNorm / BatchNorm_
|
||||
* _Softmax / LogSoftmax_
|
||||
* _Attention 机制（Self-Attention, Cross-Attention）_
|
||||
* _激活函数（如 Swish, GELU）_
|
||||
* _损失函数（如 CrossEntropy）_
|
||||
|
||||
**图像/视觉处理任务** _图像滤波（高斯模糊、边缘检测）_
|
||||
## Q2：JSON文件的格式似乎没有明确规定？如下能有一个直观的输出例子会更好
|
||||
|
||||
_图像变形（Warping）_
|
||||
|
||||
_光流计算_
|
||||
|
||||
**新兴或特定领域任务** _MoE（Mixture of Experts）中的专家路由_
|
||||
|
||||
_稀疏矩阵运算_
|
||||
|
||||
_图神经网络中的聚合操作_
|
||||
|
||||
**深度学习常见算子** _LayerNorm / BatchNorm_
|
||||
|
||||
_Softmax / LogSoftmax_
|
||||
|
||||
_Attention 机制（Self-Attention, Cross-Attention）_
|
||||
|
||||
_激活函数（如 Swish, GELU）_
|
||||
|
||||
_损失函数（如 CrossEntropy）_
|
||||
|
||||
Q2：JSON文件的格式似乎没有明确规定？如下能有一个直观的输出例子会更好
|
||||
|
||||
A2：提交可运行目录即可，无需特定格式json。
|
||||
## A2：提交可运行目录即可，无需特定格式json，如下：
|
||||
|
||||
```plaintext
|
||||
{
|
||||
|
|
@ -55,26 +47,18 @@ A2：提交可运行目录即可，无需特定格式json。
|
|||
}
|
||||
```
|
||||
|
||||
Q3：建议补充错误处理和边界情况说明（比如输入为非方阵、极端大小等情况）
|
||||
## Q3：建议补充错误处理和边界情况说明（比如输入为非方阵、极端大小等情况）
|
||||
|
||||
A3：若前项评分相同，看加分项的评分。评测反馈交互在PR，当选手提交PR相同的时候作为额外加分项时裁判会根据这些细节进行打分，也会对比赛最后结果有一定的影响。
|
||||
## A3：若前项评分相同，看加分项的评分。评测反馈交互在PR，当选手提交PR相同的时候作为额外加分项时裁判会根据这些细节进行打分，也会对比赛最后结果有一定的影响。
|
||||
|
||||
Q4：评分规则这里明确了评估方面但没有给出具体数值范围，添加一个范围会不会更好？各方面评估是否增加分段会更好（执行时间评估-->0.1s +1分，0.01s+2分...-->最高+5分）？
|
||||
## Q4：评分规则这里明确了评估方面但没有给出具体数值范围，添加一个范围会不会更好？各方面评估是否增加分段会更好（执行时间评估-->0.1s +1分，0.01s+2分...-->最高+5分）？
|
||||
|
||||
A4：核数量排名优先，同级再看评分。
|
||||
## A4：核数量排名优先，同级再看评分。
|
||||
|
||||
Q5：提供prompt让LLM生成代码，如何确保【同样prompt每次都生成不同的代码】的不确定性带来的代码质量不稳定，从而引发的评分不稳定问题？
|
||||
## Q5：提供prompt让LLM生成代码，如何确保【同样prompt每次都生成不同的代码】的不确定性带来的代码质量不稳定，从而引发的评分不稳定问题？
|
||||
|
||||
A5：一般不会出现这种问题，评测相对稳定。
|
||||
## A5：一般不会出现这种问题，评测相对稳定。
|
||||
|
||||
Q6：参赛者除了提交后能知道评分后，还能有其他方法能够更快地知道评分吗（本地评测模型、评分手册对照）？
|
||||
## Q6：参赛者除了提交后能知道评分后，还能有其他方法能够更快地知道评分吗（本地评测模型、评分手册对照）？
|
||||
|
||||
A6：评测本身速度就足够快，不用担心这个问题。
|
||||
|
||||
|
||||
|
||||
# 改进的地方：
|
||||
|
||||
1. 核数量排名脚本
|
||||
|
||||
2. 再出一版参赛说明，详情解释文档内各文件的作用
|
||||
## A6：建议直接用给到的算力平台的环境进行验证后再提交，代码托管平台评测本身速度就足够快，不用担心这个问题，后续主办方也会提供实时排名。
|
||||
Loading…
Reference in New Issue