From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Dmitry Antipov Newsgroups: gmane.emacs.devel Subject: Re: Benchmarking temporary Lisp objects [Was: Re: [RFC] temporary Lisp_Strings] Date: Wed, 03 Sep 2014 19:39:13 +0400 Message-ID: <54073621.2040403@yandex.ru> References: <5405BE5D.1090003@yandex.ru> <5405DE8B.4050201@yandex.ru> <5406EC21.4060200@yandex.ru> <5407281C.3090302@cs.ucla.edu> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1409758808 9496 80.91.229.3 (3 Sep 2014 15:40:08 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 3 Sep 2014 15:40:08 +0000 (UTC) Cc: Emacs development discussions To: Paul Eggert Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Sep 03 17:40:02 2014 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 1XPCf6-0005N0-IA for ged-emacs-devel@m.gmane.org; Wed, 03 Sep 2014 17:39:56 +0200 Original-Received: from localhost ([::1]:46192 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XPCf5-0004oz-Nt for ged-emacs-devel@m.gmane.org; Wed, 03 Sep 2014 11:39:56 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:59953) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XPCef-0004fa-Rt for emacs-devel@gnu.org; Wed, 03 Sep 2014 11:39:37 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XPCeT-0005WM-S9 for emacs-devel@gnu.org; Wed, 03 Sep 2014 11:39:29 -0400 Original-Received: from forward2l.mail.yandex.net ([2a02:6b8:0:1819::2]:44886) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XPCeT-0005VN-G7 for emacs-devel@gnu.org; Wed, 03 Sep 2014 11:39:17 -0400 Original-Received: from smtp3h.mail.yandex.net (smtp3h.mail.yandex.net [84.201.186.20]) by forward2l.mail.yandex.net (Yandex) with ESMTP id 64DF91AC0D53; Wed, 3 Sep 2014 19:39:14 +0400 (MSK) Original-Received: from smtp3h.mail.yandex.net (localhost [127.0.0.1]) by smtp3h.mail.yandex.net (Yandex) with ESMTP id E22FA1B43348; Wed, 3 Sep 2014 19:39:13 +0400 (MSK) Original-Received: from unknown (unknown [37.139.80.10]) by smtp3h.mail.yandex.net (nwsmtp/Yandex) with ESMTPSA id bsTk9uKSaW-dD7qB7GP; Wed, 3 Sep 2014 19:39:13 +0400 (using TLSv1.2 with cipher AES128-SHA (128/128 bits)) (Client certificate not present) X-Yandex-Uniq: e6c7fd14-4f10-4b90-828e-4bfedd0fb1c2 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1409758753; bh=Vs93GuUfJ+uXCx/aXRXgqT+896UL2XiiSrIvH8hkuR4=; h=Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject: References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=TP5kyzZuLkK0mt45E/QwPmXknfKG7UKzH4peN7Nkeg3EuC5HSpD9/ZcXSSsVQ1aTF n3N19r5uuNFJdVxX9KeEg9mttzduAC2x+rArbfG1MljIk4NI7L8GDZ8B/yLRfeJmOc KP772+8AcYIZkvI5/iViLuzk5pTht0iDIggB7tos= Authentication-Results: smtp3h.mail.yandex.net; dkim=pass header.i=@yandex.ru User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0 In-Reply-To: <5407281C.3090302@cs.ucla.edu> X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2a02:6b8:0:1819::2 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:173983 Archived-At: On 09/03/2014 06:39 PM, Paul Eggert wrote: > 3. It's often better (i.e., faster and/or less memory-intensive) to use a block-scope object, > which is reclaimed on block exit rather than function exit. This suggests that we should have > two forms of cons stack allocation, one block-scope and one function-scope, depending on the > lifetime that the caller wants. For a block-scope cons we can use a C99-style compound literal, > which (unlike alloca) would be safe as an expression. (We're assuming C99 in the trunk now.) OK. So, for the simplest object (cons) we can have: 1) Function-scoped version using alloca (assuming statement expressions): #define alloca_cons(head, tail) \ ({ struct Lisp_Cons *_c = alloca (sizeof *_c); \ eassert (pointer_valid_for_lisp_object (_c)); \ _c->car = (head), _c->u.cdr = (tail); \ make_lisp_ptr (_c, Lisp_Cons); }) 2) Block-scoped version using implicit stack allocation (assuming statement expressions): #define scoped_cons(head, tail) \ ({ struct Lisp_Cons alignas (GCALIGNMENT) _c; \ _c.car = (head), _c.u.cdr = (tail); \ make_lisp_ptr (&_c, Lisp_Cons); }) 3) Block-scoped version assuming no statement expression but compound literals: #define scoped_cons_2(head, tail) \ make_lisp_ptr (&((struct Lisp_Cons) { head, { tail } }), Lisp_Cons) If we have 2), why we need 1) at all? 2) in a top-level function scope is an equivalent to 1), isn't it? In 3), how we can be sure that Lisp_Cons is properly aligned on stack? Dmitry