I see a peculiar threads/cpu usage when using ffmpeg to convert a video file (on Haiku Beta4). This is the command line:
ffmpeg -i "Test.mp4" -f avi -vcodec mpeg4 -b:v 1000k -r 30 -acodec ac3 -b:a 128k -ar 44100 -ac 2 "Test.avi"
I have an 8 core i7, 2.3 GHz machine. Pulse shows about 40% usage across all 8 cores at the start, but soon drops to maybe 10% with short 50% spikes on individual cores. In general it seems to fluctuate quite a bit (not sure if it depends on the video contents changing…)
Also curious is the thread count and their core usage (all 8 cores on at the left, 4 cores turned off on the right):
All those lazy ass threads in the middle don’t seem to work at all…
A current Linux Mint shows around 80% cpu usage acoss all cores, relatively stable. No idea about thread count, because I have no idea how to get that info on Linux.
can you compare encoding time ? i get the suspicion is that the memory Management isn’t doing a good job at feeding the CPUs, but it’s just a random ballpark guess.
thread number under Mint: in bash you can run
$ ps -o nlwp <PID>
where PID is the ffmpeg process ID (just run ‘ps’ to see this)
Thanks @topolinik, that’s the output under Linux:
$ ps -o nlwp 3441
So, 34 threads? That’s more than I expected… The system monitor reports ~70% CPU usage of all my 8 cores.
My “benchmark” is a 246 MiB mp4 that gets encoded to a 163 MiB avi, with that same ffmpeg commandline posted farther up. The result:
real 1m40,400s 1m18.950s
user 6m16,824s 6m32.181s
sys 0m7,496s 0m5.454s
here is a great example of why haiku is superior to linux distros in general, small difference in encoding time massive difference in cpu utilization. I’m still willing to bet that haiku could easily encode faster with some memory and CPU pipeline feeding optimization.
a 70% increase in cpu usage for what a 20% in encoding speed, that’s wasted electricity and wtf is the Linux version doing with all that cpu utilization ???
can you test both systems against a external clock ? like a high precision watch or something ?
i for one am quiet skeptical about he stability of Linuxs internal clock monitoring for execution time.
Have you tried putting the source and destination files in a RAM drive or RAMFS? It could be that ffmpeg ends up waiting more on IO than on CPU.
I dont’t have precise timepieces to benchmark with, and frankly, am not really interested in those numbers. I was really just wondering if all those ffmpeg threads under Haiku are also used under Linux, and that seems to be the case.
Also, my initial assessment of a 50% cpu load sinking to 10% may have been a fluke or misreporting of Pulse. I’ve now installed Slayer to keep watch of cpu usage and threads, and it appears to be quite constant at 45-50% (compared to Linux 70%).
I was wondering why have dozens of threads, many of them waiting/idling and the rest not working full speed. After all, I want that encoding done as quickly as possible - why wait 30 minutes at 50% cpu usage when it could be done in 15 minutes at 100% (minus cpu cooling phases… )
IO doesn’t appear to be the bottleneck:
Haiku RAM FS:
ETA: ffmpeg shows a “speed” factor when encoding. Haiku: 9.5x, Linux: 13x.
the IO bottleneck might be the way haiku moves data from disk to ram to cache. I’ll do some thinking on how to figure this out. if i come up with anything I’ll post up and the total speed difference and cpu utilization don’t make sense, it should be relatively linear and it doesn’t appear to be. obviously the haiku version is not adequately supporting the execution pipeline. also the linux version appears to have a lot of useless execution bloat
It would be interesting a small research in this area with different formats, file sizes, video duration, conversion in parallel with other activities, simultaneous conversion of several videos, etc.
I’m kind of wierded out how you are giving linux that much shit for something you didn’t even investigate. Who sais that the speed would be a linear improvement? Also: the usage isn’t directly comparable like this.
i might be deeper into the guts of debian than you are aware of, the gui penalty in linux, is not small. It should be linear btw, if ffmpeg is running same code in both operating systems.
i also noticed that you ignored my being critical of the haiku execution pipeline being poorly managed.
there’s plenty of places you can go feel offended for Linux, is Haiku the best place ??
Again, something you have not proven.
What is the point of this attitude?
It would be much easier to look at differences 1:1 and examine that, as this ffmpeg case does instead of extrapolating from almost nothing and going “oh linux used the cpu more effictively, it’s clearly bloated”
This looks like a job for
DebugAnalyzer to determine where the bottlenecks are, if it doesn’t appear I/O is the problem. Probably worth opening a ticket, as this looks like something that could be “low-hanging fruit”, performance-wise.
You know what just came to me? My cpu is an intel i7-4712MQ @ 2.30 ghz that supposedly can ‘boost’ to 2.9 ghz. Is this boosting done on-chip or does the OS have to trigger it?
If Linux does the boosting and Haiku does not, it may explain the speed difference.
I still don’t know why ffmpeg uses dozens of threads, half of them don’t perceptibly use the cpu, and still just barely make it to 50% overall usage… but maybe that’s by design of ffmpeg…
You can watch this happening in ActivityMonitor, I have added support for CPU frequency display a few months ago (based on low-level work from other developers to report this to userspace, sorry, I forgot who did that)
Cool! Missed that…
All 8 cores hover between 900 and 1000 mhz when idle, while encoding all cores show up to 2800 mhz. So that’s good!
I just saw something worthy of bumping this thread:
FFmpeg is getting better with multithreaded transcoding pipelines | Hacker News (ycombinator.com)
Might be interesting to compare behavior (on Haiku) of the new encoder vs the “old” one