Luyang

python版本无所谓，3.6/3.7都行，关键是cuda和pytorch版本（我是cuda10/cuda10.1 +Ubuntu18.04的环境） 刚开始conda装的torch-0.4.1 ＋cuda9/cuda92/cudatoolkit10都不行，训练时报错： ``` # RuntimeError: cuda runtime error (11) : invalid argument at # /opt/conda/conda-bld/pytorch_1535493744281/work/aten/src/THC/THCGeneral.cpp:663 ``` 后来把pytorch版本换了一下就可以正常运行了： `conda install pytorch==1.0.1 torchvision==0.2.2 cudatoolkit=10.0` 【仅供参考】

Me too,good question!When I run train.py to train yolo network,once epoch finished,it raise error like: Traceback (most recent call last): File "train.py", line 95, in model.save_weights(str(epoch) + "_yolov3_weight.h5") File ".../anaconda3/envs/tf-2.1/lib/python3.7/site-packages/tensorflow_core/python/keras/engine/network.py",...

同求，resent的分布式多级多卡demo

> `nsys profile --stats=true -o dalle2 python3 test.py ` 利用nsight system工具打开上述结果，发现ComputeVarUsingWelfordWrapper耗时占比非常大，这个ComputeVarUsingWelfordWrapper具体是指什么操作呢，另外如何避免/减少它的开销？ py: 3.8 oneflow: 0.8.0  这个`ComputeVarUsingWelfordWrapper`就是var op的kernel实现，这个kernel实现的效率有问题，暂时还没有修复。如果是网络中用到了`nn.GroupNorm`的话，可以先按照这个pr：https://github.com/Oneflow-Inc/oneflow/pull/8905 中，修改一下GroupNorm中var的实现，可以绕过这个var kernel的问题，大大加速

> 测试的结论是？ 把oneflow 和 plsc 的结果放在一起看看？ 好的，我在readme中增加一栏对比说明

# Arcface-rn50测试结果对比及说明 我们基于同样的硬件环境、同样的网络及数据集，在单机单卡～4机32卡的集群中，对不同框架([paddle-plsc](https://github.com/Oneflow-Inc/DLPerf/blob/dev_paddle_plsc_arcface/PaddlePaddle/PLSC/README.md)及[oneflow](https://github.com/Oneflow-Inc/DLPerf/blob/dev_test_insightface_r50/OneFlow/Recognition/insightface/rn50/README.md))进行了测评，对比框架在大规模人脸模型(模型并行)训练时的吞吐率、加速比等主要性能指标。 ## 测试环境 为保证能更好的测试框架本身的性能好坏，做到公平公正，本次测评所有的测试均在相同的物理集群中测试，使用相同的软件环境等。测试环境共有4台机器，每台机器配置了8张V100 GPU显卡。（每台机器配置与NVIDA DGX-1接近）每台机器具体的硬件和软件配置描述如下： - Tesla V100-SXM2-16GB x 8 - InfiniBand 100 Gb/sec (4X EDR)， Mellanox Technologies MT27700 Family - Intel(R) Xeon(R) Gold 5118 CPU @...

> OK. 辛苦了。 韩广云测试的环境是10Gbps的带宽，和我们配置不一样。 恩，上面贴的数据都是在leinao相同环境上测的

你好，首先请确保GPU环境是：GPU：Tesla V100-SXM2-16GB x 8，其次可能的原因有docker运行时未设定足够大小的内存，如： `--shm-size=16g`

训练过程中还发现： - 1.通过horovodrun时，数据加载时会48core占满100%，正式训练开始不会满(差不多是能有48个core都占用不到50%) - 2.mpirun -bind-to none时效果同上；mpirun -bind-to core，这种方式可以限制进程数，使得2机数据加载和训练时只会占用16个core，不过速度是比占满时慢一些的（肉眼估算大约30%） - 3.horovodrun时1组7次训练几乎只有1~2次能正常跑完、mpirun就比较稳基本不会报异常，具体原因未能确定（可能是horovodrun不太稳定或者遭遇端口通信异常） mpirun参数可见：https://www.open-mpi.org/doc/current/man1/mpirun.1.php

> > * 通过mpi运行时，可添加参数-x NCCL_DEBUG=INFO查看nccl输出 > > > > ```shell > > mpirun -oversubscribe -np ${gpu_num} -H ${node_ip} \ > > -bind-to none -map-by numa \ > > -x NCCL_DEBUG=INFO...