From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Daniel Colascione Newsgroups: gmane.emacs.devel Subject: Re: [Emacs-diffs] trunk r114593: * lisp.h (eassert): Don't use 'assume'. Date: Fri, 11 Oct 2013 00:41:00 -0700 Message-ID: <5257AB8C.40309@dancol.org> References: <52576305.9000703@dancol.org> <52579C68.1040904@cs.ucla.edu> <83iox4pa0w.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1381477277 29329 80.91.229.3 (11 Oct 2013 07:41:17 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 11 Oct 2013 07:41:17 +0000 (UTC) Cc: emacs-devel@gnu.org To: Eli Zaretskii , Paul Eggert Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Oct 11 09:41:20 2013 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 1VUXLc-0000kg-4T for ged-emacs-devel@m.gmane.org; Fri, 11 Oct 2013 09:41:20 +0200 Original-Received: from localhost ([::1]:52883 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VUXLb-00064F-M4 for ged-emacs-devel@m.gmane.org; Fri, 11 Oct 2013 03:41:19 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:50964) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VUXLU-000648-Ih for emacs-devel@gnu.org; Fri, 11 Oct 2013 03:41:18 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VUXLP-0005nM-74 for emacs-devel@gnu.org; Fri, 11 Oct 2013 03:41:12 -0400 Original-Received: from dancol.org ([2600:3c01::f03c:91ff:fedf:adf3]:46937) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VUXLP-0005mt-1D for emacs-devel@gnu.org; Fri, 11 Oct 2013 03:41:07 -0400 Original-Received: from c-69-181-250-160.hsd1.ca.comcast.net ([69.181.250.160] helo=dcolascione-mbp.local) by dancol.org with esmtpsa (TLS1.0:DHE_RSA_CAMELLIA_256_CBC_SHA1:256) (Exim 4.80) (envelope-from ) id 1VUXLN-00017v-VN; Fri, 11 Oct 2013 00:41:06 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.0 In-Reply-To: <83iox4pa0w.fsf@gnu.org> X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2600:3c01::f03c:91ff:fedf:adf3 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:164076 Archived-At: On 10/11/13 12:00 AM, Eli Zaretskii wrote: >> Date: Thu, 10 Oct 2013 23:36:24 -0700 >> From: Paul Eggert >> >> Daniel Colascione wrote: >>> By merging eassert_and_assume with eassert, then removing the assume from eassert, you've essentially removed calls to assume and pessimized the code. >> >> OK, in trunk bzr 114622 I restored eassert_and_assume >> (under the shorter name 'eassume'), but can you measure >> how much performance you're gaining with this change? I don't expect major gains yet, since I haven't fully fleshed out my actual use of the feature. That said, I don't like the code generation that happens without the assume: the compiler has to generate code as if we could be working with negative numbers, but that never happens in reality. >> The eassume macro is tricky to use (as it sometimes makes >> performance worse) so I'd rather omit it if any >> performance gains are insignificant. I'd rather keep it in so it gains more use, especially if we insist on using signed arithmetic everywhere. It doesn't "make performance worse" per se: what it does is evaluate side effects in its argument, and sometimes those side effects are expensive. If used with an argument that's cheap to evaluate --- say, eassume (x < y) --- it should only help performance. > I'm also curious as to why this is needed. Again, 'assume' is an > optimization device, and 'eassert' is not normally compiled in > optimized builds. What are the use cases for this? True, assertions and assume declarations are different, but they're similar in that they both communicate information about constraints. A macro like eassume is useful because, with one line of code, it informs the optimizer about a possible optimization _and_ checks (when checking is on) that what we told the optimizer isn't full of lies. The last bit is important because the consequence of an incorrect assume declaration is incorrect code generation. The side effect problem Dmitry found is the reason I didn't just fold assume into eassert myself. Having a single macro available that assumes and asserts can be useful to avoid duplication when touching new code that wants both kinds of semantics. IIRC from the other thread, Emacs is smaller when we merge the two constructs, so it looks like there are real gains to be had. I think the bulk of assertions can be converted: while it's easy to imagine IT_STRING_CHARPOS turning into a call to some expensive function, it's harder to imagine something like EQ gaining new side effects.