Re: [Gcl-devel] Re: gcl

[Camm Maguire]

Greetings!

"Vadim V. Zhytnikov" <address@hidden> writes:

> Camm Maguire wrote:
> 
> > Greetings!  Thanks for your input here Vadim!
> >
> > OK, first some news: it appears that the libc2.2.4 on Linux is
> > basically fixed. In addition to the stack issue uncovered by Robert
> > Read, there is another small change in my tree against rsym_elf.c to
> > map _setjmp onto __sigsetjmp.  With these two changes, maxima's make
> > test runs without error for me on libc2.2.4.  Will be committing these
> > changes soon.
> >
> > Given that one of our top priority items on which you had been working
> > may now be done (please confirm with the new commits when they are
> > in), would you perhaps like to look into this?  I think you have the
> > most experience with big memory usage.  You are after all the one who
> > came up with that gmp relocation test.  Perhaps you could start
> > digging into the code, and offering some thoughts on what memory
> > redesign would be necessary to get behavior more in line with CLISP
> > et.al.?
> >
> > On some good advice from Peter van Eynde, it would seem that we will
> > always need a garbage collector
> 
> Certainly yes. GC is essential part of any Lisp system. The only
> alternative
> I ever heard of  - to have really HUGE amount of virtual memory
> and
> just don't do any memory GC of freeing (not very practical
> approach).
> 

OK, then lets chalk up the idea of doing away with gc to my naivete
coming from the world of C :-)

> > (as opposed to malloc/free), and that
> > conservative ones fit C the best.  He recommends the Boehm libgc, and
> > it does appear to be used widely in a number of projects.  A version
> > even ships with the gcc compilers!  What's more, it is relatively easy
> > to implement, so I'm going to have a go at porting gcl to it as soon
> > as this libbfd stuff is done.  This gc can run incrementally too.  It
> > may have a significant performance impact.
> >
> > But simply porting this gc will not solve the fragmented memory design
> > issue.  Can you help here Vadim?
> >
> 
> I've been thinking about my possible contribution to GCL project
> last days
> and I was about to propose another task to me - to track down non
> ANSI
> and missing ANSI features in GCL. But as far as I understand
> there is already
> other person - Richard Leddy who is willing to take care of it.
> Am I right about this?
> 

I've written Richard, but have received no reply as yet.

But in any case, Vadim, I think you should do what you feel best at,
and most comfortable with.  If any skills are in short supply with our
current group, they are lisp skills, and you are invaluable here.  As
for the Lisp issues, I see the broad outline like this (in no
particular order):

1) getting the cltl1 test-suite in the 2.5.0 test directory to run
   without error (used by CLISP as an integrity check)
2) importing the ansi testsuite mentioned by Peter, and getting ansi
   behavior with a '-ansi' runtime switch.
3) compiling standard lisp libraries with gcl, whatever people find
   useful, e.g. clx, etc.

Which ever one of these you feel is most irritating as a lisp
programmer, please jump in and do your best at suggesting fixes.  1)
should be pretty easy -- just a matter of using #+ and #- as
appropriate (see testing files for examples with CLISP, etc.), and
documenting all legitimate failures.


> As for GC issue the main trouble is that I'm not experienced C
> programmer.
> As Lisp programmer I see how GCL's GC works and I feel that I do
> not
> quite like it. But I'm not sure that I'm qualified enough to make
> concrete
> proposals how to rewrite it in C. I could do some investigation
> about GC
> methods in CLisp, CMUCL and possible other lisps and compare it
> to GCL with the aim to understand what the difference is and what
> can be done to improve situation. But certainly I can't do it
> very 
> quickly :-( 
> 

the main benefit you *can* offer here is the user's perspective of how
gcl differs from the others with respect to *memory usage*, not gc per
se.  (It looks like we'll be headed in the Boehm gc direction, so this
matter is at least close to being settled).  Frankly, I don't even
have a good handle yet on what the different types of gcl memory are,
and what they are used for.  And I certainly don't know if CLISP or
the others have something like (allocate...) or not, and if not, how
they grow the heap.  Is it just a question that gcl will grow the
memory as needed without any special commands, but will do so more
slowly?  Any idea why this is?  Which of the memory segments are most
likely to run out first?  Specifically, in your test example you
shared on testing the gmp relocations, is gcl comparable in
performance when used with your init.lsp allocating all that memory?
And can one change those allocated values later in the session should
one run out of memory?  I.e. is the allocation necessary to run big
jobs, or merely a performance aid?


Take care,

> 
> >
> > Take care,
> >
> > "Vadim V. Zhytnikov" <address@hidden> writes:
> >
> > > Camm Maguire wrote:
> > >
> > > >
> > > > And then my wish list:
> > > >
> > > > 7) Clean the code!  No errors with -Wall, comment, etc.
> > > > 8) dlopen instead of fasload.
> > > > 9) look into the Boehm conservative garbage collector.  Can we do
> > > >    without a garbage collector, and just 'free' at the appropriate
> > > >    time?
> > >
> > > I think that garbage collection is very important issue for GCL
> > > future. And improving GC must get quite high priority
> > > in the task list. If we temporarily forget about other
> > > problems GCL is quite good and fast Lisp implementation
> > > unless time comes to make GC. As far as I understand
> > > at present memory in GCL is split in dozen of regions
> > > each serving as storage for data of some particular type.
> > > And memory can't be relocated between these regions
> > > at run time. It is not so bad for making some experiments
> > > with Lisp but it is bad for doing practical calculations.
> > > You can easily have a situation when you have plenty of
> > > RAM in general but run out of memory of some particular
> > > type X. So now to work with GCL you must permanently
> > > watch memory usage and adjust it manually according to you
> > > particular problem. This is not what the average user want to do.
> > > The problem is clearly visible when you run some
> > > large Lisp programs, like Maxima, on GCL.
> > > On GCL test run time strongly depends on the
> > > the amount of memory pre allocated at start time.
> > > Nothing like this is observed when running Maxima
> > > on other Lisps, say Clisp or CMUCL. This just proves
> > > that at present memory allocation and GC strategy
> > > in GCL is not so good.
> > >
> > > Vadim
> > >
> > >
> > > --
> > >
> > > [ Vadim V. Zhytnikov  <address@hidden>  <address@hidden> ]
> > >
> > >
> > >
> > >
> > >
> > > _______________________________________________
> > > Gcl-devel mailing list
> > > address@hidden
> > > http://mail.gnu.org/mailman/listinfo/gcl-devel
> > >
> > >
> >
> > --
> > Camm Maguire                                            address@hidden
> > ==========================================================================
> > "The earth is but one country, and mankind its citizens."  --  Baha'u'llah
> 
> --
> 
> [ Vadim V. Zhytnikov  <address@hidden>  <address@hidden> ]
> 
> 
> 
> 

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