From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: AS31976 209.132.180.0/23 X-Spam-Status: No, score=-4.0 required=3.0 tests=AWL,BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_EF,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,SPF_HELO_PASS,SPF_PASS shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from sourceware.org (server1.sourceware.org [209.132.180.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dcvr.yhbt.net (Postfix) with ESMTPS id 151861F463 for ; Tue, 10 Sep 2019 14:26:50 +0000 (UTC) DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:to:from:subject:message-id:date:mime-version :content-type:content-transfer-encoding; q=dns; s=default; b=UMQ 7+yKbw7x4RZ0onJJTqVekhhOrUUL2Hzz+M4uAExNKgn8uBK9CgziCx03FoaAeUkO lQOL9Boi1AwMHosgKOEaEHW9bhaUXcbEdwCfU7CAv6q+mn3eGGIV14KjXGBU/Jk4 22TgkM33KhtorxjtrlSbI6/ahNA30zvKv9nXjRC4= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:to:from:subject:message-id:date:mime-version :content-type:content-transfer-encoding; s=default; bh=la/UoCdTa CFs81ztEfz/1uHrSVg=; b=V5Qi5fJiJ9R+NBF/oJycrboCqZ/1eOa9AjtGTP4T7 rSdjGj6lufEwAbChX15xSNPSw6Z07FeA+nizFxXksIMOr5S1pY2eFODY+dHBQ8IP PqoFM777esccbgy0zLwudfu9XFWX92cbACcxmYule4QrIGPaYMoApR6HaFe4MYeg kE= Received: (qmail 52110 invoked by alias); 10 Sep 2019 14:26:47 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Received: (qmail 52101 invoked by uid 89); 10 Sep 2019 14:26:47 -0000 Authentication-Results: sourceware.org; auth=none X-HELO: mail-qt1-f171.google.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=to:from:openpgp:autocrypt:subject:message-id:date:user-agent :mime-version:content-language:content-transfer-encoding; bh=gGEuvDd2wcALl3CxCksYXaK2Zim+gOpZ7l5CX+7sC6I=; b=AV25aJ+sjQ7y3AMjvaa1b/SfH2x6oDMpFhUl23s4w3i/m1VHb3SPXAt8KD596KEbwV WHDacv2GjbrE2s9kcouZ26A44e+VevXTcPD4qMNiXwswpIXyMiqkO87vj2e3chzDf1YC DpLpB5xGC3MBH+9+HCWbjyNHQmN5/xNt8nLnD05lkMfP8YJHuANUzzOLtTWTkwskeF18 Cz8BUmKXvP5o0VBNBCEO0lski5mj4KtRzFSH7nEL7k+YQj6w7wJ7fzzSVkFgn4+g78vq 2tVG+y3w8pYGtg3GTeOJ4LkOAn8s6xO6OSvEevs/HrpPjxJdqTjvYLt2gdEM0cKHLdMv VAaA== To: GNU C Library From: Adhemerval Zanella Openpgp: preference=signencrypt Subject: Some clarification about AMD ifunc selection Message-ID: <58572ec0-6d46-b1ec-8225-28268cd51e83@linaro.org> Date: Tue, 10 Sep 2019 11:26:41 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Based on the repercussion this issue has raised in some communities [1] [2], I would like to clarify some misconceptions points that are brought in online discussions. - glibc has moved to a community consensus with arch-maintainers having a strong word regarding architecture specific bits. It does not mean that arch-maintainer have a final word, but that other maintainers usually trust their judgment regarding aspect like ABI issue, performance optimizations, enablement for upcoming features, etc. It also does not prevent any other maintainer, ever for other architectures, to raise questions or even block some arch-specific patch. - Patch review is time-consuming for the arch-specific bits it means the maintainer should be knowledgeable not only about the generic implementation but also about architecture-specific parts. For an extensive review for performance-related patches, it also means the maintainer should have access to arch-specific manuals or actual hardware along with a comprehensible test case to evaluate the performance, which is not possible for most the cases. That's why usually on glibc we rely on the patch submitter to provide such data. - Performance evaluation is hard and glibc benchmark infrastructure still requires improvements. It means it is not straightforward to get the best permutation of optimized string routines for all possible chips without some feedback about how these perform on real hardware (BZ#16830 is an example). It gets even more complex when optimized routines are added without actively being used (BZ#21572). - Most of the x86 optimization work was done by Intel developers and they were the ones driving both discussions about performance and internal code organization. It does not prevent other developers to ask for generic improvement for code organization (for instance the work to move from assembly to C code for ifunc selection) or to ask if the arch-specific implementation would indeed add real-world gains (for instance on the AVX2 strcat/strncat submission). - It also did not prevent other parties to push patches for x86 which are AMD related [3][4][5][6][7][8]. As Florian has expressed BZ#24979 we need more involvement and feedback from AMD for the performance work. Said that I don't see that glibc 'discriminate' Zen or any other AMD platform purposely. It is the fallout of 1. lack maintainer resources from glibc community (both in manpower and infrastructure) and 2. more Intel work than AMD towards some optimization decisions which biased some design decision towards Intel. I can understand that for 2. Intel should also be responsible for AMD performance to some extent and us maintainer should have spotted this possible outcome in code reviewing. So I am open to suggestion on how we can improve it, but my view is we definitely need more engagement from AMD to fully move this forward. [1] https://news.ycombinator.com/item?id=20908957 [2] https://www.realworldtech.com/forum/?threadid=187134&curpostid=187134 [3] https://www.sourceware.org/ml/libc-alpha/2015-12/msg00378.html [4] https://www.sourceware.org/ml/libc-alpha/2016-02/msg00641.html [5] https://www.sourceware.org/ml/libc-alpha/2016-03/msg00441.html [6] https://sourceware.org/bugzilla/show_bug.cgi?id=20195 [7] https://sourceware.org/ml/libc-alpha/2018-07/msg00486.html [8] https://sourceware.org/ml/libc-alpha/2018-12/msg00300.html