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 181 — 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: [OT] Disappearing documentation steve g <Sgonedes1977@gmail.com> - 2026-06-19 19:05 -0400
Re: Resources to learn common lisp? steve g <Sgonedes1977@gmail.com> - 2026-06-19 19:01 -0400
Re: Resources to learn common lisp? Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-20 00:02 +0000
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? ram@zedat.fu-berlin.de (Stefan Ram) - 2026-06-19 08:12 +0000
Re: Resources to learn common lisp? Paul Rubin <no.email@nospam.invalid> - 2026-06-19 04:27 -0700
Re: Resources to learn common lisp? steve g <Sgonedes1977@gmail.com> - 2026-06-19 21:24 -0400
Re: Resources to learn common lisp? George Neuner <gneuner2@comcast.net> - 2026-06-20 13:00 -0400
Re: Resources to learn common lisp? Stefan Monnier <monnier@iro.umontreal.ca> - 2026-06-18 12:53 -0400
Re: Resources to learn common lisp? Alan Bawden <alan@csail.mit.edu> - 2026-06-18 21:28 -0400
Re: Resources to learn common lisp? Stefan Monnier <monnier@iro.umontreal.ca> - 2026-06-19 15:08 -0400
Re: Resources to learn common lisp? Alan Bawden <alan@csail.mit.edu> - 2026-06-19 22:32 -0400
Re: Resources to learn common lisp? George Neuner <gneuner2@comcast.net> - 2026-06-20 13:56 -0400
Re: Resources to learn common lisp? George Neuner <gneuner2@comcast.net> - 2026-06-20 13:43 -0400
Re: Resources to learn common lisp? steve g <Sgonedes1977@gmail.com> - 2026-06-19 19:06 -0400
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? steve g <Sgonedes1977@gmail.com> - 2026-06-19 18:48 -0400
Re: Resources to learn common lisp? steve g <Sgonedes1977@gmail.com> - 2026-06-19 18:28 -0400
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? steve g <Sgonedes1977@gmail.com> - 2026-06-19 18:58 -0400
Re: Resources to learn common lisp? steve g <Sgonedes1977@gmail.com> - 2026-06-19 18:52 -0400
Re: Resources to learn common lisp? Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-20 00:04 +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? Stefan Monnier <monnier@iro.umontreal.ca> - 2026-06-18 12:44 -0400
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? Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-19 07:01 +0000
Re: Resources to learn common lisp? antispam@fricas.org (Waldek Hebisch) - 2026-06-19 11:41 +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 8 of 10 — ← Prev page 1 … 6 7 [8] 9 10 Next page →
| From | tfb <no_email@invalid.invalid> |
|---|---|
| Date | 2026-06-16 13:34 +0000 |
| Message-ID | <110rjdb$156ii$1@dont-email.me> |
| In reply to | #60900 |
Waldek Hebisch <antispam@fricas.org> wrote: > The the same problem as comparing binaries. And simplest solution > is to record source version used to produce snapshot (or binary). > And version control is not what saved images are for, at least today: they're for delivering programs, and for the same things people use VM snapshots for now: recovery from disasters and shipping images to different hardware, for instance. Instead we all end up using a language which doesn't do that and wrapping delivered programs in vast layers of what are essentially images, in the firm of Docker and VMs. -- tfeb.org/computer/
[toc] | [prev] | [next] | [standalone]
| From | tfb <no_email@invalid.invalid> |
|---|---|
| Date | 2026-06-13 08:36 +0000 |
| Message-ID | <110j4qk$2q1p4$1@dont-email.me> |
| In reply to | #60862 |
Lawrence D´Oliveiro <ldo@nz.invalid> wrote: > That’s even worse. That means the live objects have to be moved from > their existing locations, which might be in the cache, into new > locations which most likely are not. How do you think the copying happens? How does the data you've just written to its new location manage not to end up in a cache? I really think you need to read, *and understand* some material on computer architecture. I don't know if Hennessy and Patterson is still as good as it was, but it's likely a good place to start. Then implement a simple two-space copying GC (real examples tend to be so full of low-level cleverness that it's better to implement a naïve one). A good way to do this is to start by writing a program which will defragment objects in memory: turn a linked list into another one whose links nodes are all adjacent, say. When you do that, you'll find you've basically written a copying GC. -- www.tfeb.org/computer/
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D’Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2026-06-14 01:43 +0000 |
| Message-ID | <110l0v9$3av52$1@dont-email.me> |
| In reply to | #60869 |
On Sat, 13 Jun 2026 08:36:36 -0000 (UTC), tfb wrote: > Lawrence D´Oliveiro <ldo@nz.invalid> wrote: > >> That’s even worse. That means the live objects have to be moved >> from their existing locations, which might be in the cache, into >> new locations which most likely are not. > > How do you think the copying happens? How does the data you've just > written to its new location manage not to end up in a cache? You need to remember what the cache is for. Having a cache in the copying path doesn’t somehow magically speed up copying. And remember, *everything* that is live is being pushed into the cache by the copying -- including objects that the program wasn’t actually needing at the moment.
[toc] | [prev] | [next] | [standalone]
| From | Stefan Monnier <monnier@iro.umontreal.ca> |
|---|---|
| Date | 2026-06-14 10:36 -0400 |
| Message-ID | <jwvbjdd5gx3.fsf-monnier+comp.lang.lisp@gnu.org> |
| In reply to | #60884 |
> And remember, *everything* that is live is being pushed into the cache > by the copying -- including objects that the program wasn’t actually > needing at the moment. Yeah, GCs are very costly. Which makes it all the more amazing that reference counting is typically even worse. === Stefan
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D’Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2026-06-14 23:55 +0000 |
| Message-ID | <110nf0q$3vra6$3@dont-email.me> |
| In reply to | #60893 |
On Sun, 14 Jun 2026 10:36:48 -0400, Stefan Monnier wrote: > Yeah, GCs are very costly. Which makes it all the more amazing that > reference counting is typically even worse. Do you have a reference for that? One which shows that heap-intensive operations are more efficient (size, speed) when doing with a garbage collector than reference-counting?
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2026-06-14 18:04 -0700 |
| Message-ID | <87y0gg62cx.fsf@nightsong.com> |
| In reply to | #60896 |
Lawrence D’Oliveiro <ldo@nz.invalid> writes:
> Do you have a reference for that? One which shows that heap-intensive
> operations are more efficient (size, speed) when doing with a garbage
> collector than reference-counting?
Chapter 5 of "The Garbage Collection Handbook" (Jones, Hosking, & Moss
2012) is about reference counting. Most of what it says about naive
reference counting (like Python's, or C++'s std::shared_ptr) is bad.
The relevant text is a page or so, more than I want to type. The rest
of the chapter is about ways to get around the deficiencies.
I also looked up Zorn's PhD thesis (about GC performance) from 1988:
https://www2.eecs.berkeley.edu/Pubs/TechRpts/1989/Archive/CSD-89-544.pdf
It says similar things to the GC handbook above:
Unfortunately, reference counting has fundamental disadvantages.
First and foremost, reference counting algorithms do not reclaim
storage allocated in circular structures. Modifications to the
traditional algorithm have been suggested to overcome this problem,
but the performance of the modified algorithm is unacceptably slow.
As a result, reference counting algorithms are augmented with
traditional garbage collection algorithms. A second disadvantage of
reference counting is that space is required to maintain the count.
A simple implementation associates a 32-bit count with each object
and increases the size of each cons object (the most common object
type) by 50%. More complex implementations reduce this overhead but
do not entirely eliminate it. A third disadvantage of reference
counting is that it fails to reorganize or compact objects in memory
and is thus unable to improve the locality of references to those
objects. By using generations, garbage collection can signicantly
improve reference locality, as this thesis shows. Finally, the most
signicant advantage of reference counting, that of incrementally
collecting storage, has also been achieved with garbage collection
algorithms using incremental and generation techniques.
Because of these disadvantages, reference counting is not often used
in modern Lisp and Smalltalk implementations. Recently, however,
research with distributed memory computers has sparked renewed
interest in reference counting algorithms because they allow storage
deallocation based on local information, instead of the global
information required by garbage collection. This dissertation
focuses entirely on techniques for garbage collection and does not
consider reference counting any further.
Jones' online GC bibliography has a bunch of entries that mention
reference counting. Only a few look even slightly relevant, but you
could check them if you want.
https://www.cs.kent.ac.uk/people/staff/rej/cgi-bin/searchbib?pattern=reference+counting
[toc] | [prev] | [next] | [standalone]
| From | tfb <no_email@invalid.invalid> |
|---|---|
| Date | 2026-06-16 12:33 +0000 |
| Message-ID | <110rfqf$142ot$1@dont-email.me> |
| In reply to | #60898 |
Paul Rubin <no.email@nospam.invalid> wrote: > > Chapter 5 of "The Garbage Collection Handbook" (Jones, Hosking, & Moss > 2012) is about reference counting. Most of what it says about naive > reference counting (like Python's, or C++'s std::shared_ptr) is bad. > The relevant text is a page or so, more than I want to type. The rest > of the chapter is about ways to get around the deficiencies. > You can also just measure stuff. In the thing I just posted the GC was called 4,065 times on generation 0. Each time it found no more than 1,000 live conses each of which is 16 bytes (2 words). So it copied something like 65MB. A better way is probably to say it considered at about 4 million conses. The program allocated a billion conses, so the GC saw about 1/250th of them (not coincidentally the GC runtime was about 1/250th of the total runtime). A reference counted system would have looked at, *and written the reference counts of* all billion conses: about 250 times as many as the GC. I don't have a reference-counted modern Lisp, but it seems deeply implausible that it would be faster. If it was faster, it could only reduce run-time by under 0.5%, because that's what the GC overhead was. This was for a program which did essentially nothing but allocate memory. So it is empirically not the case that GCs are slow for programs which allocate heavily. Obviously if you allocate in a way which is intentionally hostile to the GC *and* you don't tune the GC to deal with that then they can take longer. LW has extensive support for this: for huge long-lived allocations you allocate into a generation which the GC does not look at, and then when you're done you tell it to look at it, once. I assume other serious GC'd implementations of Lisp or other languages have similar tuning options. -- tfeb.org/computer/
[toc] | [prev] | [next] | [standalone]
| From | Stefan Monnier <monnier@iro.umontreal.ca> |
|---|---|
| Date | 2026-06-15 09:51 -0400 |
| Message-ID | <jwv7bo02aiq.fsf-monnier+comp.lang.lisp@gnu.org> |
| In reply to | #60896 |
Lawrence D’Oliveiro [2026-06-14 23:55:06] wrote: > On Sun, 14 Jun 2026 10:36:48 -0400, Stefan Monnier wrote: >> Yeah, GCs are very costly. Which makes it all the more amazing that >> reference counting is typically even worse. > Do you have a reference for that? One which shows that heap-intensive > operations are more efficient (size, speed) when doing with a garbage > collector than reference-counting? [ For the Nth time: I'm not talking about memory size, only about speed. And not specifically for "heap intensive" operations, but for just normal execution of "typical" programs. ] I don't have a reference, no. But I'm pretty sure there are plenty. I guess the most obvious argument is just the very small number of language implementations that use reference counting and are "high performance" (which presumably implies that the implementors have spent some effort to try and use an efficient memory management technique). I know there exists a GC for the JVM that uses reference counting, but it's only one out of many others. It is competitive speed-wise, but it took a lot of effort to get there (it's very far from a simple reference counting system like CPython's). There's also Lean which uses reference counting, but I haven't seen any indication that it's particularly fast. AFAIK, the main purpose is to allow "functional in place update" (by checking if the refcount is equal to 1), IOW circumvent the language constraint on everything being immutable yet without resorting to monads. Given the amount of effort poured into the GC of many language implementations, if reference counting was competitive speed-wise, it'd be used a lot more, since it's a lot easier to implement (and debug). === Stefan
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D’Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2026-06-16 00:23 +0000 |
| Message-ID | <110q516$o45a$7@dont-email.me> |
| In reply to | #60910 |
On Mon, 15 Jun 2026 09:51:57 -0400, Stefan Monnier wrote: > I guess the most obvious argument is just the very small number of > language implementations that use reference counting and are "high > performance" (which presumably implies that the implementors have > spent some effort to try and use an efficient memory management > technique). Perl was probably the pioneer here. Implementations use garbage collection simply because it’s so much easier to do, nothing more. As I mentioned elsewhere Java gets “high performance” by minimizing heap allocation, at the cost of writing more circumlocutory code. Lisp would be the same. What’s his name, Lisp guru Paul Graham, has a blog online where he talks about working on an early dotcom startup where the development language was Lisp. That gave them a lot of productivity boosts. But the core part of the in-memory database was implemented in C++, precisely where the garbage collector could not get its sticky fingers on it.
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2026-06-16 03:14 -0700 |
| Message-ID | <87a4su6bcg.fsf@nightsong.com> |
| In reply to | #60913 |
Lawrence D’Oliveiro <ldo@nz.invalid> writes: > Lisp would be the same. What’s his name, Lisp guru Paul Graham, has a > blog online where he talks about working on an early dotcom startup > where the development language was Lisp. That gave them a lot of > productivity boosts. But the core part of the in-memory database was > implemented in C++, precisely where the garbage collector could not > get its sticky fingers on it. Do you mean https://www.paulgraham.com/avg.html ? The mention of C++ was after he sold the company to Yahoo: In January 2003, Yahoo released a new version of the editor written in C++ and Perl. It's hard to say whether the program is no longer written in Lisp, though, because to translate this program into C++ they literally had to write a Lisp interpreter: the source files of all the page-generating templates are still, as far as I know, Lisp code. (See Greenspun's Tenth Rule.) He mentions that the ordering system of his site was written in C but doesn't say why. It's not that great an essay imho. And the stuff he says about Python now seems quaint.
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2026-06-16 15:29 -0700 |
| Message-ID | <871pe65dbt.fsf@nightsong.com> |
| In reply to | #60913 |
Lawrence D’Oliveiro <ldo@nz.invalid> writes: > Perl was probably the pioneer here. Implementations use garbage > collection simply because it’s so much easier to do, nothing more. Have you actually implemented both? I feel like a bunch of stuff you're saying come from inexperience. In my case I've implemented an Awk with reference counting and later a Lisp with GC. I used RC in the Awk because at that time, I didn't know how to write a GC. The GC in the Lisp that I wrote was quite simple but I still wouldn't say that it was easier than RC. Of course "serious" GC's are very intricate and not remotely comparable to the naive reference counting in something like Python. It's ridiculous to say it's easier. Here's Simon Marlow et al's 2008 paper on the GHC garbage collector: https://simonmar.github.io/bib/papers/parallel-gc.pdf I have a vague recollection that the GHC GC was later redone to be even more sophisticated. And it's nowhere near as fancy as the GC's used in Java which have gotten a lot more development energy. If of any interest, the current "big" Python implementation is CPython and it uses reference counting. MicroPython, a smaller Python version for microcontrollers, uses GC. Lua, considered a smaller-footprint and more embeddable language than Python, also uses GC. MicroPython ran on MCU's with as little as 16KB of ram (BBC Micro:bit v1) though that was very cramped. It's reasonably usable with 32KB. I don't think CPython could run at all on those machines. I'd be interested to know why CPython uses RC. If I ever meet Guido I'll try to remember to ask him. I do have the impression that immediate reclamation for stuff like file descriptors was claimed as a big advantage, before Python itself got RAII in the "with" statement. Slightly related, do you even use Lisp? I think your picture of how Lisp programs use memory is also unrealistic.
[toc] | [prev] | [next] | [standalone]
| From | Stefan Monnier <monnier@iro.umontreal.ca> |
|---|---|
| Date | 2026-06-16 10:23 -0400 |
| Message-ID | <jwv7bny1t3z.fsf-monnier+comp.lang.lisp@gnu.org> |
| In reply to | #60913 |
Lawrence D’Oliveiro [2026-06-16 00:23:02] wrote: > On Mon, 15 Jun 2026 09:51:57 -0400, Stefan Monnier wrote: >> I guess the most obvious argument is just the very small number of >> language implementations that use reference counting and are "high >> performance" (which presumably implies that the implementors have >> spent some effort to try and use an efficient memory management >> technique). > Perl was probably the pioneer here. Implementations use garbage > collection simply because it’s so much easier to do, nothing more. I'm sorry, but I don't count things like Perl or CPython (or ELisp, for that matter) as high-performance language implementations. As tools, they can be very efficient, but it's not because they run Perl or Python code efficiently: it's because they don't spend much time running actual Perl and Python code (instead they spend most of their time running code written in other languages, like C). > As I mentioned elsewhere Java gets “high performance” by minimizing > heap allocation, at the cost of writing more circumlocutory code. No, Java gets high performance because lots of money was poured into the implementation of JVM's compilers to generate efficient machine code. In turn, this makes the time spent managing memory more visible so it increases pressure on the language implementors to implement efficient memory management, and it also increases pressure on programmers to be mindful of the amount of allocation they perform when they care about speed. > That gave them a lot of productivity boosts. But the core part of the > in-memory database was implemented in C++, precisely where the garbage > collector could not get its sticky fingers on it. This seems to argue that automatic memory management can be expensive. I never claimed otherwise. I'm just claiming that when a language implementation has to implement automatic memory management, the choice of reference counting will usually lead to slower execution than what you'd get with a tracing GC. === Stefan
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2026-06-16 21:34 -0700 |
| Message-ID | <87wlvx4wf8.fsf@nightsong.com> |
| In reply to | #60927 |
Stefan Monnier <monnier@iro.umontreal.ca> writes: > This seems to argue that automatic memory management can be expensive. > I never claimed otherwise. A decade or two ago (idk about now), there was some wisdom claiming that GC increased your program's memory footprint by quite a lot compared with manual memory management. The speed penalty was nowhere near as large.
[toc] | [prev] | [next] | [standalone]
| From | Stefan Monnier <monnier@iro.umontreal.ca> |
|---|---|
| Date | 2026-06-17 15:02 -0400 |
| Message-ID | <jwv33yl2i4r.fsf-monnier+comp.lang.lisp@gnu.org> |
| In reply to | #60941 |
>> This seems to argue that automatic memory management can be expensive. >> I never claimed otherwise. > A decade or two ago (idk about now), there was some wisdom claiming that > GC increased your program's memory footprint by quite a lot compared > with manual memory management. The speed penalty was nowhere near as > large. For many years this question was largely irrelevant because the rest of the impact of automatic memory management (AMM) trumped such questions. I'm thinking here about things like how AMM avoids security issues, speeds up development, and makes it much easier to design generic data-structure libraries. There are now alternatives (mostly Rust but also languages like C++), so it's slowly changing, but AMM remains the obvious default choice. === Stefan
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D’Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2026-06-18 04:14 +0000 |
| Message-ID | <110vrbk$2bgdb$2@dont-email.me> |
| In reply to | #60927 |
On Tue, 16 Jun 2026 10:23:23 -0400, Stefan Monnier wrote: > I'm sorry, but I don't count things like Perl or CPython (or ELisp, > for that matter) as high-performance language implementations. Too bad, because they are. Perl got a reputation for being that seeming oxymoron: a “fast, interpreted” language. And Python -- heavily used in many applications requiring high performance in doing lots of complex computations on large datasets. Java doesn’t get a look in here.
[toc] | [prev] | [next] | [standalone]
| From | Stefan Monnier <monnier@iro.umontreal.ca> |
|---|---|
| Date | 2026-06-18 12:44 -0400 |
| Message-ID | <jwvldcboleb.fsf-monnier+comp.lang.lisp@gnu.org> |
| In reply to | #60960 |
Lawrence D’Oliveiro [2026-06-18 04:14:44] wrote:
> On Tue, 16 Jun 2026 10:23:23 -0400, Stefan Monnier wrote:
>> I'm sorry, but I don't count things like Perl or CPython (or ELisp,
>> for that matter) as high-performance language implementations.
> Too bad, because they are. Perl got a reputation for being that
> seeming oxymoron: a “fast, interpreted” language.
> And Python -- heavily used in many applications requiring high
> performance in doing lots of complex computations on large datasets.
> Java doesn’t get a look in here.
Looks like you missed this part of my message:
As tools, they can be very efficient, but it's not because they run
Perl or Python code efficiently: it's because they don't spend much
time running actual Perl and Python code (instead they spend most of
their time running code written in other languages, like C).
=== Stefan
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2026-06-14 13:14 -0700 |
| Message-ID | <87bjdc7uce.fsf@nightsong.com> |
| In reply to | #60884 |
Lawrence D’Oliveiro <ldo@nz.invalid> writes: > And remember, *everything* that is live is being pushed into the cache > by the copying -- including objects that the program wasn’t actually > needing at the moment. Generational GC exists to avoid that. In most GC cycles, the stuff that you copy is new and either is in use or gets collected at the next cycle. Now and then you have a "major" GC that copies older objects. Those cycles are slower but there aren't that many of them. If you actually profile an application, and GC is dominating the CPU time, something is probably wrong with the program. It's even that way with GHC, which likely generates more garbage than typical Lisp programs do, because of how the language works.
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D’Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2026-06-18 02:30 +0000 |
| Message-ID | <110vl7p$2a675$2@dont-email.me> |
| In reply to | #60894 |
On Sun, 14 Jun 2026 13:14:25 -0700, Paul Rubin wrote: > If you actually profile an application, and GC is dominating the CPU > time, something is probably wrong with the program. You mean, like needing to give it more RAM, maybe? Because RAM usage is not something you can trust a GC-only language to manage for itself, can you?
[toc] | [prev] | [next] | [standalone]
| From | tfb <no_email@invalid.invalid> |
|---|---|
| Date | 2026-06-16 11:46 +0000 |
| Message-ID | <110rd23$137br$1@dont-email.me> |
| In reply to | #60884 |
Lawrence D´Oliveiro <ldo@nz.invalid> wrote:
> You need to remember what the cache is for. Having a cache in the
> copying path doesn’t somehow magically speed up copying.
Where was the bit where I claimed that? Oh, gosh, I didn't claim it, did
I?
>
> And remember, *everything* that is live is being pushed into the cache
> by the copying -- including objects that the program wasn’t actually
> needing at the moment.
>
Here's the thing, you have two systems (1) a system which leaves caches
full of data which is live and which may be referenced again, and (2) a
system which leaves caches full of data which certainly never will be
referenced again. One of these systems is better than the other: can you
guess which?
And yes, the problem with a copying GC is it may need to copy a lot of
data. That's why nobody serious has used naïve two-space copying GCs for
forty years. They use something cleverer.
Here's the output of a program running in an implementation with one of
these cleverer GCs:
? (run)
* 1000000 chunks of 1000
Timing the evaluation of (progn (thrash n m))
User time = 21.156
System time = 0.078
Elapsed time = 21.238
Allocation = 16016000000 bytes
4276 Page faults
total / user / system
total gc activity = 0.086224 / 0.058126 / 0.028098
Standard 0 ( 4065 calls) = 0.083341 / 0.057528 / 0.025813
Standard 1 ( 8 calls) = 0.002883 / 0.000598 / 0.002285
- estimate 16000000000 bytes
* single chunk of 1000000000
Timing the evaluation of (progn (thrash n m :chunk-by-n nil))
User time = 34.310
System time = 7.447
Elapsed time = 46.056
Allocation = 16000000016 bytes
3908831 Page faults
total / user / system
total gc activity = 25.694390 / 18.446271 / 7.248119
Standard 0 ( 19 calls) = 5.275545 / 4.710530 / 0.565015
Standard 1 ( 6 calls) = 1.925155 / 1.636884 / 0.288271
Standard 2 ( 4 calls) = 13.096888 / 8.477376 / 4.619512
Standard 3 ( 2 calls) = 5.396802 / 3.621481 / 1.775321
- estimate 16000000000 bytes
The first call to THRASH allocated 1,000 conses 1,000,000 times: a total
allocation of about 16GB. The GC is taking about 1/246 of the run time.
That's because it never finds more than about 16k of live data, even though
it's run thousands of times.
The second call allocates the same amount: about 16GB. And the two loops
are the same, but this time it's collecting one big list. And now the GC
is taking more than half of the runtime. That's because I've deliberately
written the second example to be hostile to a generational GC and also I
have deliberately not adjusted it so that it doesn't kill the GC. In real
life, if I had a program which I knew was going to allocate some vast,
non-ephemeral object I'd do that in a way that wasn't going to kill the GC.
OK, well, discussing things with you is like discussing things with mud, so
I'll likely give up now.
--
tfeb.org/computer/
[toc] | [prev] | [next] | [standalone]
| From | antispam@fricas.org (Waldek Hebisch) |
|---|---|
| Date | 2026-06-18 15:34 +0000 |
| Message-ID | <111135j$3kbud$1@paganini.bofh.team> |
| In reply to | #60921 |
tfb <no_email@invalid.invalid> wrote:
> Lawrence D´Oliveiro <ldo@nz.invalid> wrote:
>
>> You need to remember what the cache is for. Having a cache in the
>> copying path doesn’t somehow magically speed up copying.
>
> Where was the bit where I claimed that? Oh, gosh, I didn't claim it, did
> I?
>
>>
>> And remember, *everything* that is live is being pushed into the cache
>> by the copying -- including objects that the program wasn’t actually
>> needing at the moment.
>>
>
> Here's the thing, you have two systems (1) a system which leaves caches
> full of data which is live and which may be referenced again, and (2) a
> system which leaves caches full of data which certainly never will be
> referenced again. One of these systems is better than the other: can you
> guess which?
>
> And yes, the problem with a copying GC is it may need to copy a lot of
> data. That's why nobody serious has used naïve two-space copying GCs for
> forty years. They use something cleverer.
>
> Here's the output of a program running in an implementation with one of
> these cleverer GCs:
>
> ? (run)
> * 1000000 chunks of 1000
> Timing the evaluation of (progn (thrash n m))
>
> User time = 21.156
> System time = 0.078
> Elapsed time = 21.238
> Allocation = 16016000000 bytes
> 4276 Page faults
<snip>
> * single chunk of 1000000000
> Timing the evaluation of (progn (thrash n m :chunk-by-n nil))
>
> User time = 34.310
> System time = 7.447
> Elapsed time = 46.056
> Allocation = 16000000016 bytes
> 3908831 Page faults
A simple two-space copying GCs can run with speed comparable
to speed of bulk copy. Modern machine can manage to copy tens
of gigabytes per second. The examples each allocate 16 GB, which
with resonable typical strategy in the second case requres copying
of 32 GB. First one is likely to stabilize with minimal amount of
copied data. Of course, there is cost of bringing allocated memory
from DRAM to the cache, which basically means adding time needed
to copy 16 GB to the cache and time to evict this 16 GB from the
cache. Still, it is few gigabytes per seconds which seems quite
doable by simple two-space copying GCs.
In the first case working set is small enough to fit in the
cache so two-space copying GCs could work entirely in cache
(assuming that GC is smart enough to adjust size of space
to the working data).
BTW: modern CPU-s have considerable write buffering. I would be
not be suprised if CPU noticed that the whole line is overwritten
with new data, so there is no need to bring old data from DRAM.
--
Waldek Hebisch
[toc] | [prev] | [next] | [standalone]
Page 8 of 10 — ← Prev page 1 … 6 7 [8] 9 10 Next page →
Back to top | Article view | comp.lang.lisp
csiph-web