(no subject)

(no subject)

[±è°æÀÏ]

[-- Attachment #1: Type: text/html, Size: 4702 bytes --]

(no subject)

[Han-Wen]

Subject: status: separation of expansion/optimization/memoization/execution
In-Reply-To: <Pine.GSO.4.05.10208022349150.5209-100000@sallust.ida.ing.tu-bs.de>
References: <Pine.GSO.4.05.10208022349150.5209-100000@sallust.ida.ing.tu-bs.de>
X-Mailer: VM 7.05 under Emacs 21.2.1
Reply-To: hanwen@cs.uu.nl
FCC: ~/persoonlijk/Mail/sent

dirk@sallust.ida.ing.tu-bs.de writes:
> Hi folks,
>  [ eval hacking ]

I'm just wondering -- Some time ago Keisuke Nishida (sp?) was working on
a byte compiler for GUILE that offered major speedups in many
cases. Is that still being pursued?

--
Han-Wen Nienhuys   |   hanwen@cs.uu.nl   |   http://www.cs.uu.nl/~hanwen 

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

Re: (no subject)

[Rob Browning]

Han-Wen <hanwen@cs.uu.nl> writes:

> I'm just wondering -- Some time ago Keisuke Nishida (sp?) was
> working on a byte compiler for GUILE that offered major speedups in
> many cases. Is that still being pursued?

Not at the moment.  He had to stop working on that (at least for a
while), and I can't recall if he though he'd be able to get back to
it.

Regardless, I think the general plan was to first get the evaluation
process cleaned up a bit and then step back and consider what comes
next.  There as been discussion of scm->c, jit, lightning-based-jit,
gcc-front-end-based[1], and traditional byte compilation.  Once the
evaluation process better separates memoization and execution from
each other and from the other steps (a la Dirk's current work).  It
should be a lot easier to explore the possibilities.

[1] which with the addition of -foptimiize-sibling is now at least one
    step more likely to be feasible, though perhaps still not the
    right idea.  I'm still not sure that gcc's intermediate language
    has all the features you'd really need.

    Interesting related link:
      http://gcc.gnu.org/frontends.html -- see FLIM -- a realy simple
      example gcc front end, and Ksi, a compiler from a very thin sexp
      representation of gcc's intermedate trees to machine code, and
      Gont a high level language that spits out forms to be processed
      by Ksi on the back-end.

-- 
Rob Browning
rlb @defaultvalue.org, @linuxdevel.com, and @debian.org
Previously @cs.utexas.edu
GPG=1C58 8B2C FB5E 3F64 EA5C  64AE 78FE E5FE F0CB A0AD

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

(no subject)

[Dirk Herrmann]

Clinton Ebadi wrote:
> > I don't care how memoization works.  I understand there are
> > optimization issues.  Optimizing isn't important to me, or
> > I would not use an interpretive language as my "extension
> > language".  If you add a disabling mechanism, then you'll
> > have the best of all worlds.  You can memoize/optimize to
> > your heart's content, and I'll disable it for my purposes.
> > If that is not practical and Guile becomes, essentially,
> > an semi-compiled language with constraints on where
> > defines may happen, then my goose will be cooked.
>
> Not to mention how Guile wouldn't be Scheme anymore. Why can't code be
> memiozied and compiled incrementally?

First, why wouldn't guile be scheme any more if conditional definitions
are disallowed?  They are disallowed by R5RS, so actually, if you
understand "being scheme" as "conforming to R5RS" then currently guile is
not scheme and disallowing conditional definitions will bring it one step
closer to "being scheme" :-)

Second, certainly can code be memoized and compiled incrementally.
However, this would have to be done every time the code was read in again,
since in an expression like (if <condition> (define <foo> <bar)) the value
of <condition> may change every time the code is read in.  That is, we
would reduce our possibility to pre-compile code.  Pre compiling code,
however, is one of our options to speed up guile's starting time (aside
from optimizing guile's module system...).

Best regards, 
Dirk Herrmann



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

Memoization, define and all that

[tomas]

On Sat, Nov 09, 2002 at 09:29:40AM +0100, Dirk Herrmann wrote:
> 
> Clinton Ebadi wrote:
> > > I don't care how memoization works.  [...]

[...]

> First, why wouldn't guile be scheme any more if conditional definitions
> are disallowed?  They are disallowed by R5RS, so actually, if you
> understand "being scheme" as "conforming to R5RS" then currently guile is
> not scheme and disallowing conditional definitions will bring it one step
> closer to "being scheme" :-)

Hrm. As marius pointed out elsewhere, this isn't just an issue with define,
but actually with any form which might get expanded before/at compile time.

> Second, certainly can code be memoized and compiled incrementally.
> However, this would have to be done every time the code was read in again,
> since in an expression like (if <condition> (define <foo> <bar)) the value
> of <condition> may change every time the code is read in.

Yes, as far as we can't make sure (e.g. by static code analysis) that
we have a fixed value for <condition>. As soon as <condition> is known,
things look better (and if <condition> isn't known, there might be a
reason to it, that is, the programmer is willing to pay for the overhead).

Of course I'm not favouring a thorough code analysis (is that decidable
at all?), but: if you *know* a thing to be constant -- go ahead and
memoize, if you *don't know* well, take with you a reference to the lexical
environment (you have to do this for macros, in some way or other, don't
you?) and leave things as they are.

With time you can get better by expanding the set of situations you *know*
about. This is what I had in mind when I was talking something about partial
evaluation.

Does this sound plausible?

> That is, we would reduce our possibility to pre-compile code.

But only in those cases which you are about to prohibit. You can always
pre-compile the ``goodies'' (e.g. those lexical spans where `define is
not redefined, etc.). May be I'm overlooking something here, but I tend
to view pre-compilation as a kind of constant folding.

> Pre compiling code, however, is one of our options to speed up guile's
> starting time (aside from optimizing guile's module system...).

Yep. And I think it a bearable burden for the programmer to keep some
things in mind if she intends to write well-compilable code. But as
long as we have eval around (and we won't like to miss this one do we?),
we'll have an instance of the compiler/interpreter around, so it
doesn't hurt postponing things (other than performance, that is). So
the trick might be to just postpone things ``when we don't know better'',
because someone is playing nasty tricks with our basic forms (whatever
they may be, I think define is just an example).

Thanks for your patience in reading my half-baked mumbling.

Regards
-- tomas


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

Re: (no subject)

[Clinton Ebadi]

On Saturday 09 November 2002 03:29, Dirk Herrmann wrote:
> > Not to mention how Guile wouldn't be Scheme anymore. Why can't code be
> > memiozied and compiled incrementally?
>
> First, why wouldn't guile be scheme any more if conditional definitions
> are disallowed?  They are disallowed by R5RS, so actually, if you
> understand "being scheme" as "conforming to R5RS" then currently guile is
> not scheme and disallowing conditional definitions will bring it one step
> closer to "being scheme" :-)

I was referring to the part where you would have to reload your code if a 
binding changed and the whole (define define define-private) etc. not 
working.

-- 
http://unknownlamer.org
Truth lies in loneliness
When hope is long gone by


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

(no subject)

[Karen Ferguson]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1.1: Type: text/plain; charset="iso-5748-8", Size: 401 bytes --]

Hi again,

Here is Karen Ferguson. I wite you because we are accepting your mortgage application.
Our office confirms you can get a $220.000 loÀn for a $352.00 per month payment.
Approval process will take 1 minute, so please fill out the form on our website:

http://methodic.moneyintelligent.info/j8/o0o.php?jq1=101



Thank you.

Best Regards Karen Ferguson
First Account Manager



[-- Attachment #2: Type: text/plain, Size: 143 bytes --]

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

(no subject)

[Tanisha Villalobos]

Hi again,

Here is Tanisha Villalobos. I write to you because we are accepting your m=
ortgage application.
Our office confirms you can get a $220.000 lo=C0n for a $252.00 per month =
payment.
Approval process will take 1 minute, so please fill out the form on our we=
bsite:


http://lockian-growth.refi-talk.com


Thank you.

Best Regards Tanisha Villalobos
First Account Manager





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

(no subject)

[Neil Jerram]

ludo@gnu.org (Ludovic Courtès) writes:

> I should have mentioned this one:
> http://thread.gmane.org/gmane.comp.programming.garbage-collection.boehmgc/3185 .
>
> This is normally somewhat fixed in current BDW-GC CVS, but Guile itself
> may have troubles of its own dealing with cancellation.

Thanks.  I thought already about cancellation, but I couldn't see
anything in the test program that would do that.  Do you know of
anything in that program, or in BDW-GC, that does a pthread_cancel?

> The critical section issue should be orthogonal, though.

Yes.

> Here it is:

Thanks, and thanks to Ken also.

I've cherry-picked the following branch_release-1-8 fixes.

commit 499c43b03225abb8d3af9087b7630d523b74e13a
Author: Neil Jerram <neil@ossau.uklinux.net>
Date:   Thu Mar 5 20:03:33 2009 +0000

    Avoid throw from critical section, given invalid sigaction call

(This is for a different critical section problem, but which still
occurs (prior to this commit) in master.)

commit 3009b5d557e1ebfd828fd0de9b1da5abb2f6ec9a
Author: Neil Jerram <neil@ossau.uklinux.net>
Date:   Tue Mar 10 23:55:31 2009 +0000

    Fix spurious `throw from within critical section' errors

(This is the commit that I hope will fix the errors that you're seeing.)

Can you see how the test runs now?

Also, can I check my thinking on one other fix, and how it
interacts with BDW-GC?

commit 2bfcaf2605f8366d8c708c148bde5313b88497e0
Author: Neil Jerram <neil@ossau.uklinux.net>
Date:   Wed Mar 4 23:45:11 2009 +0000

    Lock ordering: don't allocate when in critical section (scm_sigaction_for_thread)

With BDW-GC I believe that allocation in a critical section is no longer
a problem, specifically because

- the stop-the-world mechanism uses signals and sigsuspend - whereas
  Guile GC used mutexes - and hence there are no concerns about lock
  ordering

- it doesn't matter if there are threads waiting for the critical
  section when a GC happens, because the signal mechanism will still
  interrupt them.

Is that right?

Thanks!
        Neil

(no subject)

[Neil Jerram]

Ken Raeburn <raeburn@raeburn.org> writes:

> On Sep 30, 2009, at 16:59, Neil Jerram wrote:
>> I've cherry-picked the following branch_release-1-8 fixes.
>
> With these fixes, indeed, I can't reproduce the problem any more; I
> left the test program running for over an hour, whereas before it
> would trigger the problem almost immediately.
> Thanks!

Great news; thanks for trying and confirming that.

      Neil

(no subject)

[Neil Jerram]

ludo@gnu.org (Ludovic Courtès) writes:

>>> This is normally somewhat fixed in current BDW-GC CVS, but Guile itself
>>> may have troubles of its own dealing with cancellation.
>>
>> Thanks.  I thought already about cancellation, but I couldn't see
>> anything in the test program that would do that.  Do you know of
>> anything in that program, or in BDW-GC, that does a pthread_cancel?
>
> Hmm no, sorry for the confusion.  The srfi-18 test this was taken from
> did use cancellation, though.

OK, thanks for clarifying that.  I guess there must be something other
than cancellation lurking.

> Good that you noticed it was missing from ‘master’.  (BTW ‘signals.test’
> should be changed to GPLv3+ and have a ‘define-module’ clause.)

Thanks, done.

>> commit 3009b5d557e1ebfd828fd0de9b1da5abb2f6ec9a
>> Author: Neil Jerram <neil@ossau.uklinux.net>
>> Date:   Tue Mar 10 23:55:31 2009 +0000
>>
>>     Fix spurious `throw from within critical section' errors
>>
>> (This is the commit that I hope will fix the errors that you're seeing.)
>>
>> Can you see how the test runs now?
>
> The abort () is apparently never reached with this patch.
>
> It took me some time to understand this:
>
> -  if (scm_i_critical_section_level)
> +  if (thread->critical_section_level)
>      {
>        fprintf (stderr, "continuation invoked from within critical section.\n");
>        abort ();
>
> Critical sections concern all the threads in guile mode.  Thus I would
> think that the question “are the threads in a critical section?” cannot
> be answered by looking at a per-thread ‘critical_section_level’.

That's not the question here.  The question is "is _this_ thread in a
critical section?"  There's no reason (AFAIK) why thread A shouldn't
throw while thread B is in a critical section.

Note that access to the critical section is controlled by a mutex, not
by (scm_i_)critical_section_level.  (scm_i_)critical_section_level only
exists to catch genuine "throw from critical section" errors.

> However, it really seems that the intent was really to forbid ‘throw’s
> when the *current thread* is holding the critical section mutex, so the
> patch is correct but I find the name ‘critical_section_level’ is
> slightly misleading.

The tricky detail here is that scm_i_critical_section_mutex is
initialized as a recursive mutex, so the implication is that it's
possible for a thread to enter the critical section multiple times.
Hence we need some kind of "level", instead of just a boolean
"in_critical_section".

> What do you think?

I have no objection to a more intuitive name, if you can suggest one.

>> Is that right?
>
> Yes.

Thanks.

> BTW, rest assured: thanks to libgc we won’t get any Helgrind report!
> :-)

I assume you mean because most of the helgrind reports involved the
heap_mutex, which no longer exists.  Presumably we could still (in
theory) get helgrind reports for other mutexes?

Regards,
        Neil

(no subject)

[Neil Jerram]

ludo@gnu.org (Ludovic Courtès) writes:

>      should be OK.  However, I’m slightly concerned about MSVC’s
>      __declspec: does it work if it sees:
>
>        __declspec(dllexport) extern SCM foo (SCM);
>        extern SCM foo (SCM);

I don't know for sure, but I know I've seen "function redeclared with
different linkage" warnings in the past, and this could well be one of
the situations that generates such warnings.

But what about using SCM_API instead of extern?  Wouldn't that always
generate the right code?  (At least for building guile itself.)

>      If it works, that probably means this point is moot.
>
>   2. The automatically added ‘extern’ declaration makes
>      ‘-Wmissing-prototypes’ useless, which is annoying.

I guess it depends if the primitives in question are designed to be used
only from Scheme, or also from other C files.  If they're only for
Scheme, it's a nice feature that SCM_DEFINE does everything needed and
the developer doesn't need a matching prototype.  If they're for other C
files, the missing prototype warning could be helpful.

Then again, the developer will get some kind of warning anyway when
trying to use the function from another file.  So I think the balance is
in favour of SCM_DEFINE including the prototype.

   Neil

(no subject)

[Neil Jerram]

ludo@gnu.org (Ludovic Courtès) writes:

> Hi Neil,
>
> Neil Jerram <neil@ossau.uklinux.net> writes:
>
>> But what about using SCM_API instead of extern?  Wouldn't that always
>> generate the right code?  (At least for building guile itself.)
>
> You’re right.  It’ll work for building Guile itself, but most probably
> fail when building external libraries, because it will have
> SCM_API==dllimport whereas the symbols of the lib being built want
> dllexport.
>
> I have no idea how to fix this since third party libraries typically
> have their own ‘SCM_API’-like macro for that purpose.
>
> Well, we could just disable ‘SCM_SUPPORT_STATIC_ALLOCATION’ altogether
> for “Woe32” builds.
>
> What do you think?

We're talking here about macros that are always used in .c files, aren't
we?  (As opposed to headers that an application using the library would
include.)

So on Woe32, we actually always want dllexport.

i.e. if the header has
SCM_API SCM scm_frobate (SCM arg);

and the SCM_DEFINE in .c expands to something that includes
__declspec(dllexport) SCM scm_frobate (SCM arg);

that should be good, because SCM_API will be __declspec(dllexport) when
building the library.

In the Scheme-only case, that does mean exporting something that doesn't
need exporting - but either we can just live with that, or later add
your suggestion of SCM_DEFINE_LOCAL.

Regards,
        Neil