From: Dirk Herrmann <dirk@sallust.ida.ing.tu-bs.de>
Cc: guile-devel@gnu.org, guile-user@gnu.org
Subject: Re: status: separation of expansion/optimization/memoization/execution
Date: Wed, 14 Aug 2002 21:30:56 +0200 (CEST) [thread overview]
Message-ID: <Pine.GSO.4.05.10208142109010.6796-100000@sallust.ida.ing.tu-bs.de> (raw)
In-Reply-To: <87lm7e7tqc.fsf@zagadka.ping.de>
On 10 Aug 2002, Marius Vollmer wrote:
> So, cleaning up the existing lazy memoizer is a very good thing
> indeed. But I'd say you should also make sure that you don't
> significantly lose performance by doing it. That part of Guile will
> be performance-critical for quite some time.
At the current state I can't decide yet, whether after the changes guile's
speed will at all differ from before. Too many optimizations of the
scheme code are not possible yet, until the separation is complete. If
there is a performance problem then, it will be easier to optimize the
evaluator then. There are, however, a lot of open questions:
* in principle, memoization could memoize all variable references. That
would mean, the execution could be freed of all checks for symbols and
variable lookups - this would have been done by the memoizer.
Benefits:
- no symbol lookups in the executor
- quoted symbols could be made into symbols, getting rid of one level of
quoting
Problems:
- how to deal with undefined symbols?
- should 'undefine' still be possible, and if so, how?
* should the executor ever run over an undefined symbol? This could be
checked during expansion and memoization. If it is known that during
exection all symbols are defined, this eliminates one test during
variable lookup.
Best regards,
Dirk
_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel
next prev parent reply other threads:[~2002-08-14 19:30 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-08-02 22:42 status: separation of expansion/optimization/memoization/execution Dirk Herrmann
2002-08-02 23:15 ` Rob Browning
2002-08-02 23:47 ` Han-Wen
2002-08-02 23:20 ` Dale P. Smith
2002-08-03 12:12 ` Han-Wen
2002-08-04 1:51 ` Dirk Herrmann
2002-08-04 2:03 ` Han-Wen
2002-08-04 2:05 ` Tom Lord
2002-08-04 2:11 ` Tom Lord
2002-08-04 2:20 ` for example Tom Lord
2002-08-04 2:27 ` i know -- let's play bridge! Tom Lord
2002-08-04 2:46 ` Tom Lord
2002-08-04 2:50 ` Thomas Bushnell, BSG
2002-08-04 2:57 ` Tom Lord
2002-08-04 3:04 ` Thomas Bushnell, BSG
2002-08-04 3:43 ` Tom Lord
2002-08-04 3:53 ` Thomas Bushnell, BSG
2002-08-04 4:03 ` Tom Lord
2002-08-04 4:10 ` Tom Lord
2002-08-04 3:50 ` Tom Lord
2002-08-04 3:55 ` Tom Lord
2002-08-04 3:58 ` Tom Lord
2002-08-05 18:15 ` status: separation of expansion/optimization/memoization/execution Marius Vollmer
2002-08-05 18:11 ` Marius Vollmer
2002-08-07 20:51 ` Dirk Herrmann
2002-08-10 13:01 ` Marius Vollmer
2002-08-14 19:30 ` Dirk Herrmann [this message]
2002-08-26 22:11 ` Marius Vollmer
2002-08-05 18:36 ` Neil Jerram
2002-08-07 20:55 ` Dirk Herrmann
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=Pine.GSO.4.05.10208142109010.6796-100000@sallust.ida.ing.tu-bs.de \
--to=dirk@sallust.ida.ing.tu-bs.de \
--cc=guile-devel@gnu.org \
--cc=guile-user@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.
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).