[mythtv] LTO with -O3 optimisations compile support in MythTV?

Piotr Oniszczuk piotr.oniszczuk at gmail.com
Wed Nov 10 21:19:05 UTC 2021



> Wiadomość napisana przez Gary Buhrmaster <gary.buhrmaster at gmail.com> w dniu 10.11.2021, o godz. 17:49:
> 
> On Wed, Nov 10, 2021 at 1:32 PM Piotr Oniszczuk
> <piotr.oniszczuk at gmail.com> wrote:
> 
>> Pls let me know if you are interested to include this into current MythTV master.
> 
> (optional) LTO support has been in master for around
> a year now, and specifying it (and the various overrides
> for gcc and/or clang versions to support lto properly
> across the various compiler versions and implementations)
> and -O3 is really a job for your specific configure flags,
> and "just works for me" when I use them (I think
> the github issue mentioned the required flags to the
> configure step to let it all (optionally) work across the
> various combinations).

Indeed: MythTV code is already good for LTO.
I'm compiling it with LTO since Sep2020 on gcc9.3.

My issue is failing build-in FFmpeg compile for armv7 target when in-line asm is enabled.
As upstream FFmpeg also fails for me on armv7 target - issue root-cause might purely in FFmpeg.

Thing holding me to bother FFmpeg guys (i.e. with bug report) is: probably not enough data points to convenience them.

Structuring this a bit: my failed armv7 inline-asm compile with LTO & -O3 can be result of following possible:

	1. ffmpeg bug so inline-asm are failing for gcc declared cpu caps I declare at compile.
	2. lack of ffmpeg inline-asm support for gcc declared cpu caps I declare at compile.
	3. issue of mine toolchain is exposed in this corner case.

I don't know which one is root cause...

> 
> Did you find you needed to make further changes
> elsewhere in the code for such (optional) support,
> or has no one ever submitted the (upstream) FFmpeg
> bug report (and if this is the previously reported FFmpeg
> bug, it really really needs to be reported upstream first
> and accepted there before cherry picked into the
> MythTV project).

Agree.
But can't answer as still don't know what is root cause: 1 or 2 or 3
 

> 
> FWIW, while I tend to compile my "production" with
> clang and lto (which have generated the better
> results and avoids certain issues I have) the
> improvements are basically small in the tests
> I have done on my systems.  And day to day
> compilation is almost always much slower in
> elapsed time with LTO (so I do not use lto for test
> builds).  

Indeed. LTO + O3 is worth probably only for release builds.

> Do you have any available  performance
> measurements that show much better runtime
> performance in runtime for your use cases?

Unfortunately no in quantified way.
Qualified measures shows me:
- better responsiveness and overall feel of speed - but only on v. slow machines (cortex-a53 @ 1.2GHz or lower)
- significantly lower CPU for sw. video decode. (H6 with cortex-a53 at 1.8 decodes in software average Sat HDTV with 45..65% of CPU). 
(but indeed: majority comes from NEON and can't say what from -O3/LTO)   

> 
> FWIW, I think the best reason to compile with LTO
> (occasionally) is to identify the (past) occasional
> use of the same function name in different
> contexts (which has always been invalid in C++,
> but the MythTV project had a few cases which
> needed to be cleaned up, and, as I recall, were
> fixed in the original github issue/pull).

I'm driving to LTO & -O3 as Myth is quire heavy app - when compared to other players like i.e. Kodi.
Thats why any techniques/tools optimising performance on v.weak CPU is imho important and worth to use. 

Maybe, to get more data points about in-line asm root cause:
somebody else may try to compile mythtv for armv7 target with following:

-mthumb -march=armv7-a+simd -mfloat-abi=softfp -o3 -lto
 
if it will fail - then it will be worth to fix upstream and the backport to myth code



More information about the mythtv-dev mailing list