[Openmcl-devel] Understanding the impact of consing

[Gary Byers]

I enjoyed reading your blog post,


One thing that people seem not to realize is that the cost of consing

depends on how and for how long the allocated object is referenced.  Most

of the work done by the GC involves  the non-garbage objects that survive,

and it is easy to see this.


(defun keep (n l)
   (unless (zerop n)
     (keep (1- n) (cons l nil))))

(defun drop (n l)
   (unless (zerop n)
     (drop (1- n) (cdr (cons l nil)))))

Try calling

(time (drop (ash 256 30) nil))

.and then try calling

(time (keep (ash 256 30) nil))


each call will allocate around 4 gb (and you may need to ensure

that you have adequate physical memory in the KEEP case.  I think

uou'll likely find that consing short-lived data is often very cheap,

and that preventing the the gc from reclaiming memory can be a very costly

thing to do.


at one point, the blog post speculates that



triggering the GC more frequently [may be] helping somehow by compacting 
the remaining garbag





note that the gc may compact or otherwise reorganize the non-garbage 
(the live data that survives the gc.)
.
Doing so may may reduce the number of cache lines, pages, and other 
finite resources code needs to
process that data, and that can be a measurably good thing.

On 08/06/2016 07:21 AM, Max Rottenkolber wrote:
> Hi everyone,
>
> I have written a blog post about the challenges I encountered during the
> development of MaxPC,¹ a combinatory parsing library. In one section I talk
> about how consing affects performance on CCL (or not), and I don't have answers
> to some of my observations. I would be extremely grateful to someone with a
> better understanding of CCL internals than me to fact/sanity check the section
> “To Cons, or Not to Cons?” specifically:
>
>    http://mr.gy/blog/maxpc.html#section-3-2
>
> (I would include a text version, but without the diagram it makes little
> sense.) Understanding what’s going on might require reading the source (links
> to the relevant sections are in the benchmark diagram description), which is
> probably too much to ask, but who knows, maybe someone finds this as
> interesting as I do.
>
> Thanks in advance to anyone who donates their attention.
>
> Cheers,
> max
>
> [1]: https://github.com/eugeneia/maxpc
>
> _______________________________________________
> Openmcl-devel mailing list
> Openmcl-devel at clozure.com
> https://lists.clozure.com/mailman/listinfo/openmcl-devel