From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from nikam.ms.mff.cuni.cz (nikam.ms.mff.cuni.cz [195.113.20.16]) by sourceware.org (Postfix) with ESMTPS id 938D43858D37 for ; Tue, 9 May 2023 10:22:45 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 938D43858D37 Authentication-Results: sourceware.org; dmarc=fail (p=none dis=none) header.from=ucw.cz Authentication-Results: sourceware.org; spf=none smtp.mailfrom=kam.mff.cuni.cz Received: by nikam.ms.mff.cuni.cz (Postfix, from userid 16202) id 4AAC2284FD9; Tue, 9 May 2023 12:22:43 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ucw.cz; s=gen1; t=1683627763; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=6liAb6NyveXB6LwOykUVufd6PlOdLfuFGHxWj193qK4=; b=GeTSsf9WIJamciU7uYvebd71zDzg1glGboiqa8+VMDVnF9Y2bE8X52lMjIHpgrY0poHxn5 zT3JkQt9V238txe5h3czqjyabso+x12BUuPqWQR8g7kyNbWL/z0sUdm96m3S4fYyqofZOx S5sgRmeTmPdKqUJVyq5/RdzAoCRbopI= Date: Tue, 9 May 2023 12:22:43 +0200 From: Jan Hubicka To: Martin =?iso-8859-2?Q?Li=B9ka?= Cc: Qing Zhao , gcc Patches , Martin Jambor Subject: Re: Question on patch -fprofile-partial-training Message-ID: References: <2A707DB2-5BCE-4F1F-A971-67AC55B30297@oracle.com> <5FEEC8EF-85A8-4A94-ABE0-3E783F0C8A7C@oracle.com> <83fbeb1d-9bf8-1434-d8cb-a9827b1af266@suse.cz> <30e4827a-1a4d-1a26-6158-5e7c967e5268@suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <30e4827a-1a4d-1a26-6158-5e7c967e5268@suse.cz> X-Spam-Status: No, score=-5.2 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,SPF_NONE,TXREP,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: > > > > > > > > From my understanding, -fprofile-partial-training is one important option for PGO performance. > > > > > > I don't think so, speed benefit would be rather small I guess. > > I saw some articles online to introduce this option for gcc10, > > https://documentation.suse.com/sbp/all/html/SBP-GCC-10/index.html#sec-gcc10-pgo > > Hi. > > Ah, I see. > > > And also based on my previous experience in Studio compiler, I guess that this one might have > > Some good performance impact on PGO. Is there any old performance data on this option? (I cannot find online) > > Maybe Honza can chime in here? Or Martin who is the author of the white paper. Main motivation for this was profiling programs that contain specific code paths for different CPUs (such as graphics library in Firefox or Linux kernel). In the situation training machine differs from the machine program is run later, we end up optimizing for size all code paths except ones taken by the specific CPU. This patch essentially tells gcc to consider every non-trained function as built without profile feedback. For Firefox it had important impact on graphics rendering tests back then since the building machined had AVX while the benchmarking did not. Some benchmarks improved several times which is not a surprise if you consider tight graphics rendering loop optimized for size versus vectorized one. The patch has bad effect on code size which in turn impacts performance too, so I think it makes sense to use -fprofile-partial-training with bit of care (i.e. only one code where such scenarios are likely). As for backporting, I do not have checkout of GCC 8 right now. It depends on profile infrastructure that was added in 2017 (so stage1 of GCC 8), so the patch may backport quite easilly. I am not 100% sure what shape the infrastrucure was in the first version, but I am quite convinced it had the necessary bits - it was able to make the difference between 0 profile count and missing profile feedback. Honza > > Martin > > > > > thanks. > > > > Qing > > > > > > > > > I’d like > > > > to see any big technique difficult to prevent it from being back ported to GCC8. > > > > > > There might be of course some patch dependencies and I don't see a point why should we waste > > > time with that. > > > > > > Cheers, > > > Martin > > > > > > > > > > > Thanks. > > > > > > > > Qing > > > > > > > > > > > > > > Martin > > > > > > > > > > > > > > > > > Can this patch be back ported to GCC8 easily? I am wondering any significant > > > > > > Change between GCC8 and GCC10 that might make the backporting very hard> > > > > > > Thanks a lot for your help. > > > > > > > > > > > > Qing > > >