From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Ken Raeburn Newsgroups: gmane.emacs.devel Subject: Re: Proposal: block-based vector allocator Date: Tue, 22 May 2012 01:23:30 -0400 Message-ID: <31DDD6A8-9483-493B-B4F0-52F47B44ED55@raeburn.org> References: <4EDDA68B.5050601@yandex.ru> <4FB4AFA4.7020601@yandex.ru> <4FBA32D9.5090704@yandex.ru> <4FBA47A0.4050103@yandex.ru> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Trace: dough.gmane.org 1337664222 17346 80.91.229.3 (22 May 2012 05:23:42 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Tue, 22 May 2012 05:23:42 +0000 (UTC) To: Emacs Dev Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue May 22 07:23:41 2012 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1SWhZM-0005JV-GS for ged-emacs-devel@m.gmane.org; Tue, 22 May 2012 07:23:40 +0200 Original-Received: from localhost ([::1]:58077 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SWhZM-0001T9-0t for ged-emacs-devel@m.gmane.org; Tue, 22 May 2012 01:23:40 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:35655) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SWhZI-0001T4-Bx for emacs-devel@gnu.org; Tue, 22 May 2012 01:23:37 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SWhZG-0002es-Mh for emacs-devel@gnu.org; Tue, 22 May 2012 01:23:35 -0400 Original-Received: from mail-qa0-f41.google.com ([209.85.216.41]:57797) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SWhZG-0002eg-IQ for emacs-devel@gnu.org; Tue, 22 May 2012 01:23:34 -0400 Original-Received: by qabg27 with SMTP id g27so2385043qab.0 for ; Mon, 21 May 2012 22:23:32 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=SSQSO3xqAjGJAm1edpKTA9wZpMhjyJblFzeEEqGyBKE=; b=k+sQabPav0/2DEjizwMgFoit/yHBLfVR56kJ/c9AQFywI5fks2hskj/w27AuPWvm0L hZ7rGbAdyRwZkn6LMvyQ+Y+wbhyU4NBcAy/OoKz2i+YEWjJ5PgZKUaN3AgBjeEjGty6n C56nDnQH8R4AGjqKstKT9MO+wlabthZogcN7ZZWRZHTqpMAr2X7DmWaJ3VkuD8ot6j20 Nl4N6YNPSKYqwE3gb2GGaQjvJY23qIK/l0I9rTGDaw21SDc5P1ak3edFtr2hlYT1QYXE SV85lXnxMUJszI0KS3BAaDL017vDwPPglUgrOMnGIz7ia34kJy08o8uJa1ZF40oN+O9u OQxg== Original-Received: by 10.224.78.208 with SMTP id m16mr42420925qak.62.1337664212564; Mon, 21 May 2012 22:23:32 -0700 (PDT) Original-Received: from squish.raeburn.org (c-66-31-202-94.hsd1.ma.comcast.net. [66.31.202.94]) by mx.google.com with ESMTPS id hv18sm43479248qab.19.2012.05.21.22.23.31 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 21 May 2012 22:23:32 -0700 (PDT) In-Reply-To: <4FBA47A0.4050103@yandex.ru> X-Mailer: Apple Mail (2.1257) X-Gm-Message-State: ALoCoQlXoYRN9iEYbR4Q03OCpQLv3nFMDJtpOVPzLotQzdwEHGriMaoceLrkGlWWAkuC3W7dD85z X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 209.85.216.41 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:150595 Archived-At: On May 21, 2012, at 09:48, Dmitry Antipov wrote: > On 05/21/2012 05:02 PM, Andreas Schwab wrote: >=20 >> It doesn't make much sense to try to find such a trivial but non-std >> macro in a system header. >=20 > Hm, glibc provides some not-so-trivial bits (assuming gcc): >=20 > # define roundup(x, y) (__builtin_constant_p (y) && powerof2 (y) = \ > ? (((x) + (y) - 1) & ~((y) - 1)) = \ > : ((((x) + ((y) - 1)) / (y)) * (y))) >=20 > It seems to be a very negligible optimization, but why not use it if = available? Because a good compiler should be able to make that optimization itself = if you use the simple, straightforward version? (You might have to use = an unsigned type for x.) My Mac's compiler does. I get the impression = glibc has a lot of optimizations targeted at older versions of gcc. You need to supply the fallback version anyways, so just use the version = optimized for human readability and maintenance, instead of jumping = through hoops to dig through multiple system headers for a trivial = arithmetic macro to maybe save a few microseconds on a system with = outdated software. Ken=