Re: [Chicken-users] Re: compiling jbogenturfa'i .scm => .c takes 2.5 hours

[Alan Post]

On Sat, Nov 27, 2010 at 11:50:48PM +0100, Felix wrote:
> > I've rerun the build with "-debug 2", and it sent a lot of output to
> > the terminal.  The build hasn't finished running yet, but the
> > terminal output has stopped.  Here is the file so far, which I think
> > is what you were asking for.  If this file is too much, I'll run the
> > same command on a smaller portion of the grammar (say just the
> > morphology file) or on a toy grammar.  It should still be showing
> > the problem, just perhaps not at the scale I see on the full Lojban
> > grammar.
> > 
> > Looking at this, can you point me in the right direction? (172K):
> > 
> >   http://lodockikumazvati.org/download/jbogenturfahi.build.log.bz2
> > 
> > I traced statement45, which is behaving roughly like I would expect,
> > with it being set to undefined, used in several lambda expressions,
> > and then defined inside the letrec.  The same story with sumti75.
> > Is it the excessive number of ##core#lambda expressions that is causing
> > my problem?  If that isn't the right track, nothing here is catching
> > my eye and so I begin to expect something post-macro expansion.
> 
> Hm. I'm not sure. Could you run it again with "-debug bosp"?
> (and without the "-debug 2"). Could you also give me access to
> the generated .c file? (just run chicken-install with the -k
> option). 
> 

My previous e-mail concerning my initial success was premature, there
is one complication that I'm dealing with.  Each record in my letrec
is a generator, in that the <init> portion generating the value for
<variable> should only be run only once.  If it is run multiple times,
I generate the code multiple times.  This is how it works currently:

  (letrec ((gerna (nunjavni-morji ...)))
     gerna)

If I change that to use a lambda:

  (letrec ((gerna (lambda () (nunjavni-morji ...))))
     (gerna))

Then any place that gerna is called will generate a new
nunjavni-morji, which is my memoization routine (nunjavni-morji
means: "memorization rule generator") .  This by definition has
side-effects, so I can't do that.  I really need one memoization routine
per record.  I would have to say something like this:

  (letrec ((gerna (let ((result '())
                        (generated #f))
                    (lambda ()
                      (if generated
                          result
                          (begin (set! result (nunjavni-morji ...))
                                 (set! generated #t)
                                 result))))))
    (gerna))

Meaning I would have an outer lambda to catch recursive references
to other letrec records, but my lambda would want to generate the
results once, and return that single result every time it is referenced.

Which I *could* do, but wow does it strike me as ugly.  This is why
I generated the code I did originally, which wrapped each *reference*
to a record in a lambda, rather than each *definition* of a record in
a lambda.

So I'm back to wondering if there is any way that each lambda
expression I generate as a result of referencing a letrec record can
somehow be merged, reducing the size of the compiled code but allowing
me to keep the generated scheme code like it is now.

As requested, here is the output and .c code resulting from using
'debug -bosp':

The build output (2K) (Note that this failed after generating the C
file, as I forget to run without a memory ulimit.  It did generate
the C file, however):

  http://lodockikumazvati.org/download/jbogenturfahi.bosp.build.log.bz2

The C code generated from running with '-debug bosp' (942K): 

  http://lodockikumazvati.org/download/jbogenturfahi.bosp.c.bz2

Does anything in these files provide a suggestion as to what I could
do differently?

-Alan
-- 
.i ko djuno fi le do sevzi