[FFmpeg-user] A question about -benchmark_all
Nicolas George
george at nsup.org
Fri Feb 6 13:31:24 CET 2015
L'octidi 18 pluviôse, an CCXXIII, rongyan a écrit :
> When I use -benchmark_all to record the x264 encoding time, I found the
> number for single thread is 16264711, while for the same bitstream, the
> number for the multithreads is 85186340. From the number , the
> multithreads use more time than the single thread, it does not make sense.
It would not make sense for it to take LESS time, since it performs the same
amount of work (the encoding) and more (the synchronization). Remember that
this kind of benchmark counts the total computing time: two threads running
for one minute will count two minutes.
Still, a >5 overhead factor is a bit too much just for synchronization.
> Multiple thread (the log file shows the number of threads is 128):
This is a very large number of threads. What is the hardware exactly? In
particular, how many processors, cores per processor and hyperthreading
threads per core?
Hyperthreading can explain a ×2 overhead factor, possibly even ×4, since
threads running on the same core doing similar tasks share the same
computing power and therefore run as many times slower.
With that many threads, memory bandwidth is also probably a huge overhead.
IMHO, for that kind of processing 8 8-core boxes would be more efficient
than one 128-core one.
> I look at the code, found the record update is before/after each thread
> schedule, so my question is whether or not -benchmark_all can accurate
> record the encoding time? Or it in deed records the time not for encoding
> itself?
With threads enabled, -benchmark_all may be quite a bit off in associating
precise task to each time: it may count for decoding time that was taken by
encoding, or the other way around.
The total time, though, is accurate.
Regards,
--
Nicolas George
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <https://ffmpeg.org/pipermail/ffmpeg-user/attachments/20150206/2aef437f/attachment.asc>
More information about the ffmpeg-user
mailing list