I will take better runtime over compile time expense any day. Thanks.
Blake On Wed, Oct 29, 2014 at 11:01 AM, Camm Maguire <[email protected]> wrote: > 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 <[email protected]> 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 <[email protected]> > wrote: > > > > Greetings! > > > > Blake McBride <[email protected]> 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 > > > [email protected] > > > https://lists.gnu.org/mailman/listinfo/gcl-devel > > > > -- > > Camm Maguire > [email protected] > > > ========================================================================== > > "The earth is but one country, and mankind its citizens." -- > Baha'u'llah > > > > -- > Camm Maguire [email protected] > ========================================================================== > "The earth is but one country, and mankind its citizens." -- Baha'u'llah >
_______________________________________________ Gcl-devel mailing list [email protected] https://lists.gnu.org/mailman/listinfo/gcl-devel
