From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from spam02.hesby.net (spam01.hesby.net [81.29.32.152]) by sourceware.org (Postfix) with ESMTP id 419853858D20 for ; Tue, 27 Feb 2024 16:21:36 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 419853858D20 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=hesbynett.no Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=hesbynett.no ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 419853858D20 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=81.29.32.152 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1709050899; cv=none; b=iOOOHK0USu5CeR5I/bMj0nV2imO2lcNf8SS+WKki26BnJgGXWWX7941/rakcumMrdnUaDirptWWaQ9knz52uF0fdIM7D1Nlp7ZkxiDH5gGF4JOUYt+fKuEm30GV7HmLEnDCPhqXSTP84TotZDZ6CB9hZAkz+JwjCpOaUiQt1cK0= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1709050899; c=relaxed/simple; bh=OjKj/i7C5xtFXZyY0Q58d6IOQaJgY9LCx1SpeDSQhDI=; h=Message-ID:Date:MIME-Version:Subject:To:From; b=ofvLcCrZR8DS2jQUMeQVf74jehwraYj3vGxXlWPoMPP7SdXzzWn3I7VRYj4uWgnrae2vcIQpoicK6Ly/4NrHurK+hTxWplatftFHvk2TPOtuNrad8JzjJJx0RKY63hNu/nfIy4yV3LN2fu7t4gpytE/VsTXdPMdD70cJE6XB43I= ARC-Authentication-Results: i=1; server2.sourceware.org Received: from [192.168.0.63] (unknown [79.161.10.130]) by spam02.hesby.net (Halon) with ESMTPSA id 4368228b-d58c-11ee-841f-506b8dfa0e58; Tue, 27 Feb 2024 17:21:34 +0100 (CET) Message-ID: <0d7e9daf-062b-123a-9a7c-d9e9b2227947@hesbynett.no> Date: Tue, 27 Feb 2024 17:21:29 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.11.0 Subject: Re: Gcc version affects program execution efficiency Content-Language: en-GB To: abzhou36 , gcc-help@gcc.gnu.org References: <588501a5.1197e.18deacf4429.Coremail.abzhou36@163.com> From: David Brown In-Reply-To: <588501a5.1197e.18deacf4429.Coremail.abzhou36@163.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-3032.7 required=5.0 tests=BAYES_00,DEAR_SOMETHING,KAM_DMARC_STATUS,KAM_SHORT,NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: Hi, Version 9.4 is quite old - from you can see that gcc 11.4 is the oldest version still actively supported by the gcc development team. Ubuntu, or their upstream source Debian, might still support older gcc. So there are limits to how much help you can get here - basically, you get people like me (a user) giving you suggestions on how to find out more yourself. That said, if there is a significant regression here, it's possible that it also applies to newer gcc, and therefore be important to identify, and if it turns out to be a real and current performance regression, you can file a bug for the experts to consider. The first thing to do in cases like this is to make sure you have a sensible choice of compiler options (such as optimisation flags) and that they are the same for both compilers. The next step is to isolate a compilable stand-alone version of the function. That does not take much here, but it needs a little - a typedef for uint_8, and some kind of definition for SOFO and COM (I have no idea what these should be). Then put the code into the fantastic site , and compare versions. I've made a start here: From here, we can quickly see that the current trunk gcc generates the same code (at -O2) as for 9.4, and that this is noticeably different from gcc 7.5. It is also easy to check that the gcc 8 series generates the same code as 7.5, so this has been affected by a change made between gcc 7 and gcc 8. It is not at all easy to know what speed differences there are between these code versions. So this is something /you/ can do - measure the speed of this function with gcc 7.5 and 9.4, to see what difference you are seeing in practice. (And when giving the results, include brief information about the processor.) Now with the generated code easily visible, someone with more experience than me at x86_64 and the code generation (especially changes between gcc 8 and 9) can maybe see what's going on, and whether or not it is a problem. David On 27/02/2024 14:44, abzhou36 via Gcc-help wrote: > Dear Sir or Madam > > > > > I used ffmpeg for hardware acceleration of video decoding and compiled ffmpeg using gcc-9.4 on the Ubuntu 20.04 system. > However, its performance is poor. If gcc-7.5 is used on the same Ubuntu 20.04 system, the decoding performance will be better. > > > I analyzed the code of ffmpeg and found that there is a big difference in time consumption when use gcc-9.4 and gcc-7.5 in the following functions: > static int find_marker(const uint_8 **pbuf_ptr, const uint_8 *buf_end) > { > const uint_8 *buf_ptr; > unsigned int v, v2; > int val; > int skipped = 0; > > buf_ptr = *pbuf_ptr; > while (buf_end - buf_ptr > 1) { > v = *buf_ptr++; > v2 = *buf_ptr; > if (v == 0xff && v2 >= SOFO && v2 <= COM) { > val = *buf_ptr++; > goto found; > } > skipped++; > } > buf_ptr = buf_end; > val = -1; > found: > *pbuf_ptr = buf_ptr; > return val; > } > > > I want to know why this difference arises and how to solve this problem. > > > I look forward to your help. > > > Thanks and Regards. > Aibin