From owner-freebsd-hackers@FreeBSD.ORG Thu Jun 14 22:14:11 2007 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6096416A468 for ; Thu, 14 Jun 2007 22:14:11 +0000 (UTC) (envelope-from freebsd-hackers@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.freebsd.org (Postfix) with ESMTP id DC08613C487 for ; Thu, 14 Jun 2007 22:14:10 +0000 (UTC) (envelope-from freebsd-hackers@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1HyxZU-0007fj-SC for freebsd-hackers@freebsd.org; Fri, 15 Jun 2007 00:13:41 +0200 Received: from 89-172-58-72.adsl.net.t-com.hr ([89.172.58.72]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 15 Jun 2007 00:13:40 +0200 Received: from ivoras by 89-172-58-72.adsl.net.t-com.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 15 Jun 2007 00:13:40 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-hackers@freebsd.org From: Ivan Voras Date: Fri, 15 Jun 2007 00:12:15 +0200 Lines: 70 Message-ID: References: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig0B4229BF4F16084D61EAAD3A" X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: 89-172-58-72.adsl.net.t-com.hr User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) In-Reply-To: X-Enigmail-Version: 0.94.3.0 Sender: news Subject: Re: Reason for doing malloc / bzero over calloc (performance)? 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: Thu, 14 Jun 2007 22:14:11 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig0B4229BF4F16084D61EAAD3A Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable youshi10@u.washington.edu wrote: > Do you know if that's with malloc or calloc? What portion of the source= > demonstrates this? No source, but here's a quote from http://boredzo.org/blog/archives/2006-11-26/calloc-vs-malloc: For large blocks (where "large" is surprisingly small, something like 14 KB) Mac OS X's default malloc() will always go to the kernel for memory by calling vm_allocate(). vm_allocate() always returns zero-filled pages; otherwise, you might get back a chunk of physical RAM or swap space that had been written to by some root process, and you'd get privileged data. So for large blocks, we'd expect calloc() and malloc() to perform identically. Mach will reserve some memory but not physically allocate it until you read or write it. The pages can also be marked zero filled without having to write zeros to RAM. But the first time you read from the page, it has to allocate and then zero-fill it. Google lead me to this: http://developer.apple.com/documentation/Performance/Conceptual/ManagingM= emory/Articles/MemoryAlloc.html It's not conclusive: For allocations greater than a few virtual memory pages, malloc uses the vm_allocate routine to obtain a block of the requested size.The vm_allocate routine assigns an address range to the new block in the virtual memory space of the current process but does not allocate any physical memory. Instead, the malloc routine pages in the memory for the allocated block as it is used. The granularity of large memory blocks is 4096 bytes, the size of a virtual memory page. If you are allocating a large memory buffer, you should consider making it a multiple of this size. Note: Large memory allocations are guaranteed to be page-aligned. but: The calloc routine reserves the required virtual address space for the memory but waits until the memory is actually used before initializing it. This approach alleviates the need to map the pages into memory right away. It also lets the system initialize pages as they=E2=80=99re used, a= s opposed to all at once. --------------enig0B4229BF4F16084D61EAAD3A Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.4 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGcb1FldnAQVacBcgRAu8rAKCdVT4GhEK/il596F8qTt9t2wWGzACgi+cw IEr4q4KFdO3zC4dRIfCFmng= =spKr -----END PGP SIGNATURE----- --------------enig0B4229BF4F16084D61EAAD3A--