Re: [Gcl-devel] What do the times represent

[Camm Maguire]

Greetings!  I'm guessing from your other post that you are working with
2.7.0 aka master.  Great!  The build time is indeed slow, and this is
among the main reasons why this is not released yet.  But its not gc.
The compiler has become very 'sophisticated' and inlines everything in
terms of compressed lisp source.  On top of this, it iterates on
variable type collisions in tagbody and recursion, so computationally
it is quite involved.  It does produce superior code, but given how
compile-time and runtime have been merged in recent usage, it needs to
be able to cache previously compiled results, and this is not done yet.

Take care,

Blake McBride <address@hidden> writes:

> Perhaps you are right.  I thought "run-gbc" was time in GC.  In that case it 
> would have been drastic.  The "gbc" time, while clearly not drastic,
> is significant.  Building GCL takes a bit of time.  Given how much memory 
> machines have these days, bumping up the build-time memory footprint may
> be worth it.
>
> Thanks for the response.
>
> Blake
>
> On Tue, Oct 28, 2014 at 7:27 PM, Camm Maguire <address@hidden> wrote:
>
>     Greetings!
>    
>     Blake McBride <address@hidden> writes:
>    
>     > When building GCL I get messages like this:
>     >
>     > real time       :     32.630 secs
>     > run-gbc time    :     26.180 secs
>     > child run time  :      2.259 secs
>     > gbc time        :      4.119 secs
>     >
>     > I know what "real time" is.  What do the other times represent?
>    
>     child time -- time spent in forked children, mostly gcc.
>     gbc time -- garbage collection time
>     run-gbc time -- time spent in GCL proper outside of garbage collection.
>    
>     >
>     > In particular, I am wondering about "run-gbc time" and "gbc time".  If 
> "gbc" is garbage collection, I am wondering if there is some parameter
>     that
>     > can be set for building the system using a larger heap so that their 
> are fewer - or no - garbage collections.  If my interpretations are
>     correct,
>     > this could drastically speed system build time.
>     >
>    
>     What the figures above show is that one might save ~12% if gc could be
>     eliminated entirely.  Indeed, there are many settings which affect this
>     proportion, including the pre-allocation of various memory types.  One
>     might have a large image for system building, and a minimal final image
>     for final use, as it is generally desirable to minimize the disk image
>     and not guess what the user's memory demands are likely to be.  I'm
>     skeptical that 'drastic' savings are possible.
>    
>     Take care,
>    
>     > Blake McBride
>     >
>     > _______________________________________________
>     > Gcl-devel mailing list
>     > address@hidden
>     > https://lists.gnu.org/mailman/listinfo/gcl-devel
>    
>     --
>     Camm Maguire                                        address@hidden
>     ==========================================================================
>     "The earth is but one country, and mankind its citizens."  --  Baha'u'llah
>

-- 
Camm Maguire                                        address@hidden
==========================================================================
"The earth is but one country, and mankind its citizens."  --  Baha'u'llah