Skip to content

Latest commit

 

History

History
64 lines (44 loc) · 2.63 KB

FAQ.md

File metadata and controls

64 lines (44 loc) · 2.63 KB

第一期S1 评测数据集生成挑战赛(GPUCodeForces) FAQ

Q1:数据集主题是否太过宽泛?是否需要增加特定限制条件来帮助参赛者聚焦某一领域下研究?

A1:不做限制,看重性能。

经典计算密集型任务

  • 矩阵乘法(GEMM)
  • 卷积(Convolution)
  • 快速傅里叶变换(FFT)
  • 排序(Sorting)
  • 规约(Reduction)
  • 扫描(Scan)

图像/视觉处理任务

  • 图像滤波(高斯模糊、边缘检测)
  • 图像变形(Warping)
  • 光流计算

新兴或特定领域任务

  • MoE(Mixture of Experts)中的专家路由
  • 稀疏矩阵运算
  • 图神经网络中的聚合操作

深度学习常见算子

  • LayerNorm / BatchNorm
  • Softmax / LogSoftmax
  • Attention 机制(Self-Attention, Cross-Attention)
  • 激活函数(如 Swish, GELU)
  • 损失函数(如 CrossEntropy)

Q2:JSON文件的格式似乎没有明确规定?如下能有一个直观的输出例子会更好

A2:提交可运行目录即可,无需特定格式json,如下:

{
  "task_name": "matrix_multiplication",
  "description": "...",
  "input_generator": "code snippet or function name",
  "gt_generator": "code snippet or function name",
  "metrics": ["time", "throughput", "bandwidth"],
  "prompt": "Optional prompt for LLM"
}

Q3:建议补充错误处理和边界情况说明(比如输入为非方阵、极端大小等情况)

A3:若前项评分相同,看加分项的评分。评测反馈交互在PR,当选手提交PR相同的时候作为额外加分项时裁判会根据这些细节进行打分,也会对比赛最后结果有一定的影响。

Q4:评分规则这里明确了评估方面但没有给出具体数值范围,添加一个范围会不会更好?各方面评估是否增加分段会更好(执行时间评估->0.1s +1分,0.01s+2分...->最高+5分)?

A4:核数量排名优先,同级再看评分。

Q5:提供prompt让LLM生成代码,如何确保【同样prompt每次都生成不同的代码】的不确定性带来的代码质量不稳定,从而引发的评分不稳定问题?

A5:一般不会出现这种问题,评测相对稳定。

Q6:参赛者除了提交后能知道评分后,还能有其他方法能够更快地知道评分吗(本地评测模型、评分手册对照)?

A6:建议直接用给到的算力平台的环境进行验证后再提交,代码托管平台评测本身速度就足够快,不用担心这个问题,后续主办方也会提供实时排名。