From: Daniel Colascione <dancol@dancol.org>
To: Eli Zaretskii <eliz@gnu.org>, Paul Eggert <eggert@cs.ucla.edu>
Cc: emacs-devel@gnu.org
Subject: Re: [Emacs-diffs] trunk r114593: * lisp.h (eassert): Don't use 'assume'.
Date: Fri, 11 Oct 2013 00:41:00 -0700 [thread overview]
Message-ID: <5257AB8C.40309@dancol.org> (raw)
In-Reply-To: <83iox4pa0w.fsf@gnu.org>
On 10/11/13 12:00 AM, Eli Zaretskii wrote:
>> Date: Thu, 10 Oct 2013 23:36:24 -0700
>> From: Paul Eggert <eggert@cs.ucla.edu>
>>
>> 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.
next prev parent reply other threads:[~2013-10-11 7:41 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <E1VTxwB-0001h8-7E@vcs.savannah.gnu.org>
2013-10-11 2:31 ` [Emacs-diffs] trunk r114593: * lisp.h (eassert): Don't use 'assume' Daniel Colascione
2013-10-11 6:36 ` Paul Eggert
2013-10-11 7:00 ` Eli Zaretskii
2013-10-11 7:41 ` Daniel Colascione [this message]
2013-10-11 8:08 ` Eli Zaretskii
2013-10-11 8:19 ` Daniel Colascione
2013-10-11 8:59 ` Stephen J. Turnbull
2013-10-11 9:10 ` Daniel Colascione
2013-10-11 10:27 ` Stephen J. Turnbull
2013-10-11 12:42 ` Stefan Monnier
2013-10-11 15:24 ` Stephen J. Turnbull
2013-10-11 9:06 ` Eli Zaretskii
2013-10-11 9:18 ` Daniel Colascione
2013-10-11 9:36 ` Eli Zaretskii
2013-10-11 9:55 ` Daniel Colascione
2013-10-11 10:31 ` Dmitry Antipov
2013-10-11 15:22 ` Paul Eggert
2013-10-11 15:41 ` Daniel Colascione
2013-10-12 7:37 ` Paul Eggert
2013-10-11 11:19 ` Eli Zaretskii
2013-10-11 15:57 ` Daniel Colascione
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5257AB8C.40309@dancol.org \
--to=dancol@dancol.org \
--cc=eggert@cs.ucla.edu \
--cc=eliz@gnu.org \
--cc=emacs-devel@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.