Hi, Paul ----- Original Message ----- > From: "Paul B Mahol" <one...@gmail.com> > To: "FFmpeg development discussions and patches" <ffmpeg-devel@ffmpeg.org> > Sent: Tuesday, September 1, 2020 10:46:54 PM > Subject: Re: [FFmpeg-devel] [PATCH 1/3][GSoC] Add mutithread function for > dnn_backend_native_layer_conv2d.c
> On 9/1/20, Xu Jun <xuju...@sjtu.edu.cn> wrote: >> Hi, Mark >> >> ----- Original Message ----- >>> From: "Mark Thompson" <s...@jkqxz.net> >>> To: "FFmpeg development discussions and patches" <ffmpeg-devel@ffmpeg.org> >>> Sent: Tuesday, September 1, 2020 4:41:06 AM >>> Subject: Re: [FFmpeg-devel] [PATCH 1/3][GSoC] Add mutithread function for >>> dnn_backend_native_layer_conv2d.c >> >>> On 31/08/2020 18:03, xuju...@sjtu.edu.cn wrote: >>>> From: Xu Jun <xuju...@sjtu.edu.cn> >>>> >>>> Use pthread to multithread dnn_execute_layer_conv2d. >>>> Can be tested with command "./ffmpeg_g -i input.png -vf \ >>>> format=yuvj420p,dnn_processing=dnn_backend=native:model= \ >>>> espcn.model:input=x:output=y -y sr_native.jpg -benchmark" >>>> >>>> before patch: utime=11.238s stime=0.005s rtime=11.248s >>>> after patch: utime=20.817s stime=0.047s rtime=1.051s >>> >>> Can you explain why it uses almost twice as much total CPU time after the >>> patch? >>> That seems rather more than can be explained away as scheduling overhead. >>> >>> If it's actually doing significantly more then maybe you want to document >>> somewhere that enabling threading will improve latency at the cost of >>> throughput. >> >> I have done some test and find that utime is strongly correlated with CPU >> HyperThreading technology. >> >> When I turn off my CPU HyperThreading technology using command "echo off > >> /sys/devices/system/cpu/smt/control" in root user, the utime gets stable >> whatever the number of threads I have created, and is same to that before >> patch. >> >> When CPU HyperThreading technology is on, once the number of threads I >> create gets close to physical cores' number my cpu has, or even bigger, the >> utime will get bigger simultaneously. When I use as many threads as the >> logical cores' number of my cpu, the utime will be twice of that before >> patch. >> >> Therefore, I think HyperThreading technology make the logical cores twice >> the physical cores while the counting power is not twiced. And for ffmpeg >> utime, it sums all logical cores' runtime. So it seems to be twice of that >> before patch. >> >> In the next version, I will open an API for user to choose how many threads >> to use in native backend. And I'm going to set the default threads number to >> physical cores' number - 1 in order to get better performance while not >> increasing utime much on the plantforms which support HyperThreading. > > -threads option is already available for filters that use slice threads. Actually the native backend of DNN module in libavfilter does not support slice thread. So it does not use -threads option. The thread function I added just have effect in the conv2d layer of DNN's native backend, and is not the same with slice thread in filter level. > > Make sure that your threads do not share same memory for reading/writting. I will carefully think about the timing in program running and operate adequate test for that to avoid such bugs. - Xu Jun > >> >> As for the rtime, setting threads' number to logical cores - 1 will get >> about 20%-30% performance improvement over setting threads' number to >> physical cores - 1 in my test. >> >> - Xu Jun >> >>> >>> - Mark >>> _______________________________________________ >>> ffmpeg-devel mailing list >>> ffmpeg-devel@ffmpeg.org >>> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel >>> >>> To unsubscribe, visit link above, or email >>> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". >> >> _______________________________________________ >> ffmpeg-devel mailing list >> ffmpeg-devel@ffmpeg.org >> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel >> >> To unsubscribe, visit link above, or email >> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". > _______________________________________________ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
