From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from ffbox0-bg.mplayerhq.hu (ffbox0-bg.ffmpeg.org [79.124.17.100]) by master.gitmailbox.com (Postfix) with ESMTP id 714F842E6C for ; Thu, 8 Sep 2022 20:25:39 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id 78C2568BAA4; Thu, 8 Sep 2022 23:25:37 +0300 (EEST) Received: from relay8-d.mail.gandi.net (relay8-d.mail.gandi.net [217.70.183.201]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id 5509168B9D0 for ; Thu, 8 Sep 2022 23:25:31 +0300 (EEST) Received: (Authenticated sender: michael@niedermayer.cc) by mail.gandi.net (Postfix) with ESMTPSA id 6B6B31BF206 for ; Thu, 8 Sep 2022 20:25:29 +0000 (UTC) Date: Thu, 8 Sep 2022 22:25:28 +0200 From: Michael Niedermayer To: FFmpeg development discussions and patches Message-ID: <20220908202528.GB2088045@pb2> References: <20220908173911.GA2088045@pb2> MIME-Version: 1.0 In-Reply-To: Subject: Re: [FFmpeg-devel] [PATCH 2/2] swscale/input: Avoid calls to av_pix_fmt_desc_get() X-BeenThere: ffmpeg-devel@ffmpeg.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: FFmpeg development discussions and patches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: FFmpeg development discussions and patches Content-Type: multipart/mixed; boundary="===============1333647097223781985==" Errors-To: ffmpeg-devel-bounces@ffmpeg.org Sender: "ffmpeg-devel" Archived-At: List-Archive: List-Post: --===============1333647097223781985== Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="9U2a9f8T4tDTLWgN" Content-Disposition: inline --9U2a9f8T4tDTLWgN Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Sep 08, 2022 at 09:38:51PM +0200, Andreas Rheinhardt wrote: > Michael Niedermayer: > > Hi > >=20 > > On Thu, Sep 08, 2022 at 04:38:11AM +0200, Andreas Rheinhardt wrote: > >> Up until now, libswscale/input.c used a macro to read > >> an input pixel which involved a call to av_pix_fmt_desc_get() > >> to find out whether the input pixel format is BE or LE > >> despite this being known at compile-time (there are templates > >> per pixfmt). Even worse, these calls are made in a loop, > >> so that e.g. there are six calls to av_pix_fmt_desc_get() > >> for every pair of UV pixel processed in > >> rgb64ToUV_half_c_template(). > >> > >> This commit modifies these macros to ensure that isBE() > >> is evaluated at compile-time. This saved 9743B of .text > >> for me (GCC 11.2, -O3). > >=20 > > hmm, all these functions where supposed to be optimized out > > why where they not ? > >=20 > > iam asking as the code is simpler before your patch if that > > "optimization out" thing would work > >=20 >=20 > Why should these functions be optimized out? What would enable the > compiler to optimize them out? Going back into the past, there was 6b0768e2021b90215a2ab55ed427bce91d148148 before this the code certainly did get optimized out, it was just #define isBE(x) ((x)&1) thats simple and clean code btw after this it became #define isBE(x) \ + (av_pix_fmt_descriptors[x].flags & PIX_FMT_BE) thats still really good, and very readable, its a const array so one would assume that a compiler can figure that out at compile time well, i try not to think of linking and seperate objects here ;) next it got then replaced by a function and a call that i suspect people thought would be inlined > (And I really don't see why this patch would make the code more > complicated.) the code historically was capable to lookup any flag and detail of a pixel format at compile time now your code works around that not working. Introducing a 2nd system to do this in parallel. To me if i look at the evolution of isBE() / code checking BE-ness it become more messy over time I think it would be interresting to think about if we can make av_pix_fmt_desc_get(compile time constant) work at compile time. or if we maybe can return to a simpler implementation thx [...] --=20 Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Awnsering whenever a program halts or runs forever is On a turing machine, in general impossible (turings halting problem). On any real computer, always possible as a real computer has a finite number of states N, and will either halt in less than N cycles or never halt. --9U2a9f8T4tDTLWgN Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iF0EABEIAB0WIQSf8hKLFH72cwut8TNhHseHBAsPqwUCYxpPtAAKCRBhHseHBAsP q+VbAKCW5wmTUafT6Ra+G+XVsVDOrbm06wCcDxsXfZa7tj8mR3+vweUffgHyQfE= =vbjN -----END PGP SIGNATURE----- --9U2a9f8T4tDTLWgN-- --===============1333647097223781985== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe". --===============1333647097223781985==--