关于pytorch1.0

[ww451575464]

你好，我在pytorch1.0上进行的训练，修改了
if torch.mean(preds0_prob[text_begin:text_begin+len(sim_preds0[j].split('$')[0]+'$')]).item() >
torch.mean(preds1_prob[text_begin:text_begin+len(sim_preds1[j].split('$')[0]+'$')]).item():
将.data[0]改为.item()，训练是可以进行的了，按照readme所说，只是训练变慢，应该不会还有什么后遗症吧

[Canjie-Luo]

如果您能够成功测试的话，检查输出的结果没有问题，那就可以了。欢迎一起维护和开发新版本。

[gzhcv]

hello，我在用torch1.0版本时发现一个奇怪的问题。按照 @ww451575464 的方式修改了代码，在服务器A上运行没有问题。但是在服务器B上运行会卡在main.py的150行 data = val_iter.next()，所以怀疑是读数据时卡住了，我把num_work参数设为0num_work=0后就能正常运行了。 我查了下这个参数的含义：

num_workers，从注释可以看出这个参数必须大于等于0，0的话表示数据导入在主进程中进行，其他大于0的数表示通过多个进程来导入数据，可以加快数据导入速度

服务器B的CPU配置是：物理CPU1个，6核，逻辑CPU核数总共12。
服务器A的CPU配置是：物理CPU2个，每个CPU有8核，逻辑CPU核数总共32。

难道是因为服务器B的CPU核数太少？(每个训练程序CPU占用率才100%，感觉有点奇怪，太少了，服务器B上用torch0.3版CPU占用率映像中能到600%，num_work=2)

因为num_work的数量设大一点可以加速，所以还是想能不能解决这个问题？ 有什么建议嘛？ @Canjie-Luo

[Canjie-Luo]

您的机器真多，真羡慕...这个我也没啥经验，希望大家一起讨论和启发

[ww451575464]

@gzhcv 我也经常卡在那里，，，ctrl+c关了重试几次就好了，，，后来我改为用enumerate迭代，反正是个迭代器。不过这个和num_work是否有关就不是很清楚了

[gzhcv]

@ww451575464 可能还是和num_work以及CPU配置有关。 我用enumerate和list试了一下，都卡在那里了。多试几次确实能奏效，不过我这得试很多次才成功，这也是很奇葩的现象

[gzhcv]

@Canjie-Luo 我这是暴殄天物，用了这多机器也没做出什么来。 您在资源有限的情况下能做出这么好的工作，佩服