FM-PS初步性能分析

目标

使系统能够发挥分布式的能力,即scalability.

实验设计

假设(设定提交任务部分延迟相对于训练是可以忽略不计的)
若有两个Tworker和一个Pserver,每个Tworker负责5000张image的数据
则对比对象则是一个进程单独负责训练,负责10000张训练数据
时间(time)和计算资源(cpu使用率)的分布会是什么样呢?

单进程实验

epoch:5
mini_batch_size:15
training_data_size:10000
evaluation_data_size:500
可以看到训练时间占了几乎百分之百的部分
其中train:14.988s, evaluation:0.598s
那么训练中的时间是如何分布的呢?

至此我们可以以此为baseline,先初步观察一下单Pserver单Tworker的时间分布

单Pserver单Tworker

epoch:5
mini_batch_size:15
training_data_size:10000
evaluation_data_size:500
采取和单进程一样的配置

预想

可以设想,由于优化器在Pserver上,所以forwardbackward的时间综合应该要持平
对于Tworker来说:
optimizer的时间 =
pull + push + fill + extract(get_gradient_from_network) + slice_gradient
之前单进程的时间的是4.044秒

分析

训练时间

可以看到这次花在训练上的时间是60s左右,比baseline慢了四倍之多。
所以现在需要分析是不是按我们的预想的分布来发展.
pull/push次数应该是:10000*5/15 = 3333(次)
时间分布

one_batch_forward_and_backward

训练分布

可以看到训练时间的分布基本符合我们的预期,也就是说,四倍的开销均来源于优化器部分的实现。

优化器

optimizer的时间 =
pull + push + fill + extract(get_gradient_from_network) + slice_gradient
已知baseline:4.044秒
根据上述公式我们得到:
pull(24.982) + push(3.657) + fill_and_extract(0.2) + slice_gradient(19.512) = 48.351秒
因此接下来需要详细分析如何减小这一部分的时间消耗

PULL

pull_parameter函数时间分布

1.对于pull,RPC调用,目前是在本机的一对一通信,0.9秒并不是主要的部分,但可以预见若worker和server数量增加,该部分的开销会增加,同时,若在不同机器上网络延迟会进一步影响该项性能,值得以后多注意,但目前不是主要目标。

2.可以看到调用了20040次构建ndarray,这让pull成为主要的性能瓶颈。那么正确的实现应该是如何调用呢?
可以猜测的是现在的实现是存在问题的,对于目前的神经网络来说,是6个参数,1-3层的权重和偏置,那么应该只有在第一次拿到参数时需要构建array,之后每一次都把对应key的参数赋值进array,而不是每一次都创建一个新的ndarray。

3.可以看到反序列化的开销也是占比较大的一块,花费了3.735秒,对于这一块,可以将python实现的ParserFromString替换为底层是c++实现的代码,从而降低这里的时间占比

Slice Gradient

分析

1.可以看到这里也有和pull一样的问题,大量的时间花在对于每一个参数数值的填充上,可以改成在第一次时创建相应的梯度PB对象,之后维护PB对象,对其值进行更新,而不是每一次都创建PB对象,再构造一个结构无异的梯度组。
2.替换python实现的protobuf函数为底层c++实现的代码

PUSH

push端的性能问题主要在Pserver端如何相应RPC调用上,因此接下来转入C++实现的Pserver端的性能分析

  //遍历key-gradient pair
  for(size_t i = 0; i < size; i++){
    const task::KeyValuePair& pair = kth_gradient.pairs(i);
    const uint32_t pair_size = pair.values_size();
    vector<uint32_t> shape{pair_size};
    gradients_[pair.name()] =  make_shared<VectorParameter>(1, shape);
    for(int j = 0; j < pair_size; j++){
      gradients_[pair.name()]->values[j] = pair.values(j);
    }
  }
  //update
  //TODO:
  //交给线程在背后detach去做
  update_parameter();

可以看到有同样的问题,在响应push请求时,不断的构造出了新的array或者Matrix导致时间大量的消耗,同时对于参数更新不应该在push函数内进行更新,可以启动一个(detach)线程在背后去更新,然后立即返回

©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 204,053评论 6 478
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 85,527评论 2 381
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 150,779评论 0 337
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 54,685评论 1 276
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 63,699评论 5 366
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 48,609评论 1 281
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 37,989评论 3 396
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 36,654评论 0 258
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 40,890评论 1 298
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 35,634评论 2 321
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 37,716评论 1 330
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 33,394评论 4 319
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 38,976评论 3 307
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 29,950评论 0 19
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 31,191评论 1 260
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 44,849评论 2 349
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 42,458评论 2 342

推荐阅读更多精彩内容