From owner-freebsd-hackers@FreeBSD.ORG Tue Aug 15 18:58:34 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7716716A4DF for ; Tue, 15 Aug 2006 18:58:34 +0000 (UTC) (envelope-from jasone@FreeBSD.org) Received: from lh.synack.net (lh.synack.net [204.152.188.37]) by mx1.FreeBSD.org (Postfix) with ESMTP id B72BE43D8A for ; Tue, 15 Aug 2006 18:58:20 +0000 (GMT) (envelope-from jasone@FreeBSD.org) Received: by lh.synack.net (Postfix, from userid 100) id 675175E4AC6; Tue, 15 Aug 2006 11:58:20 -0700 (PDT) Received: from [127.0.0.1] (unknown [129.101.159.30]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by lh.synack.net (Postfix) with ESMTP id C8A8B5E4837; Tue, 15 Aug 2006 11:58:18 -0700 (PDT) Message-ID: <44E2194B.5050400@FreeBSD.org> Date: Tue, 15 Aug 2006 11:58:19 -0700 From: Jason Evans User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: =?UTF-8?B?IuadjumRqyBcIihMSSBYaW4pXCIi?= References: <20060814231504.GB69362@lor.one-eyed-alien.net> <20060815023505.N1988@kushnir1.kiev.ua> <1155609256.930.12.camel@spirit> In-Reply-To: <1155609256.930.12.camel@spirit> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Checker-Version: SpamAssassin 3.0.6 (2005-12-07) on lh.synack.net X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=failed version=3.0.6 Cc: freebsd-hackers@freebsd.org, Intron Subject: Re: The optimization of malloc(3): FreeBSD vs GNU libc X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Aug 2006 18:58:34 -0000 李鑫 (LI Xin) wrote: > 在 2006-08-15二的 02:38 +0300，Vladimir Kushnir写道： >> On -CURENT amd64 (Athlon64 3000+, 512k L2 cache): >> >> With jemalloc (without MY_MALLOS): >> ~/fdtd> /usr/bin/time ./fdtd.FreeBSD 500 500 1000 >> ... >> 116.34 real 113.69 user 0.00 sys >> >> With MY_MALLOC: >> ~/fdtd> /usr/bin/time ./fdtd.FreeBSD 500 500 1000 >> ... >> 45.30 real 44.29 user 0.00 sys > > Have you turned off the debugging options, i.e. ln -sf > 'aj' /etc/malloc.conf? If you want to do a fair comparison, you will also define NO_MALLOC_EXTRAS when compiling malloc.c, in order to turn off the copious assertions, not to mention the statistics gathering code. Before you do that though, it would be useful to turn statistics reporting on (add MALLOC_OPTIONS=P to your environment when running the test program) and see what malloc says is going on. [I am away from my -current system at the moment, so can't benchmark the program.] If I understand the code correctly (and assuming the command line parameters specified), it starts out by requesting 3517 2000-byte allocations from malloc, and never frees any of those allocations. Both phkmalloc and jemalloc will fit two allocations in each page of memory. phkmalloc will call sbrk() at least 1759 times. jemalloc will call sbrk() approximately 6 times. 2kB allocations are a worst case for some of jemalloc's internal bookkeeping, but this shouldn't be a serious problem. Fragmentation for these 2000-byte allocations should total approximately 6%. malloc certainly incurs more overhead than a specialized sbrk()-based allocator, but I don't see any particular reason that jemalloc should perform suboptimally, as compared to any complete malloc implementation, for fdtd. If you find otherwise, please tell me so that I can look into the issue. Thanks, Jason