[prev in list] [next in list] [prev in thread] [next in thread] 

List:       mythtv-dev
Subject:    Re: [mythtv] LTO with -O3 optimisations compile support in MythTV?
From:       Piotr Oniszczuk <piotr.oniszczuk () gmail ! com>
Date:       2021-11-10 21:19:05
Message-ID: 3F651019-F2DF-4B18-9D5E-2F82FA0DF803 () gmail ! com
[Download RAW message or body]



> 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


[prev in list] [next in list] [prev in thread] [next in thread]