From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: =?utf-8?B?T25kxZllaiBCw61sa2E=?= Newsgroups: gmane.comp.lib.glibc.alpha Subject: Re: [PATCH v2] Add malloc micro benchmark Date: Wed, 28 Feb 2018 17:46:21 +0100 Message-ID: <20180228164621.GA10445@domone> References: <6ad98d83-d49b-25a3-ef01-e93e18f4740b@redhat.com> <96b76d58-d2f0-2176-51e5-f6338ed079e1@redhat.com> <165192eb-d815-867f-e1ba-0f9972eb19cd@redhat.com> <20180228141126.GA13073@domone> <808ed1e2-5945-0712-87a5-a0408de55fb0@redhat.com> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Trace: blaine.gmane.org 1519836273 20611 195.159.176.226 (28 Feb 2018 16:44:33 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 28 Feb 2018 16:44:33 +0000 (UTC) User-Agent: Mutt/1.5.20 (2009-06-14) Cc: Carlos O'Donell , Joseph Myers , Wilco Dijkstra , "libc-alpha@sourceware.org" , nd To: Florian Weimer Original-X-From: libc-alpha-return-90684-glibc-alpha=m.gmane.org@sourceware.org Wed Feb 28 17:44:28 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:date:from:to:cc:subject:message-id:references :mime-version:content-type:content-transfer-encoding :in-reply-to; q=dns; s=default; b=k1FjmY8+zj+9JQ0xlz3cgnmtxvurwg iM6TPRbk0ZpY1/cYP3c0dda5xuUz0YkZJYkgjkns/nB8A0Be73sUZjoQtXpPv4us 4gWHQxXGmJxoNmGLiOhRqAkG26W+l9+LHa+4g/32OGuAzw912AWxMWBgEtdfQVZI 7r+29+yONFAmI= 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:date:from:to:cc:subject:message-id:references :mime-version:content-type:content-transfer-encoding :in-reply-to; s=default; bh=H4uO2kQ1cjxZfzoASCFG9BfAB9c=; b=rj92 d5ttY9HHo4HPAeP/0GYERstvryl5Pu0HTWoR6UNBkby4bev2NhA3D0L1TeuR7+Ni 7Qzv0JaxNOGQy8mPBS+TBCa88KU3tFD5HMqo/rSftVNDliikVglQQKBIUn+KF8+0 XpDiTCRxukojXmqzkyVlHP2eMBkABZbCkDx4KXY= 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.1 required=5.0 tests=BAYES_00,FREEMAIL_FROM,SPF_NEUTRAL autolearn=no version=3.3.2 spammy=H*F:D*seznam.cz, HContent-Transfer-Encoding:8bit X-HELO: popelka.ms.mff.cuni.cz Content-Disposition: inline In-Reply-To: <808ed1e2-5945-0712-87a5-a0408de55fb0@redhat.com> Xref: news.gmane.org gmane.comp.lib.glibc.alpha:83015 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 1er4qB-0004tD-7Q for glibc-alpha@blaine.gmane.org; Wed, 28 Feb 2018 17:44:27 +0100 Received: (qmail 14294 invoked by alias); 28 Feb 2018 16:46:30 -0000 Received: (qmail 14282 invoked by uid 89); 28 Feb 2018 16:46:29 -0000 On Wed, Feb 28, 2018 at 03:16:09PM +0100, Florian Weimer wrote: > On 02/28/2018 03:11 PM, Ondřej Bílka wrote: > >Thats rather ineffective, it is easier to start fresh than try to > >maintain rather obsolete allocator. Most of other are faster and more > >space effective because of their layout. > > That's not quite true. Despite its limitations, glibc malloc still > compares remarkably well to other allocators. That confuses cause and effect. People spent lot of effort to fix workloads where this allocator is bad (usually starts with saying that malloc is slow) with trick like static buffers, merging allocations, memory pools etc. With better allocator it wouldn't be neccessary as it would handle simpler code with same performance. > > I think a heap-style allocator which does not segregate allocations > of different sizes still has its place, and why not provide one in > glibc? > That isn't case for any allocator and it is asking for trouble. You want to avoid sitation where two big chunks couldn't be merged because of tiny chunk between them. Also you will likely spend more space on header overhead than could you save. For small sizes merging chunks doesn't happen so we lose nothing by requiring uniform capacity. For larger size this representation is still problematic and you could improve performance with another representation that also avoids alignment problem by placing metadata elsewhere(for mine only 4 bytes are needed).