From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Florian Weimer Newsgroups: gmane.comp.lib.glibc.alpha Subject: Re: [PATCH v2] Add malloc micro benchmark Date: Wed, 28 Feb 2018 15:16:09 +0100 Message-ID: <808ed1e2-5945-0712-87a5-a0408de55fb0@redhat.com> 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> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Trace: blaine.gmane.org 1519827256 30477 195.159.176.226 (28 Feb 2018 14:14:16 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 28 Feb 2018 14:14:16 +0000 (UTC) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 Cc: Carlos O'Donell , Joseph Myers , Wilco Dijkstra , "libc-alpha@sourceware.org" , nd To: =?UTF-8?B?T25kxZllaiBCw61sa2E=?= Original-X-From: libc-alpha-return-90680-glibc-alpha=m.gmane.org@sourceware.org Wed Feb 28 15:14:11 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=X9Hfqr2Oevy8/tWN mlqVBwzhjPFtXeFydiuDl6rPFW4IHaGRfjjsUkUHyPqGrCEwW7gFyVpI1nIqRQrw NDO1DoRBbNyO+kkKpIWS5d/NUm86ZS7FCoC38C5gnJV+WgqXvv5MGSkTYgdMshqN KICrfKn3bx8RQDlY+2J5bB+T2W4= 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=3IEYcCbFJQdvI6xR2Ii0ve xOO0k=; b=IyuCTYKFHrspg4L7egvqPp9WaN2bICnArKE0W98kk/JSj48+KV5KBg URob/rTtIiXDicsjQln3zxQZNFMkBnFANUB4Mld9MWQyb/+YQtuGezVCyhdh856O SVKRkOGJZUPNiFerNzpV/TWNQeEqaLbLppBefASYQ+vYO7O2EsBAk= 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=-2.1 required=5.0 tests=AWL,BAYES_00,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 spammy=comparable, HContent-Transfer-Encoding:8bit X-HELO: mx1.redhat.com In-Reply-To: <20180228141126.GA13073@domone> Xref: news.gmane.org gmane.comp.lib.glibc.alpha:83011 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 1er2Ul-0007Lu-IW for glibc-alpha@blaine.gmane.org; Wed, 28 Feb 2018 15:14:11 +0100 Received: (qmail 86306 invoked by alias); 28 Feb 2018 14:16:14 -0000 Received: (qmail 86284 invoked by uid 89); 28 Feb 2018 14:16:14 -0000 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. Of course, there are workloads where it loses big, but those exist for other allocators, too. People simple don't write blog posts comparing *alloc with glibc malloc if glibc malloc provides comparable or better performance because it's quite boring. 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? Thanks, Florian