unofficial mirror of guile-devel@gnu.org 
 help / color / mirror / Atom feed
From: Daniel Kraft <d@domob.eu>
To: Andy Wingo <wingo@pobox.com>
Cc: "Ludovic Courtès" <ludo@gnu.org>, guile-devel@gnu.org
Subject: Re: Emacs Lisp, macros
Date: Fri, 24 Jul 2009 09:00:26 +0200	[thread overview]
Message-ID: <4A695C0A.6060708@domob.eu> (raw)
In-Reply-To: <m3bpnbf3nr.fsf@pobox.com>

Andy Wingo wrote:
>> 1) As you suggested, try doing some parts of this with new VM
>> operations.  Like all of these in one op, or maybe just a "reference and
>> error on void" as one op, and/or "lookup the variable in some module,
>> and create it if not there" as another.  I think we need some planning
>> to get the right choice, but it certainly is an important thing for
>> performance.  But for now I'd suggest to keep on with the current
>> implementation and later see what the real performance bottle-neck is
>> when running real-world code.
> 
> So, agreed wrt perspective on when to optimize. I still think that we
> should be able to cache fluid locations in the same way that Scheme
> caches variable locations, and add dynamic-ref / dynamic-set analogs to
> toplevel-ref / toplevel-set. See their implementations for details on
> what I mean.

You mean, (dynamic-ref fluid) equvialent to (fluid-ref fluid) but just 
VM optimized, and the same for dynamic-set!?  Sounds nice!

Well, just some notes about variable references and performance;  there 
are still those three things that have to be done I mentioned already 
some time before (for setting a variable, 1) and 2) will be relevant):

1) Make sure the fluid itself is there for each variable needed and 
create a new one if not.

I did this once on every access, but now I'm scanning each compiled 
expression for variable references and ensure all fluids for them 
beforehand, so that this is only done once per compiled expression and 
not, say, on each iteration in a loop.  This brought runtime for one 
test down from 2.8s to 0.1s...  This pretty amazed me, and I think the 
current solution is quite ok.

2) Reference the fluid.

This is what we could do with VM operations, but I've not yet done tests 
to find out how much time this really costs compared to 3).

3) Check if value is void and error if it is.

Maybe we could also do this in a VM operation (and then it would 
probably cost nearly nothing at all?), but I think that maybe just 
optionally getting rid of this test at all (see my remark about compiler 
options) is the better solution.

When I've implemented the options to disable 2) and/or 3), I'll do some 
timings and let you know about that.  Then we can decide if VM ops for 
the fluids are worth it and how much we can gain by them.

Daniel

-- 
Done:  Arc-Bar-Cav-Ran-Rog-Sam-Tou-Val-Wiz
To go: Hea-Kni-Mon-Pri




  reply	other threads:[~2009-07-24  7:00 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-07-14 19:48 Emacs Lisp, macros Daniel Kraft
2009-07-14 22:15 ` Ludovic Courtès
2009-07-15  8:36   ` Daniel Kraft
2009-07-23 22:14     ` Andy Wingo
2009-07-24  7:00       ` Daniel Kraft [this message]
2009-07-23 22:09 ` Andy Wingo

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=4A695C0A.6060708@domob.eu \
    --to=d@domob.eu \
    --cc=guile-devel@gnu.org \
    --cc=ludo@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).