unofficial mirror of bug-guile@gnu.org 
 help / color / mirror / Atom feed
From: David Kastrup <dak@gnu.org>
To: Andy Wingo <wingo@pobox.com>
Cc: 17049@debbugs.gnu.org
Subject: bug#17049: [PATCH] Make reverse! forego the cost of SCM_VALIDATE_LIST
Date: Thu, 20 Mar 2014 22:27:28 +0100	[thread overview]
Message-ID: <8738icef27.fsf@fencepost.gnu.org> (raw)
In-Reply-To: <87bnx0y4qk.fsf@pobox.com> (Andy Wingo's message of "Thu, 20 Mar 2014 21:50:11 +0100")

Andy Wingo <wingo@pobox.com> writes:

> Thanks for the patch.  What is its performance impact for your use
> case?

Use case is a bit hard to benchmark from scratch as it's basically
consing a list together and then reversing it.  Of course, in a fresh
session the consing is dominating the run time, while in a real-life
session cons cells are usually available from a free list.

Of course, one can just call scm_reverse_x in a loop without any consing
at all, but that's probably a bit too much of a best use case.  I could
do this in order to give an upper limit to what improvement may be
expected.

In that case, if we are talking about large lists, I'd expect a factor
of about 7:4 since the reversal takes 2 read-modify-writes per 2
elements, and tortoise and hare take 1 and 2 read cycles per 2 elements.
The loops should be tight enough to fit into registers and executing
cache, so those memory accesses should by far dominate the timing. And
with a large list, all of those data accesses need to get their cache
line at a different time.

> On Thu 20 Mar 2014 12:23, David Kastrup <dak@gnu.org> writes:
>
>> +  /* We did not start with a proper list.  Undo the reversal. */
>
> I'm hesitant.  This is visible to other threads.  (Granted there has to
> be significant wrongness if we get here...)

Uh, what of it?  The other threads have to deal with the reversal in the
non-error case, and it does not have well-defined multithread semantics.
So what you are saying is that you want to have multithread-safe
semantics for the error case exclusively if I understand correctly.

But the tortoise-hare algorithm used in SCM_VALIDATE_LIST is not
multithread-robust either as far as I can see.

At any rate, this additional reversal only happens in the error case.
Tortoise-hare is read-only, so it will be quite faster than a double
reversal (which dirties the cache of the chain twice, and if we are
talking about a circular list, the cache of the non-circular part even
four times).  So if we want to have an efficient error behavior, this
change is not going to be an improvement.

It seems pointless to add an extra unvalidated reversal when it would be
just as fast as _this_ validated reversal.

-- 
David Kastrup





  reply	other threads:[~2014-03-20 21:27 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-03-20 11:23 bug#17049: [PATCH] Make reverse! forego the cost of SCM_VALIDATE_LIST David Kastrup
2014-03-20 11:38 ` bug#17049: PostScriptum: David Kastrup
2014-03-20 14:19 ` bug#17049: [PATCH] Make reverse! forego the cost of SCM_VALIDATE_LIST David Kastrup
2014-03-20 20:50 ` Andy Wingo
2014-03-20 21:27   ` David Kastrup [this message]
2014-03-21  4:38   ` Mark H Weaver
2014-03-21 16:56     ` David Kastrup
2014-03-31 19:56       ` Mark H Weaver
2014-04-01 10:26         ` bug#17049: [PATCH v2] " David Kastrup
2014-04-01 10:40           ` David Kastrup
2014-04-01 14:09             ` Mark H Weaver
2014-04-01 14:24               ` bug#17049: [PATCH v3] " David Kastrup
2014-04-01 16:35                 ` Mark H Weaver
2014-03-21 17:44   ` bug#17049: [PATCH] " David Kastrup
2014-03-30 16:36 ` bug#17049: Further change ideas David Kastrup

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

  List information: https://www.gnu.org/software/guile/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=8738icef27.fsf@fencepost.gnu.org \
    --to=dak@gnu.org \
    --cc=17049@debbugs.gnu.org \
    --cc=wingo@pobox.com \
    /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.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).