Re: [Gcl-devel] Re: [Maxima] Re: Lisp vs. Java vs. C++ speed comparison time? [LONG]

[Camm Maguire]

Greetings!

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

> Camm Maguire writes:
> > Greetings!
> > "Vadim V. Zhytnikov" <address@hidden> writes:
> >
> >>Valery Pipin writes:
> >>
> >>
> >>>On Saturday 03 July 2004 01:42, Camm Maguire wrote:
> >>><snipped>
> >>>
> >>>>All lisps here are the latest versions in Debian unstable.  GCL was
> >>>>run in ANSI mode.  The machine was a dual Xeon 2.4Ghz.  We already
> >>>>know that the relative GCL/CMUCL performance can vary somewhat by
> >>>>machine, presumably influenced by cache size and cpu/memory bandwidth
> >>>>ratios.  It is clear for example that CMUCL is doing a better job on
> >>>>the memory layout/access times which predominate in the gc time
> >>>>component.
> >>>
> >>>Is that the reason why  I do not observe the memory leakage with maxima 
> >>>computations  that done with cmucl
> >>>implementation. In opposite, the gcl implementation can consume so much 
> >>>memory that I force to restart the x-session
> >>>or even to reboot PC.
> >>>
> >>
> >>I don't think this is memory leak.  Gcl memory layout is less
> >>compact compared to one of cmucl. The same computation on GCL
> >>require more RAM and it starts swapping earlier.
> >>
> > This is an interesting observation.  If you can quantify this with
> > some reproducible examples, we might be able to take a look at it.
> 
> It's actually very simple observation.  Start lisp,
> and make 10000000 long list.  Something like
> (progn (setq w (make-list 10000000)) nil)
> For clisp and cmucl this operation extends
> RAM by ~80Mb while for GCL it requires ~120Mb.
> It is clear that GCL uses 3 words for one cons
> cell while cmucl and clisp use 2 words.
> I wonder what is gcl cons cell size on 64bit
> machines?
> 

OK, this I understand.  The 'two word cons' issue has been on the todo
list for consideration for some time.  I'll bring this up in the
discussion/prioritization post for 2.7.0 I hope to be submitting
shortly.  

I suppose the canonical way to do this is to make use of the two least
significant bits in the pointer value on 32bit machines to hold the
type information, but this seems quite expensive as each pointer
indirection must be accompanied by a pointer truncation.
Alternatively, we could leave the pointers alone for indirection
speed, and make a 'type' call even more expensive by grouping cons
cells onto pages of their own, making one call to 'page()' and then
checking the cons cell free list for gc'ed items.  Maybe the last step
can be skipped in non-safe compiled code.  We are at least quite
fortunate that our cons cells are not relocatable in this regard.
One other idea which might be a bit dangerous would be to preserve the
current ->d.t semantics for the type, but to place t at a location
where its most significant bit would always be zero for pointers
anywhere in the heap, we'd then number the other types up from 128. 

We take three words on 64 bit systems too -- 24 bytes per cons.

Take care,

> -- 
>       Vadim V. Zhytnikov
> 
>       <address@hidden>
> 
> 
> 

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