unofficial mirror of guile-devel@gnu.org 
 help / color / mirror / Atom feed
From: Mikael Djurfeldt <mdj@kvast.blakulla.net>
Cc: djurfeldt@nada.kth.se,  Dirk Herrmann <dirk@ida.ing.tu-bs.de>,
	guile-devel@gnu.org
Subject: Re: expansion, memoization, and evaluation...
Date: Wed, 04 Dec 2002 22:47:34 +0100	[thread overview]
Message-ID: <xy7isy9v4ll.fsf@linnaeus.i-did-not-set--mail-host-address--so-tickle-me> (raw)
In-Reply-To: <878yz5fq1l.fsf@raven.i.defaultvalue.org> (Rob Browning's message of "Wed, 04 Dec 2002 15:11:02 -0600")

Rob Browning <rlb@defaultvalue.org> writes:

> OK, so does that mean that at each invocation, you need to look at the
> incoming types and check to see if you already have a cached method
> that matches the incoming signature?  i.e. if you have
>
>   (blah)
>   (foo bar baz)
>   (blarg)
>
> and foo is a generic function, and last time through, bar and baz were
> integers, but this time bar and baz are strings.  Would the current
> behavior be for goops to check, notice this, and build a new
> "precompiled" invocation for two strings?

Yes.

> For example, if you know that within a given function (or closed set
> of functions) you use some set of symbols, and within the set you
> have big (case foo ...)  statements using those symbols, you may be
> able to compile the object code to use plain integers to represent
> these symbols and then issue c-style switches to handle the case
> statements.

Yes, a wonderful optimization.  :-)

And if the compiler gets source back from the goops optimizer or does
flow analysis, it may know the types of some arguments and some
expressions in the source, and might be able to use native integer or
double representation.  In this context it's nice that a goops
"cmethod" (the result of compile-method) has a fixed type signature.

> (Of course if the guile compiler were implemented targeting C, and if
>  guile were to "Depends: gcc", we might be able to use dlopen/dlsym to
>  support heavyweight online compilation.

Yes, yes, yes!

> Though first-time execution would be awfully painful unless your
> machine was really fast ;>)

I wouldn't be so sure.  Of course we wouldn't get "real-time"
performance but I think the performance of the current goops is
promising considering what *it* does for each "first" invocation:

Traversing and rewriting the entire method source and rebuilding the
entire GF method cache up to eight times... and all of it done on the
Scheme level.

Maybe I shouldn't reveal this :), but I've seen the current goops as a
large-scale experiment to test whether these crazy ideas really work
in practise.  And they actually seem to.  I've made heavy use of goops
in large systems consisting of maybe 50 modules, and I don't have any
complaints on its performance.

Best regards,
Mikael


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel


  reply	other threads:[~2002-12-04 21:47 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-12-04  2:41 expansion, memoization, and evaluation Rob Browning
2002-12-04  2:57 ` Mikael Djurfeldt
2002-12-04  3:10   ` Rob Browning
2002-12-04  3:31     ` Mikael Djurfeldt
2002-12-04  4:07       ` Rob Browning
2002-12-04  7:07         ` Mikael Djurfeldt
2002-12-04 21:11           ` Rob Browning
2002-12-04 21:47             ` Mikael Djurfeldt [this message]
2002-12-05  0:07               ` Rob Browning
2002-12-05 16:27                 ` Marius Vollmer
2002-12-05 17:07                   ` Rob Browning
2002-12-04  8:09   ` klaus schilling
2002-12-04 10:55     ` Mikael Djurfeldt

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=xy7isy9v4ll.fsf@linnaeus.i-did-not-set--mail-host-address--so-tickle-me \
    --to=mdj@kvast.blakulla.net \
    --cc=dirk@ida.ing.tu-bs.de \
    --cc=djurfeldt@nada.kth.se \
    --cc=guile-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. 
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).