Mailing List Archive

LTO with -O3 optimisations compile support in MythTV?
Guys,

I have FFmpeg MythTV patches implementing successful compile of MythTV with LTO with -O3 optimisations on x86_64/armv7/aarch64.

Pls let me know if you are interested to include this into current MythTV master.

br

_______________________________________________
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-dev
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org
Re: LTO with -O3 optimisations compile support in MythTV? [ In reply to ]
On Wed, Nov 10, 2021 at 1:32 PM Piotr Oniszczuk
<piotr.oniszczuk@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).

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).

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). Do you have any available performance
measurements that show much better runtime
performance in runtime for your use cases?

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).
_______________________________________________
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-dev
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org
Re: LTO with -O3 optimisations compile support in MythTV? [ In reply to ]
> Wiadomo?? napisana przez Gary Buhrmaster <gary.buhrmaster@gmail.com> w dniu 10.11.2021, o godz. 17:49:
>
> On Wed, Nov 10, 2021 at 1:32 PM Piotr Oniszczuk
> <piotr.oniszczuk@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@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

_______________________________________________
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-dev
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org