Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.lisp > #60742 > unrolled thread
| Started by | Mario Rosell <mario@mariorosell.es> |
|---|---|
| First post | 2026-02-20 22:53 +0100 |
| Last post | 2026-06-03 03:16 +0000 |
| Articles | 20 on this page of 159 — 20 participants |
Back to article view | Back to comp.lang.lisp
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? steve g <Sgonedes1977@gmail.com> - 2026-06-17 00:01 -0400
Re: Resources to learn common lisp? Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-17 05:53 +0000
[OT] Disappearing documentation (was: Re: Resources to learn common lisp?) Nuno Silva <nunojsilva@invalid.invalid> - 2026-06-17 09:06 +0100
Re: Resources to learn common lisp? tfb <no_email@invalid.invalid> - 2026-06-11 17:22 +0000
Re: Resources to learn common lisp? Paul Rubin <no.email@nospam.invalid> - 2026-06-13 13:59 -0700
Re: Resources to learn common lisp? Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-14 00:55 +0000
Re: Resources to learn common lisp? Paul Rubin <no.email@nospam.invalid> - 2026-06-14 01:43 -0700
Re: Resources to learn common lisp? Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-14 05:45 +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? steve g <Sgonedes1977@gmail.com> - 2026-06-16 22:10 -0400
Re: Resources to learn common lisp? Paul Rubin <no.email@nospam.invalid> - 2026-06-16 21:37 -0700
Re: Resources to learn common lisp? Joerg Mertens <joerg-mertens@t-online.de> - 2026-06-17 12:04 +0200
Re: Resources to learn common lisp? ram@zedat.fu-berlin.de (Stefan Ram) - 2026-06-17 11:17 +0000
Re: Resources to learn common lisp? tfb <no_email@invalid.invalid> - 2026-06-17 13:57 +0000
Re: Resources to learn common lisp? Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-18 01:06 +0000
Re: Resources to learn common lisp? tfb <no_email@invalid.invalid> - 2026-06-18 09:17 +0000
Re: Resources to learn common lisp? antispam@fricas.org (Waldek Hebisch) - 2026-06-18 13:32 +0000
Re: Resources to learn common lisp? Paul Rubin <no.email@nospam.invalid> - 2026-06-18 14:21 -0700
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-16 22:12 -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? Alan Bawden <alan@csail.mit.edu> - 2026-06-11 21:07 -0400
Re: Resources to learn common lisp? tfb <no_email@invalid.invalid> - 2026-06-12 13:06 +0000
Re: Resources to learn common lisp? Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-13 00:13 +0000
Re: Resources to learn common lisp? tfb <no_email@invalid.invalid> - 2026-06-13 07:25 +0000
Re: Resources to learn common lisp? Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-13 08:25 +0000
Re: Resources to learn common lisp? tfb <no_email@invalid.invalid> - 2026-06-13 08:46 +0000
Re: Resources to learn common lisp? tfb <no_email@invalid.invalid> - 2026-06-13 08:52 +0000
Re: Resources to learn common lisp? Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-14 05:57 +0000
Re: Resources to learn common lisp? Nuno Silva <nunojsilva@invalid.invalid> - 2026-06-15 10:10 +0100
Re: Resources to learn common lisp? Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-14 05:56 +0000
Re: Resources to learn common lisp? tfb <no_email@invalid.invalid> - 2026-06-16 11:46 +0000
Re: Resources to learn common lisp? Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-18 01:03 +0000
Re: Resources to learn common lisp? tfb <no_email@invalid.invalid> - 2026-06-18 07:52 +0000
Re: Resources to learn common lisp? steve g <Sgonedes1977@gmail.com> - 2026-06-16 20:56 -0400
Re: Resources to learn common lisp? Alan Bawden <alan@csail.mit.edu> - 2026-06-13 00:55 -0400
Re: Resources to learn common lisp? tfb <no_email@invalid.invalid> - 2026-06-13 07:43 +0000
Re: Resources to learn common lisp? steve g <Sgonedes1977@gmail.com> - 2026-06-16 21:37 -0400
Re: Resources to learn common lisp? Paul Rubin <no.email@nospam.invalid> - 2026-06-13 13:09 -0700
Re: Resources to learn common lisp? Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-14 01:02 +0000
Re: Resources to learn common lisp? tfb <no_email@invalid.invalid> - 2026-06-16 10:12 +0000
Re: Resources to learn common lisp? steve g <Sgonedes1977@gmail.com> - 2026-06-16 22:54 -0400
Re: Resources to learn common lisp? Alan Bawden <alan@csail.mit.edu> - 2026-06-17 00:07 -0400
Re: Resources to learn common lisp? tfb <no_email@invalid.invalid> - 2026-06-17 08:33 +0000
Re: Resources to learn common lisp? tfb <no_email@invalid.invalid> - 2026-06-12 12:42 +0000
Re: Resources to learn common lisp? steve g <Sgonedes1977@gmail.com> - 2026-06-16 23:32 -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? Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-12 00:16 +0000
Re: Resources to learn common lisp? steve g <Sgonedes1977@gmail.com> - 2026-06-16 21:42 -0400
Re: Resources to learn common lisp? antispam@fricas.org (Waldek Hebisch) - 2026-06-15 01:15 +0000
Re: Resources to learn common lisp? Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-15 05:42 +0000
Re: Resources to learn common lisp? antispam@fricas.org (Waldek Hebisch) - 2026-06-15 11:19 +0000
Re: Resources to learn common lisp? Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-16 00:18 +0000
Re: Resources to learn common lisp? antispam@fricas.org (Waldek Hebisch) - 2026-06-16 03:27 +0000
Re: Resources to learn common lisp? Paul Rubin <no.email@nospam.invalid> - 2026-06-16 01:25 -0700
Re: Resources to learn common lisp? tfb <no_email@invalid.invalid> - 2026-06-17 10:13 +0000
Re: Resources to learn common lisp? antispam@fricas.org (Waldek Hebisch) - 2026-06-18 13:57 +0000
Re: Resources to learn common lisp? Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-18 01:11 +0000
Re: Resources to learn common lisp? Paul Rubin <no.email@nospam.invalid> - 2026-06-18 02:30 -0700
Re: Resources to learn common lisp? tfb <no_email@invalid.invalid> - 2026-06-18 09:32 +0000
Re: Resources to learn common lisp? antispam@fricas.org (Waldek Hebisch) - 2026-06-18 14:15 +0000
Re: Resources to learn common lisp? steve g <Sgonedes1977@gmail.com> - 2026-06-16 23:53 -0400
Re: Resources to learn common lisp? Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-17 05:55 +0000
Re: Resources to learn common lisp? Paul Rubin <no.email@nospam.invalid> - 2026-06-17 01:43 -0700
Re: Resources to learn common lisp? Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-18 01:07 +0000
Re: Resources to learn common lisp? George Neuner <gneuner2@comcast.net> - 2026-06-11 06:37 -0400
Re: Resources to learn common lisp? Paul Rubin <no.email@nospam.invalid> - 2026-06-13 13:30 -0700
Re: Resources to learn common lisp? Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-14 00:58 +0000
Re: Resources to learn common lisp? Paul Rubin <no.email@nospam.invalid> - 2026-06-14 01:46 -0700
Re: Resources to learn common lisp? George Neuner <gneuner2@comcast.net> - 2026-06-15 06:59 -0400
Re: Resources to learn common lisp? Paul Rubin <no.email@nospam.invalid> - 2026-06-15 12:25 -0700
Re: Resources to learn common lisp? tfb <no_email@invalid.invalid> - 2026-06-11 17:42 +0000
Re: Resources to learn common lisp? Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-12 00:16 +0000
Re: Resources to learn common lisp? tfb <no_email@invalid.invalid> - 2026-06-12 12:34 +0000
Re: Resources to learn common lisp? Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-13 00:11 +0000
Re: Resources to learn common lisp? George Neuner <gneuner2@comcast.net> - 2026-06-13 04:06 -0400
Re: Resources to learn common lisp? Paul Rubin <no.email@nospam.invalid> - 2026-06-13 13:37 -0700
Re: Resources to learn common lisp? ram@zedat.fu-berlin.de (Stefan Ram) - 2026-06-13 21:25 +0000
Re: Resources to learn common lisp? Paul Rubin <no.email@nospam.invalid> - 2026-06-13 15:26 -0700
Re: Resources to learn common lisp? Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-14 05:37 +0000
Re: Resources to learn common lisp? antispam@fricas.org (Waldek Hebisch) - 2026-06-15 01:34 +0000
Re: Resources to learn common lisp? Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-15 05:43 +0000
Re: Resources to learn common lisp? antispam@fricas.org (Waldek Hebisch) - 2026-06-15 11:23 +0000
Re: Resources to learn common lisp? Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-16 00:23 +0000
Re: Resources to learn common lisp? antispam@fricas.org (Waldek Hebisch) - 2026-06-16 03:29 +0000
Re: Resources to learn common lisp? Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-16 04:59 +0000
Re: Resources to learn common lisp? Paul Rubin <no.email@nospam.invalid> - 2026-06-16 15:10 -0700
Re: Resources to learn common lisp? tfb <no_email@invalid.invalid> - 2026-06-16 13:34 +0000
Re: Resources to learn common lisp? tfb <no_email@invalid.invalid> - 2026-06-13 08:36 +0000
Re: Resources to learn common lisp? Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-14 01:43 +0000
Re: Resources to learn common lisp? Stefan Monnier <monnier@iro.umontreal.ca> - 2026-06-14 10:36 -0400
Re: Resources to learn common lisp? Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-14 23:55 +0000
Re: Resources to learn common lisp? Paul Rubin <no.email@nospam.invalid> - 2026-06-14 18:04 -0700
Re: Resources to learn common lisp? tfb <no_email@invalid.invalid> - 2026-06-16 12:33 +0000
Re: Resources to learn common lisp? Stefan Monnier <monnier@iro.umontreal.ca> - 2026-06-15 09:51 -0400
Re: Resources to learn common lisp? Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-16 00:23 +0000
Re: Resources to learn common lisp? Paul Rubin <no.email@nospam.invalid> - 2026-06-16 03:14 -0700
Re: Resources to learn common lisp? Paul Rubin <no.email@nospam.invalid> - 2026-06-16 15:29 -0700
Re: Resources to learn common lisp? Stefan Monnier <monnier@iro.umontreal.ca> - 2026-06-16 10:23 -0400
Re: Resources to learn common lisp? Paul Rubin <no.email@nospam.invalid> - 2026-06-16 21:34 -0700
Re: Resources to learn common lisp? Stefan Monnier <monnier@iro.umontreal.ca> - 2026-06-17 15:02 -0400
Re: Resources to learn common lisp? Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-18 04:14 +0000
Re: Resources to learn common lisp? Paul Rubin <no.email@nospam.invalid> - 2026-06-14 13:14 -0700
Re: Resources to learn common lisp? Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-18 02:30 +0000
Re: Resources to learn common lisp? tfb <no_email@invalid.invalid> - 2026-06-16 11:46 +0000
Re: Resources to learn common lisp? antispam@fricas.org (Waldek Hebisch) - 2026-06-18 15:34 +0000
Re: Resources to learn common lisp? Paul Rubin <no.email@nospam.invalid> - 2026-06-13 13:22 -0700
Re: Resources to learn common lisp? Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-14 01:55 +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? steve g <Sgonedes1977@gmail.com> - 2026-06-16 21:59 -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 5 of 8 — ← Prev page 1 2 3 4 [5] 6 7 8 Next page →
| From | Stefan Monnier <monnier@iro.umontreal.ca> |
|---|---|
| Date | 2026-06-11 08:57 -0400 |
| Message-ID | <jwvjys5teuy.fsf-monnier+comp.lang.lisp@gnu.org> |
| In reply to | #60846 |
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]
| From | Lawrence D’Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2026-06-12 00:16 +0000 |
| Message-ID | <110fj5r$1r13s$6@dont-email.me> |
| In reply to | #60854 |
On Thu, 11 Jun 2026 08:57:35 -0400, Stefan Monnier wrote: > Lawrence D’Oliveiro [2026-06-11 00:22:36] wrote: >> >> 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? Yeah, too bad.
[toc] | [prev] | [next] | [standalone]
| From | steve g <Sgonedes1977@gmail.com> |
|---|---|
| Date | 2026-06-16 21:42 -0400 |
| Message-ID | <87mrwuq6w5.fsf@gmail.com> |
| In reply to | #60854 |
Stefan Monnier <monnier@iro.umontreal.ca> writes: > How could memory usage measures back up my claim, which is about speed? What types of amphetamine where they giving you? (I am being an asshole). > > > === Stefan
[toc] | [prev] | [next] | [standalone]
| From | antispam@fricas.org (Waldek Hebisch) |
|---|---|
| Date | 2026-06-15 01:15 +0000 |
| Message-ID | <110njmu$2810q$1@paganini.bofh.team> |
| In reply to | #60846 |
Lawrence D’Oliveiro <ldo@nz.invalid> 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. 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.
On equvalent programs built from low-level operations 'sbcl'
routinely gets _much_ better performance than Python. 'sbcl'
has nice profiler which (among other) indicates how much time
is spent in garbage collector. Usually garbage collection
has modest impact on execution speed (say about 10-30%).
Of course, if program is consing like crazy, then cost of
garbage collection will grow. But if you try reference counting
you will spent even more time.
For Python cost of reference counting does not matter too much
simply because cost of interpretation is too big. To get good
speed in Python you want to pass work to C/C++ code which is
is not going to do either GC or reference counting.
Concerning least resistance: in languages like Perl or Python
vast majority of data structures is (or was) noncyclic. In
such case reference counting is easy to implement.
--
Waldek Hebisch
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D’Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2026-06-15 05:42 +0000 |
| Message-ID | <110o3cs$4okg$1@dont-email.me> |
| In reply to | #60899 |
On Mon, 15 Jun 2026 01:15:12 -0000 (UTC), Waldek Hebisch wrote: > On equvalent programs built from low-level operations 'sbcl' > routinely gets _much_ better performance than Python. Is this with similar memory consumption?
[toc] | [prev] | [next] | [standalone]
| From | antispam@fricas.org (Waldek Hebisch) |
|---|---|
| Date | 2026-06-15 11:19 +0000 |
| Message-ID | <110on3c$2gi2l$1@paganini.bofh.team> |
| In reply to | #60901 |
Lawrence D’Oliveiro <ldo@nz.invalid> wrote:
> On Mon, 15 Jun 2026 01:15:12 -0000 (UTC), Waldek Hebisch wrote:
>
>> On equvalent programs built from low-level operations 'sbcl'
>> routinely gets _much_ better performance than Python.
>
> Is this with similar memory consumption?
It is hard to compare and too many things differ. All other
things being equal I would expect reference counting to have
lower memory use. GC similar to used in sbcl at peak needs
about 3-4 times more memory than amount of live data.
Reference counting needs space for counts (50% increase of
size for typical cons cell) and in non-moving variant looses
some space do to fragmentation. Fragmentation in worst case
may be quite significant, but usually is moderarte.
--
Waldek Hebisch
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D’Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2026-06-16 00:18 +0000 |
| Message-ID | <110q4nu$o45a$6@dont-email.me> |
| In reply to | #60907 |
On Mon, 15 Jun 2026 11:19:10 -0000 (UTC), Waldek Hebisch wrote: > Lawrence D’Oliveiro <ldo@nz.invalid> wrote: >> >> On Mon, 15 Jun 2026 01:15:12 -0000 (UTC), Waldek Hebisch wrote: >> >>> On equvalent programs built from low-level operations 'sbcl' >>> routinely gets _much_ better performance than Python. >> >> Is this with similar memory consumption? > > It is hard to compare and too many things differ. But you were not so reticent above about claiming “routinely gets _much_ better performance”, were you? > All other things being equal I would expect reference counting to > have lower memory use. GC similar to used in sbcl at peak needs > about 3-4 times more memory than amount of live data. Reference > counting needs space for counts (50% increase of size for typical > cons cell) and in non-moving variant looses some space do to > fragmentation. Fragmentation in worst case may be quite significant, > but usually is moderarte. Given that languages like Python have much higher-level data structures than simple cons cells, and also encourage you to use them, the extra space overhead in practice is minimal. Also don’t forget the gain from not having all those “CDR” fields that make you do pointer-chasing all the time.
[toc] | [prev] | [next] | [standalone]
| From | antispam@fricas.org (Waldek Hebisch) |
|---|---|
| Date | 2026-06-16 03:27 +0000 |
| Message-ID | <110qfq5$2q2b6$1@paganini.bofh.team> |
| In reply to | #60912 |
Lawrence D’Oliveiro <ldo@nz.invalid> wrote:
> On Mon, 15 Jun 2026 11:19:10 -0000 (UTC), Waldek Hebisch wrote:
>
>> Lawrence D’Oliveiro <ldo@nz.invalid> wrote:
>>>
>>> On Mon, 15 Jun 2026 01:15:12 -0000 (UTC), Waldek Hebisch wrote:
>>>
>>>> On equvalent programs built from low-level operations 'sbcl'
>>>> routinely gets _much_ better performance than Python.
>>>
>>> Is this with similar memory consumption?
>>
>> It is hard to compare and too many things differ.
>
> But you were not so reticent above about claiming “routinely gets
> _much_ better performance”, were you?
I have a lot of data about runtime and by "preformance" I mean
runtime. I have rather sparse data about memory use (especially
about Python memory use).
And in case you missed it: limited percentage of time spent in
sbcl GC is not due to slowness of other code. In fact the
opposite is true: since other code is fast pressure on garbage
collector is bigger.
>> All other things being equal I would expect reference counting to
>> have lower memory use. GC similar to used in sbcl at peak needs
>> about 3-4 times more memory than amount of live data. Reference
>> counting needs space for counts (50% increase of size for typical
>> cons cell) and in non-moving variant looses some space do to
>> fragmentation. Fragmentation in worst case may be quite significant,
>> but usually is moderarte.
>
> Given that languages like Python have much higher-level data
> structures than simple cons cells, and also encourage you to use them,
> the extra space overhead in practice is minimal. Also don’t forget the
> gain from not having all those “CDR” fields that make you do
> pointer-chasing all the time.
That "higher-level data structures" is part of complication.
I did not look at Python internal data structures, but
I looked at Perl data structures, and when I looked at them
they were extremaly wasteful. 'sbcl' data structures are
not super-efficient, but not bad.
Have you looked at space needed by say binary tree in Python
(I did not)? Node can be represented as a struct which
AFAICS in sbcl need 3 machine words. Alternatively one
can use a vector (also 3 machine words) or two cons cells
(4 machine words).
--
Waldek Hebisch
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2026-06-16 01:25 -0700 |
| Message-ID | <87eci66gea.fsf@nightsong.com> |
| In reply to | #60915 |
antispam@fricas.org (Waldek Hebisch) writes: > Have you looked at space needed by say binary tree in Python Python likes to use arrays and dictionaries for almost everything. Those are implemented in C and optimized pretty well, though mostly for speed. Integers are boxed and while (iirc) -1 through 100 are preallocated, the rest get consed as needed and reclaimed later. Of course in the olden days there were very compact Lisp representations like BIBOP (Big Bag of Pages) for memory-starved machines. So you'd have a page full of cons cells, a page full of symbols, etc. That way you didn't need type tags: the address would tell you what the type was. These days the heap size of a running program usually isn't that important, for reasons I described earlier. The computer's memory is full of stuff like video frames and the program heap coexists with that.
[toc] | [prev] | [next] | [standalone]
| From | tfb <no_email@invalid.invalid> |
|---|---|
| Date | 2026-06-17 10:13 +0000 |
| Message-ID | <110ts0m$1pbiu$1@dont-email.me> |
| In reply to | #60915 |
gWaldek Hebisch <antispam@fricas.org> wrote:
>
> Have you looked at space needed by say binary tree in Python
> (I did not)? Node can be represented as a struct which
> AFAICS in sbcl need 3 machine words. Alternatively one
> can use a vector (also 3 machine words) or two cons cells
> (4 machine words).
>
On a 64-bit machine a structure generally takes (+ 2 (* 2 (ceiling n 2)))
words in SBCL: I think this is a word of type, a word saying how many slots
there are and a word for each slot, but allocation is on doubleword
boundaries. It's possible that structures with type declarations for good,
immediate, might be smaller. I don't actually know how the two-word header
is layed out.
Since there seems to be some claim (not by you) that GC is only good
because 'Lisp only has conses' here's some code which doesn't. This is
portable CL other than ITERATE, which is named-let. It constructs chains
of structures which links both in a slot, and via an array in another slot
and entries in a hash table in a third:
(defstruct funge
(a (make-array 10))
(h (make-hash-table))
(l nil))
(defun funge (&optional link)
(let ((f (make-funge :l link)))
(when link
(let ((a (funge-a f))
(h (funge-h f)))
(declare (type simple-vector a)
(type hash-table h))
(dotimes (i (length a))
(setf (svref a i) link
(gethash i h) link))))
f))
(defun funge-length (f)
;; How long is a chain
(iterate fl ((f f)
(l 1))
(let ((p (funge-l f)))
(if (not p)
l
(fl p (1+ l))))))
(defun funger (n m)
;; Make n funges in chains of length m
(declare (type fixnum n m))
(iterate next ((i 0)
(c (funge)))
(if (>= i n)
(values c n i)
(next (1+ i) (if (zerop (mod i m)) (funge) (funge c))))))
Now, FUNGER will create n objects, in chains of length m (so only m objects
are ever live at once).
So:
? (extended-time (funge-length (funger 100000000 100)))
Timing the evaluation of (progn (funge-length (funger 100000000 100)))
User time = 33.101
System time = 0.170
Elapsed time = 33.278
Allocation = 94880000632 bytes
71434 Page faults
total / user / system
total gc activity = 0.751353 / 0.614433 / 0.136920
Standard 0 (23994 calls) = 0.720840 / 0.609975 / 0.110865
Standard 1 ( 138 calls) = 0.030513 / 0.004458 / 0.026055
100
This has allocated a total of just shy of 95GB, with about 2% GC overhead.
If you tweak m in the calls, you can see how GC cost depends on the amount
of live data.
--
tfeb.org/computer/
[toc] | [prev] | [next] | [standalone]
| From | antispam@fricas.org (Waldek Hebisch) |
|---|---|
| Date | 2026-06-18 13:57 +0000 |
| Message-ID | <1110th2$3jmcm$2@paganini.bofh.team> |
| In reply to | #60950 |
tfb <no_email@invalid.invalid> wrote:
> gWaldek Hebisch <antispam@fricas.org> wrote:
>>
>> Have you looked at space needed by say binary tree in Python
>> (I did not)? Node can be represented as a struct which
>> AFAICS in sbcl need 3 machine words. Alternatively one
>> can use a vector (also 3 machine words) or two cons cells
>> (4 machine words).
>>
>
> On a 64-bit machine a structure generally takes (+ 2 (* 2 (ceiling n 2)))
> words in SBCL: I think this is a word of type, a word saying how many slots
> there are and a word for each slot, but allocation is on doubleword
> boundaries. It's possible that structures with type declarations for good,
> immediate, might be smaller. I don't actually know how the two-word header
> is layed out.
You seem to be confused here. Yes, I forgot to say that on 64-bit
machine sbcl allocations are on 16 byte boundary, so there will be word
lost due to fragmentation if the size is odd. But inside things
are at word boundaries. For vectors AFAIK sbcl combines size with tag
into a single word, so 1 word for header is enough. I think that
similar thing is done for structs.
--
Waldek Hebisch
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D’Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2026-06-18 01:11 +0000 |
| Message-ID | <110vgkb$292a0$4@dont-email.me> |
| In reply to | #60915 |
On Tue, 16 Jun 2026 03:27:03 -0000 (UTC), Waldek Hebisch wrote: > And in case you missed it: limited percentage of time spent in sbcl > GC is not due to slowness of other code. In fact the opposite is > true: since other code is fast pressure on garbage collector is > bigger. Which reminds me: CPU time consumed by the garbage collector has to count towards program execution CPU time, too. > That "higher-level data structures" is part of complication. I did > not look at Python internal data structures, but I looked at Perl > data structures, and when I looked at them they were extremaly > wasteful. 'sbcl' data structures are not super-efficient, but not > bad. Look at toolkits like NumPy, commonly used to do heavy-duty computations on large amounts of data (e.g. millions of data points) from Python. Yes, the bulk of it is written in compiled languages (C? Fortran?) for speed. But remember, it is accepting the input data as Python objects, and returning results as Python objects. So you see, the performance bottleneck does not lie in Python’s memory management system.
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2026-06-18 02:30 -0700 |
| Message-ID | <87fr2k42my.fsf@nightsong.com> |
| In reply to | #60958 |
Lawrence D’Oliveiro <ldo@nz.invalid> writes: > Look at toolkits like NumPy, commonly used to do heavy-duty... > So you see, the performance bottleneck does not lie in Python’s memory > management system. Exactly, those large numeric arrays don't contain any pointers that need management at finer granularity than the array itself. What are you on about, anyway? Python had the GIL for decades. Finally the lack of parallelism became intolerable, so the GIL has been removed through painful contortions (each object has two reference counts instead of one, increasing memory bloat even more). At the end though, despite recent speedups, CPython is quite slow and its storage reclamation strategy doesn't matter that much to its performance. It does make extensions and maintenance more of a hassle.
[toc] | [prev] | [next] | [standalone]
| From | tfb <no_email@invalid.invalid> |
|---|---|
| Date | 2026-06-18 09:32 +0000 |
| Message-ID | <1110dus$2geib$1@dont-email.me> |
| In reply to | #60958 |
Lawrence D´Oliveiro <ldo@nz.invalid> wrote: > > > Which reminds me: CPU time consumed by the garbage collector has to > count towards program execution CPU time, too. > Do you think people don't do that? ? (bench 100000000 100) Timing the evaluation of (timing nil (funger n m)) User time = 0:01:19.957 System time = 0.681 Elapsed time = 0:01:20.620 Allocation = 94893571384 bytes 72064 Page faults GC time = 1.355 80.62 94GB total allocation (almost none of which was conses), all freed by the GC, 80s total runtime of which under 2% was GC overhead. Under 2%. I could probably make this program faster by fiddling with the loops. Fiddling with the GC parameters (it is using the default settings) could gain me no more than 2%. -- tfeb.org/computer/
[toc] | [prev] | [next] | [standalone]
| From | antispam@fricas.org (Waldek Hebisch) |
|---|---|
| Date | 2026-06-18 14:15 +0000 |
| Message-ID | <1110uhe$3jmcm$3@paganini.bofh.team> |
| In reply to | #60958 |
Lawrence D’Oliveiro <ldo@nz.invalid> wrote:
> On Tue, 16 Jun 2026 03:27:03 -0000 (UTC), Waldek Hebisch wrote:
>
>> And in case you missed it: limited percentage of time spent in sbcl
>> GC is not due to slowness of other code. In fact the opposite is
>> true: since other code is fast pressure on garbage collector is
>> bigger.
>
> Which reminds me: CPU time consumed by the garbage collector has to
> count towards program execution CPU time, too.
Yes, it counts.
>> That "higher-level data structures" is part of complication. I did
>> not look at Python internal data structures, but I looked at Perl
>> data structures, and when I looked at them they were extremaly
>> wasteful. 'sbcl' data structures are not super-efficient, but not
>> bad.
>
> Look at toolkits like NumPy, commonly used to do heavy-duty
> computations on large amounts of data (e.g. millions of data points)
> from Python.
>
> Yes, the bulk of it is written in compiled languages (C? Fortran?) for
> speed. But remember, it is accepting the input data as Python objects,
> and returning results as Python objects.
>
> So you see, the performance bottleneck does not lie in Python’s memory
> management system.
If you do heavy computations with largish data objects, then
memory management is usually not a problem, regardless of language.
And if code that you need is already written in say C and wrapped in
Python, then Python has obvious advantage. The point is that
sometimes you need to write code including low level parts.
In many situations that leads to a lot of smallish pieces of
data that need to be handled efficiently. Many folks in such
case say "use bigger computer", but it is nice to have a language
which is significantly higher level than C but gives comparable
performance. Lisp is not exactly there, but not far: rather
typical figure for sbcl is half of speed of comparable C. It is
worse when dealing with multidimensional arrays or if C compiler
manages to usefuly autovectorize the code. OTOH memory access
time may effectively decrease differences.
--
Waldek Hebisch
[toc] | [prev] | [next] | [standalone]
| From | steve g <Sgonedes1977@gmail.com> |
|---|---|
| Date | 2026-06-16 23:53 -0400 |
| Message-ID | <87jyrxq0v0.fsf@gmail.com> |
| In reply to | #60901 |
Lawrence D’Oliveiro <ldo@nz.invalid> writes: > On Mon, 15 Jun 2026 01:15:12 -0000 (UTC), Waldek Hebisch wrote: > >> On equvalent programs built from low-level operations 'sbcl' >> routinely gets _much_ better performance than Python. > > Is this with similar memory consumption? sbcl has a new generation GC.
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D’Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2026-06-17 05:55 +0000 |
| Message-ID | <110tcta$1l264$3@dont-email.me> |
| In reply to | #60938 |
On Tue, 16 Jun 2026 23:53:07 -0400, steve g wrote: > Lawrence D’Oliveiro <ldo@nz.invalid> writes: > >> On Mon, 15 Jun 2026 01:15:12 -0000 (UTC), Waldek Hebisch wrote: >> >>> On equvalent programs built from low-level operations 'sbcl' >>> routinely gets _much_ better performance than Python. >> >> Is this with similar memory consumption? > > sbcl has a new generation GC. Is that a yes or a no?
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2026-06-17 01:43 -0700 |
| Message-ID | <87jyrx4kw3.fsf@nightsong.com> |
| In reply to | #60945 |
Lawrence D’Oliveiro <ldo@nz.invalid> writes: >>> Is this with similar memory consumption? >> sbcl has a new generation GC. > Is that a yes or a no? You're grasping at straws. There are speed vs space trade-offs in everything, and bigger systems always choose speed. If you want something that saves space over CPython, try MicroPython. It uses a mark-sweep GC (I don't remember if it relocates) instead of semispace. Hedgehog Lisp (not used much these days) was designed to run on microprocessors with around 256K of memory and it used a semispace GC (it actually had semispace and mark-sweep). 256K is probably still too small for CPython. If you want REALLY tiny, there is a Boehm-style conservative GC available that's written in Forth for use in Forth systems. What's the smallest memory system that you've used CPython in? What's the largest Python heap you've had to use? I once slapped together a CPython script that had around 50GB of live data memory (it scanned a TB or so of server logs and collected some info by tracking stuff that had been seen earlier and was kept in memory) but again that was a speed-space tradeoff. If it had used 100GB or even 200GB I wouldn't have cared, since I had a 256GB machine available to run it on. On the other hand if all I'd had was say an 1GB machine, I would have written the script differently to make two passes separated by an on-disk sorting phase. I've done that type of thing many times. I don't understand this notion of partisanship for reference counting. Or even for CPython which is in many ways a crappy program that still exists mostly because of a big legacy codebase that depends on it. In fact the reference counting is part of the problem because C extensions have to deal with it. Lisp and Java systems usually have a much cleaner FFI where it's easier to port extensions between systems.
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D’Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2026-06-18 01:07 +0000 |
| Message-ID | <110vgcp$292a0$3@dont-email.me> |
| In reply to | #60948 |
On Wed, 17 Jun 2026 01:43:40 -0700, Paul Rubin wrote: > Lawrence D’Oliveiro <ldo@nz.invalid> writes: >>> >>>> Is this with similar memory consumption? >>> >>> sbcl has a new generation GC. >> >> Is that a yes or a no? > > You're grasping at straws. I asked a specific question, I expect a specific answer. It is the ones who cannot or will not answer that are “grasping at straws”. > I don't understand this notion of partisanship for reference > counting. It’s all about performance.
[toc] | [prev] | [next] | [standalone]
| From | George Neuner <gneuner2@comcast.net> |
|---|---|
| Date | 2026-06-11 06:37 -0400 |
| Message-ID | <pl1l2lhuuc2eogbrqno9fgc99pnlulog0v@4ax.com> |
| In reply to | #60839 |
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 5 of 8 — ← Prev page 1 2 3 4 [5] 6 7 8 Next page →
Back to top | Article view | comp.lang.lisp
csiph-web