From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Paul Eggert Newsgroups: gmane.emacs.devel Subject: Re: Benchmarking temporary Lisp objects [Was: Re: [RFC] temporary Lisp_Strings] Date: Wed, 03 Sep 2014 07:39:24 -0700 Organization: UCLA Computer Science Department Message-ID: <5407281C.3090302@cs.ucla.edu> References: <5405BE5D.1090003@yandex.ru> <5405DE8B.4050201@yandex.ru> <5406EC21.4060200@yandex.ru> 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 1409755218 24591 80.91.229.3 (3 Sep 2014 14:40:18 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 3 Sep 2014 14:40:18 +0000 (UTC) To: Dmitry Antipov , Emacs development discussions Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Sep 03 16:40:08 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 1XPBjE-0006jn-Cz for ged-emacs-devel@m.gmane.org; Wed, 03 Sep 2014 16:40:08 +0200 Original-Received: from localhost ([::1]:45994 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XPBjD-0006HB-Qm for ged-emacs-devel@m.gmane.org; Wed, 03 Sep 2014 10:40:07 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:45402) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XPBj4-0006Ey-AQ for emacs-devel@gnu.org; Wed, 03 Sep 2014 10:40:05 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XPBiw-0007pj-Qq for emacs-devel@gnu.org; Wed, 03 Sep 2014 10:39:58 -0400 Original-Received: from smtp.cs.ucla.edu ([131.179.128.62]:38538) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XPBiw-0007YC-JG for emacs-devel@gnu.org; Wed, 03 Sep 2014 10:39:50 -0400 Original-Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp.cs.ucla.edu (Postfix) with ESMTP id CE95839E801A; Wed, 3 Sep 2014 07:39:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at smtp.cs.ucla.edu Original-Received: from smtp.cs.ucla.edu ([127.0.0.1]) by localhost (smtp.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z4dPNFJHGI94; Wed, 3 Sep 2014 07:39:33 -0700 (PDT) Original-Received: from [192.168.1.9] (pool-71-177-17-123.lsanca.dsl-w.verizon.net [71.177.17.123]) by smtp.cs.ucla.edu (Postfix) with ESMTPSA id 118D639E8017; Wed, 3 Sep 2014 07:39:33 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0 In-Reply-To: <5406EC21.4060200@yandex.ru> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 131.179.128.62 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:173981 Archived-At: Dmitry Antipov wrote: > 1) Should alloca_vector fallback to Fmake_vector for large vectors? Of course. It should be like SAFE_NALLOCA. > 2) Is there a way to rewrite alloca_xxx macros to avoid statement > expressions? IIUC this is not portable beyond gcc and compilers > that mimics it (clang, Intel's icc). Some thoughts: 1. It's OK to use statement expressions on compilers that support them, and fall back on slower technology on those that don't. 2. That being said, the GNU alloca documentation says "Do not use 'alloca' inside the arguments of a function call", i.e., that code must not do foo (alloca (n)), but instead must do (p = alloca (n), foo (p)). So it's not clear that trying to do these macros as expressions will work. 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.) For a block-scope vector, if __STDC_NO_VLA__ is not defined we can declare a variable-length array, otherwise we can fall back on alloca and/or malloc. 4. Looking through the Emacs code now, I see that it's not disciplined about using SAFE_ALLOCA/SAFE_NALLOCA/etc. for unbounded arrays on the stack. I'll look into cleaning this up.