From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Carlos O'Donell Newsgroups: gmane.comp.lib.glibc.alpha Subject: Re: [PATCH v2] Add malloc micro benchmark Date: Fri, 5 Jan 2018 09:26:30 -0800 Message-ID: References: <6ad98d83-d49b-25a3-ef01-e93e18f4740b@redhat.com> <96b76d58-d2f0-2176-51e5-f6338ed079e1@redhat.com> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Trace: blaine.gmane.org 1515173085 29761 195.159.176.226 (5 Jan 2018 17:24:45 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 5 Jan 2018 17:24:45 +0000 (UTC) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 Cc: Wilco Dijkstra , "libc-alpha@sourceware.org" , nd , Florian Weimer To: Joseph Myers Original-X-From: libc-alpha-return-88876-glibc-alpha=m.gmane.org@sourceware.org Fri Jan 05 18:24:41 2018 Return-path: Envelope-to: glibc-alpha@blaine.gmane.org DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:subject:to:cc:references:from:message-id:date :mime-version:in-reply-to:content-type :content-transfer-encoding; q=dns; s=default; b=YxyYWoO2hwsxfJwY bTbL7z6jB9FigbIWKuykTcwmfL7LAKgelK8GU1O7XSdVfgrVKFulxtGQcvZ9H4iz ZlldsfclKGBkH4MWPmqToFlsYJRzXbvkz2Q0UnntVo+fv1q572GPFEJOJp1znyQX bL0Jrgoc1ARRx62XnvyxiaHrC90= 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:subject:to:cc:references:from:message-id:date :mime-version:in-reply-to:content-type :content-transfer-encoding; s=default; bh=cMNtgnDrOZwMrSZT1AHfFi sZwOQ=; b=Kx25R+fOplLPlA0hEc4iqiMgrjfwMnrMsCcTbv6Mi2Xqa+kIobwq+G l3RV9QR794gKtiqCI1TCZ3kDXH+8Or1iJ7Cy2qiEiERXa8ViGzywEjyqfnwLDNyw pcPIM0161zmamCGnjyUunqiNNvNiGmJWp8TxQYG18yQIs1R/RAA/g= 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: , Original-Sender: libc-alpha-owner@sourceware.org Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.2 spammy=Hx-languages-length:2107 X-HELO: mail-qt0-f180.google.com X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=FyN3HoiTNuZfOM+SKUviNqOfZNYuHEO2bqLs0jjyZv8=; b=Dl+40teNPbhxcgVFnCAUk1iD1GaUQtndF5xHU9p/nOH2DwhiOIgfV1HptdPyKd6584 0I74x1DHfHZtjo0vvOGZWu7BKH6GegnLtLrFWEFOgVocKQnYcOyGSYyl0VSpNhOhyczm 8gqJShhHwYH0o2b/l+Hy/3vvWNgfWe9ENNVbHAsjnamdV0828nE7sz6TXpun2hXu9HbY OjOTnfqlDT99JCAJu2JiLd+u0XBvEFTNFUyFtrahTqBUGhnZheDqcYuHbpQaqcfM4xBB FmCTJ9mg2vv3irpsMI/KAj8Qfp8IGoNWOY6wcmKlLgU8Rh4eCjbXttMbAOJiOHqze0w3 NQAw== X-Gm-Message-State: AKwxytesqscsiuz7hj2LwR58IMgXpOPoqCT67L1dFWbffERCFVtWxKDm OGs0ZcprqlGpKRlm5YyrSrxaNw== X-Google-Smtp-Source: ACJfBov4Za4moBvQTEWvH9h3hlOK1wSVbJTi5wHBM+0WLY5WVmsidz+w5pFUgXS0xZj/p9j60qu0rw== X-Received: by 10.237.56.226 with SMTP id k89mr4938699qte.1.1515173194028; Fri, 05 Jan 2018 09:26:34 -0800 (PST) In-Reply-To: Xref: news.gmane.org gmane.comp.lib.glibc.alpha:81239 Archived-At: Received: from server1.sourceware.org ([209.132.180.131] helo=sourceware.org) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eXVjR-0007Fb-DN for glibc-alpha@blaine.gmane.org; Fri, 05 Jan 2018 18:24:37 +0100 Received: (qmail 61561 invoked by alias); 5 Jan 2018 17:26:37 -0000 Received: (qmail 61544 invoked by uid 89); 5 Jan 2018 17:26:37 -0000 On 01/05/2018 08:28 AM, Joseph Myers wrote: > On Fri, 5 Jan 2018, Carlos O'Donell wrote: > >> I think that for blocks smaller than the fundamental language types >> (which require malloc to have 16-byte alignment) we do not have to >> return sufficiently aligned memory. For example if you allocate a 3-byte >> block or a 13-byte block, you cannot possibly put a 16-byte long double >> there, nor can you use that for a stack block, so it's a waste to >> guarantee alignment. > > As per DR#075, the memory needs to be aligned for any type of object (with > a fundamental alignment requirement, in C11 and later), not just those > that will fit in the block. (This in turn allows for applications using > low bits for tagged pointers.) Thanks for the reference to DR#075, I had not considered the cast equality issue. > This does not of course rule out having another allocation API that > supports smaller alignment requirements. Agreed. It would still be a win if we did not have co-located metadata (something Florian whispered into my ear years ago now) for small constant sized blocks. We would go from this: N * 1-byte allocations => N * (32-byte header + 1-byte allocation + 15-bytes alignment) [97% constant waste] To this: N * 1-byte allocations => N * (1-byte allocation + 15-bytes alignment) + (N/8)-bytes in-use-bit + 16-bytes header [96% waste for 1-byte] [94% waste for 100*1-byte] ... towards a 93.75% constant waste (limit of the alignment e.g. 15/16) This is a gain of 5% RSS efficiency for a structural change. For a 13-byte allocation: N * 1-byte allocations => N * (32-byte header + 13-byte allocation + 3-bytes alignment) [73% constant waste] To this: N * 1-byte allocations => N * (13-byte allocation + 3-bytes alignment) + (N/8)-bytes in-use-bit + 16-bytes header [60% waste for 13-bytes] [20% waste for 100*13-bytes] [19% waste for 1000*13-bytes] ... towards a 18.75% constant waste (limit of the alignment e.g. 3/16) Note: We never reach the constant limit because the in-use bit-array still grows quickly. -- Cheers, Carlos.