Joe Marshall <firstname.lastname@example.org> wrote:
| Kent M Pitman <email@example.com> writes:
| > However, I think it's pretty clearly wrong to think that consing doesn't
| > matter, so even if you start thinking that you want to do some style that
| > prefers non-destructive over destructive, I don't think that means you're
| > suddenly free of the cost of gc and consing. In both styles, you still
| > have to worry about storage wastage, about intermediate expression swell,
| > etc.
| Consing doesn't matter as much as it used to. There's no longer a
| need to watch your allocation like a hawk(inson).
| Of course, you can always slow things down by *excessively* depending
| on the GC.
Generational GCs that use Ungar's trick of a fixed-location "nursery"
typically find that the best nursery size is roughly the size of the
secondary cache [or in more recent CPUs, the tertiary cache or whichever
one is just before main memory!]. One assumes that the GC designer will
have done their job right, and initialized the size of the nursery
dynamically based on the cache size of the currently-running platform.
In which case, the best strategy for the user [meaning programmer]
is to try to arrange that the vast majority of intermediate storage
consed is garbage by the time a nursery-size worth's has been consed,
whereupon almost none of the data in the nursery is still "live" at
the next minor GC. Hence allocations & minor-GCs keep using the same,
cached(!) address range over & over...
In that context, note that "fresh" consing is often cheaper than
"mutating" recently-consed objects [the latter requiring a range
check to consider (and reject) adjusting the "remembered set"], but
the former will use up space in the nursery faster and trigger more
minor GCs. Hence which one is better "just depends"... as always. ;-}
Rob Warnock <firstname.lastname@example.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607