Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.lisp > #60742 > unrolled thread

Resources to learn common lisp?

Back to article view | Back to comp.lang.lisp

Contents

  Resources to learn common lisp? Mario Rosell <mario@mariorosell.es> - 2026-02-20 22:53 +0100
    Re: Resources to learn common lisp? Ben Bacarisse <ben@bsb.me.uk> - 2026-02-20 22:00 +0000
      Re: Resources to learn common lisp? Mario Rosell <mario@mariorosell.es> - 2026-02-21 12:25 +0100
        Re: Resources to learn common lisp? Stefan Monnier <monnier@iro.umontreal.ca> - 2026-02-21 10:24 -0500
        Re: Resources to learn common lisp? Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-02-21 21:30 +0000
          Re: Resources to learn common lisp? Mario Rosell <mario@mariorosell.es> - 2026-02-22 01:08 +0100
            Re: Resources to learn common lisp? Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-02-22 04:59 +0000
              Re: Resources to learn common lisp? Madhu <enometh@meer.net> - 2026-02-22 10:59 +0530
                Re: Resources to learn common lisp? Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-02-22 21:48 +0000
                  Re: Resources to learn common lisp? steve g <sgonedes1977@gmail.com> - 2026-06-08 12:43 -0400
          Re: Resources to learn common lisp? steve g <sgonedes1977@gmail.com> - 2026-06-08 12:41 -0400
            Re: Resources to learn common lisp? tfb <no_email@invalid.invalid> - 2026-06-08 20:02 +0000
              Re: Resources to learn common lisp? steve g <sgonedes1977@gmail.com> - 2026-06-09 00:23 -0400
                Re: Resources to learn common lisp? tfb <no_email@invalid.invalid> - 2026-06-09 06:28 +0000
                  Re: Resources to learn common lisp? tfb <no_email@invalid.invalid> - 2026-06-09 06:32 +0000
                    Re: Resources to learn common lisp? steve g <sgonedes1977@gmail.com> - 2026-06-10 12:27 -0400
                      Re: Resources to learn common lisp? tfb <no_email@invalid.invalid> - 2026-06-11 17:33 +0000
                  Re: Resources to learn common lisp? steve g <sgonedes1977@gmail.com> - 2026-06-10 12:16 -0400
              Re: Resources to learn common lisp? Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-09 06:53 +0000
                Re: Resources to learn common lisp? Axel Reichert <mail@axel-reichert.de> - 2026-06-09 12:07 +0200
                  Re: Resources to learn common lisp? Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-10 00:14 +0000
                Re: Resources to learn common lisp? tfb <no_email@invalid.invalid> - 2026-06-11 17:22 +0000
            Re: Resources to learn common lisp? Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-09 00:35 +0000
        Re: Resources to learn common lisp? steve g <sgonedes1977@gmail.com> - 2026-06-08 12:37 -0400
          Re: Resources to learn common lisp? Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-09 00:33 +0000
            Re: Resources to learn common lisp? steve g <sgonedes1977@gmail.com> - 2026-06-09 00:22 -0400
            Re: Resources to learn common lisp? Alan Bawden <alan@csail.mit.edu> - 2026-06-09 01:22 -0400
              Re: Resources to learn common lisp? tfb <no_email@invalid.invalid> - 2026-06-09 06:17 +0000
              Re: Resources to learn common lisp? Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-09 06:50 +0000
                Re: Resources to learn common lisp? steve g <sgonedes1977@gmail.com> - 2026-06-10 12:40 -0400
                  Re: Resources to learn common lisp? Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-11 00:26 +0000
                  Re: Resources to learn common lisp? George Neuner <gneuner2@comcast.net> - 2026-06-11 05:27 -0400
              Re: Resources to learn common lisp? steve g <sgonedes1977@gmail.com> - 2026-06-10 12:24 -0400
                Re: Resources to learn common lisp? George Neuner <gneuner2@comcast.net> - 2026-06-11 05:57 -0400
            Re: Resources to learn common lisp? Stefan Monnier <monnier@iro.umontreal.ca> - 2026-06-09 09:36 -0400
              Re: Resources to learn common lisp? Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-10 00:06 +0000
                Re: Resources to learn common lisp? Stefan Monnier <monnier@iro.umontreal.ca> - 2026-06-10 08:43 -0400
                  Re: Resources to learn common lisp? Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-11 00:22 +0000
                    Re: Resources to learn common lisp? Stefan Monnier <monnier@iro.umontreal.ca> - 2026-06-11 08:57 -0400
                Re: Resources to learn common lisp? George Neuner <gneuner2@comcast.net> - 2026-06-11 06:37 -0400
                Re: Resources to learn common lisp? tfb <no_email@invalid.invalid> - 2026-06-11 17:42 +0000
    Re: Resources to learn common lisp? tpeplt <tpeplt@gmail.com> - 2026-02-20 17:44 -0500
      Re: Resources to learn common lisp? Mario Rosell <mario@mariorosell.es> - 2026-02-21 12:30 +0100
    Re: Resources to learn common lisp? ram@zedat.fu-berlin.de (Stefan Ram) - 2026-02-20 23:50 +0000
      Re: Resources to learn common lisp? ram@zedat.fu-berlin.de (Stefan Ram) - 2026-02-21 00:24 +0000
        Re: Resources to learn common lisp? Andreas Eder <a_eder_muc@web.de> - 2026-02-21 11:36 +0100
        Re: Resources to learn common lisp? Mario Rosell <mario@mariorosell.es> - 2026-02-21 12:44 +0100
    Re: Resources to learn common lisp? steve g <sgonedes1977@gmail.com> - 2026-03-31 17:47 -0400
      Re: Resources to learn common lisp? Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-03-31 23:41 +0000
      Re: Resources to learn common lisp? tpeplt <tpeplt@gmail.com> - 2026-04-01 13:23 -0400
    Re: Resources to learn common lisp? Peri Didaskalou <pfd@torfree.net> - 2026-05-01 10:52 -0400
    Re: Resources to learn common lisp? Peri Didaskalou <pfd@torfree.net> - 2026-05-01 10:57 -0400
    Re: Resources to learn common lisp? Peri Didaskalou <pfd@torfree.net> - 2026-05-01 11:06 -0400
    Re: Resources to learn common lisp? steve g <sgonedes1977@gmail.com> - 2026-06-01 14:56 -0400
      Re: Resources to learn common lisp? "Robert B. Carleton" <rbc@rbcarleton.net> - 2026-06-01 23:02 +0000
        Re: Resources to learn common lisp? steve g <sgonedes1977@gmail.com> - 2026-06-02 21:32 -0400
          Re: Resources to learn common lisp? Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-03 03:16 +0000

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

#60840

On Tue, 09 Jun 2026 12:07:43 +0200, Axel Reichert wrote:

> Lawrence D’Oliveiro <ldo@nz.invalid> writes:
>
>> What’s a homoiconic language with postfix operation syntax?
>
> https://factorcode.org/
> https://concatenative.org/wiki/view/Factor/Features/The%20language

I see it needs to have an explicit “macro" construct to implement
homoiconicity. This was unnecessary in PostScript.

Here <https://gitlab.com/ldo/gxscript> is my attempt at a PostScript
revival.

[toc] | [prev] | [next] | [standalone]

#60851

Lawrence D´Oliveiro <ldo@nz.invalid> wrote:

> How about this for a definition: “homoiconicity with minimal syntax”.

I think this is close.  This would define what my friend Zyni would call a
'lispoid'.  She is mostly a mathematician, and this is by analogy with
terms like 'groupoid', which is something on the way to being a group.

For almost all purposes a lispoid is enough: it is not a term meant to
denigrate lispoids!  In particular lispoids are enough to support seamless
macros.  I think Clojure is probably a lispoid by this definition.

A lisp is then a lispoid where the underlying representation of source code
is singly-linked lists.
-- 
www.tfeb.org/computer/

[toc] | [prev] | [next] | [standalone]

#60826

On Mon, 08 Jun 2026 12:41:56 -0400, steve g wrote:

> Lawrence D’Oliveiro <ldo@nz.invalid> writes:
>
>> Lisp is a pretty interesting language, but it was never
>> standardized to the extent that we expect of languages today. Look
>> at the Common Lisp spec, and it still retains a lot of baggage to
>> maintain compatibility with obsolete OSes that simply don’t matter
>> any more.
>
>> And also, which particular Lisp do you want to learn? There are a
>> number in common use today:
>
> this is false. common lisp is a programming language.

In today’s terms, Common Lisp is only a partial language spec. It has
all that historical baggage, and yet it leaves out crucial things that
other languages, like Python, implement more uniformly today.

[toc] | [prev] | [next] | [standalone]

#60819

Mario Rosell <mario@mariorosell.es> writes:


< > Finally, what do you want learn it for?  It might just be for fun or
< > it might be because you have a very specific goal in mind for which
< > someone might have some specific recommendations.


actually lisp is best for researchers trying to test new alogrithims.
Fun as much as programming is fun...


> Just for fun. It seems like a pretty interesting language.


hook, line, and sinker!

[toc] | [prev] | [next] | [standalone]

#60825

On Mon, 08 Jun 2026 12:37:53 -0400, steve g wrote:

> actually lisp is best for researchers trying to test new [algorithms].

Lisp is purely garbage-collected though, isn’t it? Languages like Perl
and Python try for a hybrid reference-counted/garbage-collected
approach, for speed and also more deterministic memory usage in many
common scenarios.

I think you can use all three in Jupyter notebooks, anyway. That’s an
environment I recommend for just about any kind of “scratchpad” or
quick “experimentation” programming.

[toc] | [prev] | [next] | [standalone]

#60827

Lawrence D’Oliveiro <ldo@nz.invalid> writes:

> On Mon, 08 Jun 2026 12:37:53 -0400, steve g wrote:
>
< > actually lisp is best for researchers trying to test new [algorithms].


> Lisp is purely garbage-collected though, isn’t it? Languages like Perl
> and Python try for a hybrid reference-counted/garbage-collected
> approach, for speed and also more deterministic memory usage in many
> common scenarios.

i will not deny my love of this languagw. yes liSP uses GC. A hybride
approad? like unboxed numbers?

[toc] | [prev] | [next] | [standalone]

#60830

Lawrence D’Oliveiro <ldo@nz.invalid> writes:

> Lisp is purely garbage-collected though, isn’t it? Languages like Perl
> and Python try for a hybrid reference-counted/garbage-collected
> approach, for speed and also more deterministic memory usage in many
> common scenarios.

I don't think any of Common Lisp, Java, Perl or Python promise to employ
any particular algorithm for collecting garbage.  It's not something you
really need to put in your language specification document.  All you
need to say is that storage management is not something the programmer
needs to worry about.  Nothing prevents you from implementing a Common
Lisp that does reference counting.

It seems to be fashionable these days to consider reference counting to
be somehow different from garbage collection, but historically reference
counting was just another tool used for garbage collection.  At least
one of the InterLisp implementations used reference counting as part of
its garbage collector, and nobody thought that it had less of a true
garbage collector as a result.

-- 
Alan Bawden

[toc] | [prev] | [next] | [standalone]

#60832

Alan Bawden <alan@csail.mit.edu> wrote:
> Lawrence D’Oliveiro <ldo@nz.invalid> writes:
> 
> At least
> one of the InterLisp implementations used reference counting as part of
> its garbage collector, and nobody thought that it had less of a true
> garbage collector as a result.
> 

Those of us who had to write code to laboriously decircularize
about-to-be-dead structures on d machines definitely did!

But your point is right: these are implementation, not language, questions.

(I also hate the stupid 'reference counting is better' thing.  It is 2000
already, machines live or die on their caches.  I drop a large structure on
the floor.   A reference-counted implementation now dutifully walks over
the entire structure reducing all the counts to zero *and ensuring the
machine's caches are full of data that will never be used again*.   An
implementation with a copying GC ... never touches that memory again.  One
of these approaches is a lot less hostile to caches than the other.)

-- 
www.tfeb.org/computer/

[toc] | [prev] | [next] | [standalone]

#60835

On Tue, 09 Jun 2026 01:22:53 -0400, Alan Bawden wrote:

> Lawrence D’Oliveiro <ldo@nz.invalid> writes:
>
>> Lisp is purely garbage-collected though, isn’t it? Languages like
>> Perl and Python try for a hybrid
>> reference-counted/garbage-collected approach, for speed and also
>> more deterministic memory usage in many common scenarios.
>
> I don't think any of Common Lisp, Java, Perl or Python promise to
> employ any particular algorithm for collecting garbage. It's not
> something you really need to put in your language specification
> document.

It does have some subtle, but far-reaching, implications for language
usage, though.

For example, pure GC makes it easy to support multithreading. But the
downside is that it is easy for a single long-running program to
consume all available memory, even if its memory needs at any
particular moment are not that great. So you need to put arbitrary
constraints on its heap size. And if turns it that wasn’t enough for a
particular run, then you need to stop and re-run with a larger heap
allocation. Which defeats some of the point of dynamic memory
allocation when you have to micromanage such things, doesn’t it?

This is why both Perl and Python stuck with the hybrid approach. In
Perl’s case, they kind of fudged their approach to multithreading as a
consequence, with implications for sharing objects across threads.
While the Python folks have put a lot of effort into coming up with a
more comprehensive solution, making reference counts just a little bit
nondeterministic in return for greater performance while still
allowing object sharing to work the way you would expect.

[toc] | [prev] | [next] | [standalone]

#60844

Lawrence D’Oliveiro <ldo@nz.invalid> writes:

> On Tue, 09 Jun 2026 01:22:53 -0400, Alan Bawden wrote:
>
< > Lawrence D’Oliveiro <ldo@nz.invalid> writes:
< >
< >> Lisp is purely garbage-collected though, isn’t it? Languages like
< >> Perl and Python try for a hybrid
< >> reference-counted/garbage-collected approach, for speed and also
< >> more deterministic memory usage in many common scenarios.
< >
< > I don't think any of Common Lisp, Java, Perl or Python promise to
< > employ any particular algorithm for collecting garbage. It's not
< > something you really need to put in your language specification
< > document.
>
> It does have some subtle, but far-reaching, implications for language
> usage, though.
>
> For example, pure GC makes it easy to support multithreading.

!!? Ummm ??!


But the
> downside is that it is easy for a single long-running program to
> consume all available memory, even if its memory needs at any
> particular moment are not that great. So you need to put arbitrary
> constraints on its heap size.




> And if turns it that wasn’t enough for a
> particular run, then you need to stop and re-run with a larger heap
> allocation. Which defeats some of the point of dynamic memory
> allocation when you have to micromanage such things, doesn’t it?

> This is why both Perl and Python stuck with the hybrid approach. In
> Perl’s case, they kind of fudged their approach to multithreading as a
> consequence, with implications for sharing objects across threads.

with all due respect, garbage collection is very difficult. Most
programmers will use the best algorithm available; like guile does. PERL
is the fastest interpreter I have ever used, compiling the code to C
results in slower running speed. There is an issue with heap...

> While the Python folks have put a lot of effort [...]

there is no perfect solution; python can be compiled with LTO, I don't
have the numbers on me...

from what I understand this is a new method.

[toc] | [prev] | [next] | [standalone]

#60847

On Wed, 10 Jun 2026 12:40:48 -0400, steve g wrote:

> with all due respect, garbage collection is very difficult.

Why are there so many languages using it, then?

It’s difficult to implement efficiently -- that I would agree with.
Because that’s my point.

> Most programmers will use the best algorithm available; like guile
> does.

If there was a “best algorithm available”, then why would there need
to be a diversity of implementations?

> PERL is the fastest interpreter I have ever used, compiling the code
> to C results in slower running speed. There is an issue with heap...

And Perl is precisely one of the examples I mentioned, is it not, that
tries to keep reference-counting as a first resort before falling back
to garbage collection?

Wasn’t there a claim made by somebody in another posting that
reference-counting adds performance-sapping overhead compared to a
pure garbage collection approach? Yet here you are unwittingly
disproving that.

[toc] | [prev] | [next] | [standalone]

#60848

On Wed, 10 Jun 2026 12:40:48 -0400, steve g <sgonedes1977@gmail.com>
wrote:


>with all due respect, garbage collection is very difficult. Most
>programmers will use the best algorithm available; like guile does. PERL
>is the fastest interpreter I have ever used, compiling the code to C
>results in slower running speed. There is an issue with heap...

There is no one "best" algorithm.

GC is not "difficult" per se, but it is exacting and tedious to get
correct. GC is heavily dependent on - and often integrated with - the
allocation methods used, so heap layouts and data formats generally
determine what is the most effective method.

Moreover, any implementation that is not a toy will be a hybrid using
multiple different algorithms - short term data, long term data, and
"large" data (for some definition of "large") all routinely will be
handled differently.


Aside: reference counting doesn't work for cyclic data structures, so
although it is a valid method, it has to have some form of heap
sweeping backup if cyclic data structures are to be permitted.

[toc] | [prev] | [next] | [standalone]

#60842

Alan Bawden <alan@csail.mit.edu> writes:

> Lawrence D’Oliveiro <ldo@nz.invalid> writes:
>
< > Lisp is purely garbage-collected though, isn’t it?

yes common lisp uses GC.

<> Languages like Perl
< > and Python try for a hybrid reference-counted/garbage-collected
< > approach, for speed and also more deterministic memory usage in many
< > common scenarios.

what about C ?


" The Boehm-Demers-Weiser conservative garbage collector can be used as
a garbage collecting replacement for C malloc or C++ new. It allows you
to allocate memory basically as you normally would, without explicitly
deallocating memory that is no longer useful. The collector
automatically recycles memory when it determines that it can no longer
be otherwise accessed. A simple example of such a use is given here."

> I don't think any of Common Lisp, Java, Perl or Python promise to employ
> any particular algorithm for collecting garbage.  It's not something you
> really need to put in your language specification document.  All you
> need to say is that storage management is not something the programmer
> needs to worry about.  Nothing prevents you from implementing a Common
> Lisp that does reference counting.

you must be a newbie.

> It seems to be fashionable these days to consider reference counting to
> be somehow different from garbage collection, but historically reference
> counting was just another tool used for garbage collection.  At least
> one of the InterLisp implementations used reference counting as part of
> its garbage collector, and nobody thought that it had less of a true
> garbage collector as a result.

Hmmm.

Seriously, my once a month statement is to read Baker:

"Henry Givens Baker Jr. is an American computer scientist who has made
contributions in garbage collection, functional programming languages,
and linear logic. He was one of the founders of Symbolics, a company
that designed and manufactured a line of Lisp machines. In 2006, he was
recognized as an ACM Distinguished Member."

He is notable for his research in garbage collection, particularly
Baker's real-time copying collector, and on the Actor model.

Baker received his B.Sc. (1969), S.M. (1973), E.E. (1973), and Ph.D.
(1978) degrees at M.I.T.
"

just google for 
Henry baker +lisp +GC

 .

When I program in C I do not use GC, I use exit.

[toc] | [prev] | [next] | [standalone]

#60849

On Wed, 10 Jun 2026 12:24:51 -0400, steve g <sgonedes1977@gmail.com>
wrote:


>
>Seriously, my once a month statement is to read Baker:
>
>"Henry Givens Baker Jr. is an American computer scientist who has made
>contributions in garbage collection, functional programming languages,
>and linear logic. He was one of the founders of Symbolics, a company
>that designed and manufactured a line of Lisp machines. In 2006, he was
>recognized as an ACM Distinguished Member."
>
>He is notable for his research in garbage collection, particularly
>Baker's real-time copying collector, and on the Actor model.
>
>Baker received his B.Sc. (1969), S.M. (1973), E.E. (1973), and Ph.D.
>(1978) degrees at M.I.T.
>"
>
>just google for 
>Henry baker +lisp +GC

Baker advocated what is generally known as the "full black" barrier in
terms of the tri-color abstraction.  

Baker felt that the mutator (ie. the program) should only ever see
black data - never white or gray - and most of his systems employed
black allocation and rather heavy handed read barriers to guarantee
it.

The problem is that black data always will be retained through the
next collection, and studies have shown that - at least for Lispy and
FP languages - a large percentage of new allocations will die before
the next collection starts.  Baker's systems don't permit the memory
to be reclaimed until (at least) the 2nd GC cycle following its
allocation.


So while I agree that Baker is excellent reading for GC theory, his
implementation proposals should be taken with a dose of salt as many
of them are not terribly efficient in practice.

[toc] | [prev] | [next] | [standalone]

#60838

> Lisp is purely garbage-collected though, isn’t it?

Most languages (Lisp included) don't specify how and when unreachable
objects are collected, as others pointed out.  Actually, most languages
don't even specify what counts as "unreachable" (Scheme being one of
the exceptions).

> Languages like Perl and Python try for a hybrid
> reference-counted/garbage-collected approach, for speed and also more
> deterministic memory usage in many common scenarios.

Probably not "for speed": it takes a significant amount of work to make
a reference-counting system that's competitive (speedwise) with
a tracing GC, because there tend to be *many* refcount updates (and it
gets worse if you support concurrency, where most of those updates
need to be made atomic).


=== Stefan

[toc] | [prev] | [next] | [standalone]

#60839

On Tue, 09 Jun 2026 09:36:50 -0400, Stefan Monnier wrote:

> On Tue, 9 Jun 2026 00:33:44 -0000 (UTC), Lawrence D’Oliveiro wrote:
>>
>> Languages like Perl and Python try for a hybrid
>> reference-counted/garbage-collected approach, for speed and also
>> more deterministic memory usage in many common scenarios.
>
> Probably not "for speed": it takes a significant amount of work to
> make a reference-counting system that's competitive (speedwise) with
> a tracing GC, because there tend to be *many* refcount updates (and
> it gets worse if you support concurrency, where most of those
> updates need to be made atomic).

But those refcount updates are on live objects, which means they are
more likely to reside in some level of CPU cache.

Whereas a garbage collector, by design, is spending much of its time
hitting long-dead objects, which would likely have long since
disappeared from the cache. That’s going to add an order of magnitude
or two to your execution time -- which is why we have caches in the
first place.

[toc] | [prev] | [next] | [standalone]

#60845

>> Probably not "for speed": it takes a significant amount of work to
>> make a reference-counting system that's competitive (speedwise) with
>> a tracing GC, because there tend to be *many* refcount updates (and
>> it gets worse if you support concurrency, where most of those
>> updates need to be made atomic).
>
> But those refcount updates are on live objects, which means they are
> more likely to reside in some level of CPU cache.
>
> Whereas a garbage collector, by design, is spending much of its time
> hitting long-dead objects, which would likely have long since
> disappeared from the cache. That’s going to add an order of magnitude
> or two to your execution time -- which is why we have caches in the
> first place.

AFAIK, real-life usually disagrees with your analysis, which is why
refcount is rarely used in practice for implementations of languages
with automatic memory management.


=== Stefan

[toc] | [prev] | [next] | [standalone]

#60846

On Tue, 09 Jun 2026 09:36:50 -0400, Stefan Monnier wrote:

> On Wed, 10 Jun 2026 00:06:17 -0000 (UTC), Lawrence D’Oliveiro wrote:
>>
>> On Tue, 09 Jun 2026 09:36:50 -0400, Stefan Monnier wrote:
>>
>>> Probably not "for speed": it takes a significant amount of work to
>>> make a reference-counting system that's competitive (speedwise)
>>> with a tracing GC, because there tend to be *many* refcount
>>> updates (and it gets worse if you support concurrency, where most
>>> of those updates need to be made atomic).
>>
>> But those refcount updates are on live objects, which means they
>> are more likely to reside in some level of CPU cache.
>>
>> Whereas a garbage collector, by design, is spending much of its
>> time hitting long-dead objects, which would likely have long since
>> disappeared from the cache. That’s going to add an order of
>> magnitude or two to your execution time -- which is why we have
>> caches in the first place.
>
> AFAIK, real-life usually disagrees with your analysis, which is why
> refcount is rarely used in practice for implementations of languages
> with automatic memory management.

Feel free to show any performance measures that back up your claim --
particularly memory usage. I would say the only reason the Python
approach hasn’t been done before now is because it’s hard to do --
pure brute-force GC has always simply been the path of least
resistance.

[toc] | [prev] | [next] | [standalone]

#60854

Lawrence D’Oliveiro [2026-06-11 00:22:36] wrote:
> On Tue, 09 Jun 2026 09:36:50 -0400, Stefan Monnier wrote:
>> On Wed, 10 Jun 2026 00:06:17 -0000 (UTC), Lawrence D’Oliveiro wrote:
>>> On Tue, 09 Jun 2026 09:36:50 -0400, Stefan Monnier wrote:
>>>> Probably not "for speed": it takes a significant amount of work to
>>>> make a reference-counting system that's competitive (speedwise)
>>>> with a tracing GC, because there tend to be *many* refcount
>>>> updates (and it gets worse if you support concurrency, where most
>>>> of those updates need to be made atomic).
>>>
>>> But those refcount updates are on live objects, which means they
>>> are more likely to reside in some level of CPU cache.
>>>
>>> Whereas a garbage collector, by design, is spending much of its
>>> time hitting long-dead objects, which would likely have long since
>>> disappeared from the cache. That’s going to add an order of
>>> magnitude or two to your execution time -- which is why we have
>>> caches in the first place.
>>
>> AFAIK, real-life usually disagrees with your analysis, which is why
>> refcount is rarely used in practice for implementations of languages
>> with automatic memory management.
>
> Feel free to show any performance measures that back up your claim --
> particularly memory usage.

How could memory usage measures back up my claim, which is about speed?


=== Stefan

[toc] | [prev] | [next] | [standalone]

#60850

On Wed, 10 Jun 2026 00:06:17 -0000 (UTC), Lawrence D´Oliveiro
<ldo@nz.invalid> wrote:

>On Tue, 09 Jun 2026 09:36:50 -0400, Stefan Monnier wrote:
>
>> On Tue, 9 Jun 2026 00:33:44 -0000 (UTC), Lawrence D’Oliveiro wrote:
>>>
>>> Languages like Perl and Python try for a hybrid
>>> reference-counted/garbage-collected approach, for speed and also
>>> more deterministic memory usage in many common scenarios.
>>
>> Probably not "for speed": it takes a significant amount of work to
>> make a reference-counting system that's competitive (speedwise) with
>> a tracing GC, because there tend to be *many* refcount updates (and
>> it gets worse if you support concurrency, where most of those
>> updates need to be made atomic).
>
>But those refcount updates are on live objects, which means they are
>more likely to reside in some level of CPU cache.

Depends. Often with reference counting systems linked structures -
lists and trees - are just stuck on the relevant[*] free list and are
not deconstructed until/unless the nodes are needed for new
allocations.  By that time they are no longer in cache.

[*] many systems use list based allocators that are designed to
provide fixed sized blocks for some number of commonly used sizes,
backed by a general best fit allocator if nothing else fits. E.g., if
you ask for 96 bytes, you may get a 128 byte block.


>Whereas a garbage collector, by design, is spending much of its time
>hitting long-dead objects, which would likely have long since
>disappeared from the cache.

That depends on the type of GC. 

Mark-sweep collectors must make (at least) one pass over the entire
heap to locate and recycle dead objects. They touch every heap object
once and live objects twice.

However mark-compact and semispace copying collectors touch only live
objects (and touch them only once).  In these systems dead objects are
simply abandoned and their memory is reclaimed by being overwritten in
subsequent allocations.


>That’s going to add an order of magnitude or two to your execution
>time -- which is why we have caches in the first place.

Sweeping is a sequential walk through the heap - the access pattern is
highly predictable (to the CPU) and quite fast ... which is why
mark-sweep systems still are used.  Marking live data often takes much
longer because it jumps around.  

Copying is similar to marking in that it jumps around, but copying
eliminates the need to sweep afterward.

[toc] | [prev] | [next] | [standalone]

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

Back to top | Article view | comp.lang.lisp

csiph-web