On Thu, Apr 22, 2021 at 11:00:40PM -0700, Khem Raj wrote: > On Thu, Apr 22, 2021 at 10:49 PM <mikko.rap...@bmw.de> wrote: > > > > On Thu, Apr 22, 2021 at 08:05:20AM -0700, Khem Raj wrote: > > > On Thu, Apr 22, 2021 at 7:42 AM Mikko Rapeli <mikko.rap...@bmw.de> wrote: > > > > > > > Currently lz4 uses it's own defaults which include O3 optimization. > > > > Switch from O3 to bitbake default O2 reduces binary package size > > > > from 467056 to 331888 bytes. Enables also building with Os if needed. > > > > > > > > > These could impact runtime performance have you > > > Checked what the rough impact is ? > > > > Nope, have not checked this. I've build my targets with this patch > > and have not noticed any major performance regression. If there is > > a performance problem, then I'd rather see O3 explicitly set in the recipe, > > for example for native target. > > > > > Secondly we will be using non default set which could result in errors > > > less > > > seen by others over time I have realized it’s also good to open a dialog > > > upstream and get the reasoning behind not letting distro defaults apply > > > some packages do have valid reasons > > > > I've seen bugs with O3 optimziation level too on some target archs. > > I would not enable that by default. But I do understand your concern. > > > > In similar ways, I was checking ffmpeg, attr, acl etc which were defaulting > > to O3 in older versions but with new poky master versions now behave well > > and use bitbake default O2. I guess there too no major performance > > regressions > > have been detected. > > > > Thanks for checking this out. Perhaps it will be good to ping upstream > and raise this > that we are changing default opts, are there any concerns we should know.
Well, to me the global optimization flags set by bitbake are a distro wide policy which we on bitbake side are allowed and should do when ever we please. Upstreams may have different opinions, but all I've seen is that those who think O3 is good or better, usually end up adding a lot of workarounds due to various buggy compiler versions, e.g. fall back to O2. I checked lz4 chat and found this which even says that O2 is faster on some arch and benchmark: https://groups.google.com/g/lz4c/c/L0caJWd-vCY Now, if anyone wants to try to use Os everywhere to reduce binary sizes, then respecting bitbake compile flags becomes important. The exceptions to the defaults need to be evaluated per use case, per target and with measurements. And sorry, for this change I don't have measurements of the effect except for binary size. -Mikko
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#150827): https://lists.openembedded.org/g/openembedded-core/message/150827 Mute This Topic: https://lists.openembedded.org/mt/82287155/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
