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

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

Resources to learn common lisp?

Started byMario Rosell <mario@mariorosell.es>
First post2026-02-20 22:53 +0100
Last post2026-06-03 03:16 +0000
Articles 20 on this page of 216 — 21 participants

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? 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? Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-28 07:55 +0000
                            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? Paul Rubin <no.email@nospam.invalid> - 2026-06-21 14:57 -0700
                                    Re: Resources to learn common lisp? Stefan Monnier <monnier@iro.umontreal.ca> - 2026-06-22 09:11 -0400
                                  Re: Resources to learn common lisp? tfb <tfb@work.it.out> - 2026-06-24 22:14 +0000
                                    Re: Resources to learn common lisp? Stefan Monnier <monnier@iro.umontreal.ca> - 2026-06-25 11:20 -0400
                                  Re: Resources to learn common lisp? Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-28 23:21 +0000
                                Re: Resources to learn common lisp? George Neuner <gneuner2@comcast.net> - 2026-06-20 13:43 -0400
                                  Re: Resources to learn common lisp? Alan Bawden <alan@csail.mit.edu> - 2026-06-20 22:28 -0400
                                    Re: Resources to learn common lisp? Stefan Monnier <monnier@iro.umontreal.ca> - 2026-06-22 09:16 -0400
                              Re: Resources to learn common lisp? Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-27 23:38 +0000
                          Re: Resources to learn common lisp? ram@zedat.fu-berlin.de (Stefan Ram) - 2026-06-26 00:43 +0000
                            Re: Resources to learn common lisp? Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-27 02:52 +0000
                      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? Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-27 23:35 +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? Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-28 07:47 +0000
                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? steve g <Sgonedes1977@gmail.com> - 2026-06-28 22:42 -0400
                                    Re: Resources to learn common lisp? tfb <no_email@invalid.invalid> - 2026-06-16 13:34 +0000
                                Re: Resources to learn common lisp? steve g <Sgonedes1977@gmail.com> - 2026-06-28 22:41 -0400
                                  Re: Resources to learn common lisp? Paul Rubin <no.email@nospam.invalid> - 2026-06-28 20:31 -0700
                        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? Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-27 02:56 +0000
                                      Re: Resources to learn common lisp? tfb <tfb@work.it.out> - 2026-06-27 20:25 +0000
                                        Re: Resources to learn common lisp? Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-28 23:37 +0000
                                          Re: Resources to learn common lisp? Paul Rubin <no.email@nospam.invalid> - 2026-06-28 16:55 -0700
                                        Re: Resources to learn common lisp? steve g <Sgonedes1977@gmail.com> - 2026-06-28 22:48 -0400
                                          Re: Resources to learn common lisp? Paul Rubin <no.email@nospam.invalid> - 2026-06-28 20:34 -0700
                                      Re: Resources to learn common lisp? Paul Rubin <no.email@nospam.invalid> - 2026-06-27 13:48 -0700
                                        Re: Resources to learn common lisp? Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-28 23:34 +0000
                                  Re: Resources to learn common lisp? Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-27 02:58 +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? Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-27 03:02 +0000
                                        Re: Resources to learn common lisp? Paul Rubin <no.email@nospam.invalid> - 2026-06-26 21:47 -0700
                                          Re: Resources to learn common lisp? Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-27 23:18 +0000
                                            Re: Resources to learn common lisp? Paul Rubin <no.email@nospam.invalid> - 2026-06-28 16:36 -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? Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-27 23:29 +0000
                                        Re: Resources to learn common lisp? Paul Rubin <no.email@nospam.invalid> - 2026-06-28 16:41 -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? Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-28 23:38 +0000
                                Re: Resources to learn common lisp? Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-28 23:42 +0000
                      Re: Resources to learn common lisp? steve g <Sgonedes1977@gmail.com> - 2026-06-28 22:37 -0400
                        Re: Resources to learn common lisp? Paul Rubin <no.email@nospam.invalid> - 2026-06-28 20:42 -0700
                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 7 of 11 — ← Prev page 1 … 5 6 [7] 8 9 … 11  Next page →

#60963

FromPaul Rubin <no.email@nospam.invalid>
Date2026-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]

#60964

Fromtfb <no_email@invalid.invalid>
Date2026-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]

#60967

Fromantispam@fricas.org (Waldek Hebisch)
Date2026-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]

#60938

Fromsteve g <Sgonedes1977@gmail.com>
Date2026-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]

#60945

FromLawrence D’Oliveiro <ldo@nz.invalid>
Date2026-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]

#60948

FromPaul Rubin <no.email@nospam.invalid>
Date2026-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]

#60957

FromLawrence D’Oliveiro <ldo@nz.invalid>
Date2026-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]

#60988

Fromsteve g <Sgonedes1977@gmail.com>
Date2026-06-19 18:58 -0400
Message-ID<87bjd6jfxu.fsf@gmail.com>
In reply to#60948
Paul Rubin <no.email@nospam.invalid> writes:

> 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 had a SCSI setup that did parallel operations like this. unfortunately
I can no longer afford the hardware - not to mention SCSI is a pain in
the a$$ to use; I hate crimping cables.

Yes it is faster but much more expensive and complicated at the hardware
level, IMHO.

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

#60987

Fromsteve g <Sgonedes1977@gmail.com>
Date2026-06-19 18:52 -0400
Message-ID<87ik7ejg8e.fsf@gmail.com>
In reply to#60945
Lawrence D’Oliveiro <ldo@nz.invalid> writes:

> 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?


File: sbcl.info,  Node: History and Implementation of SBCL,  Prev: More Common Lisp Information,  Up: Introduction

"
SBCL also inherited some newer architectural features from CMUCL. The
most important is that on some architectures it has a generational
garbage collector ("GC"), which has various implications (mostly good)
for performance.  These are discussed in another chapter, *note
Efficiency::.
"

what type of machine are you running?

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

#60994

FromLawrence D’Oliveiro <ldo@nz.invalid>
Date2026-06-20 00:04 +0000
Message-ID<1114lf3$3m8ht$2@dont-email.me>
In reply to#60987
On Fri, 19 Jun 2026 18:52:01 -0400, steve g wrote:

> Lawrence D’Oliveiro <ldo@nz.invalid> writes:
> 
>> 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?
> 
> "
> SBCL also inherited some newer architectural features from CMUCL. The
> most important is that on some architectures it has a generational
> garbage collector ("GC"), which has various implications (mostly good)
> for performance.  These are discussed in another chapter, *note
> Efficiency::.
> "

And memory consumption?

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

#60850

FromGeorge Neuner <gneuner2@comcast.net>
Date2026-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]

#60875

FromPaul Rubin <no.email@nospam.invalid>
Date2026-06-13 13:30 -0700
Message-ID<87ldci89p4.fsf@nightsong.com>
In reply to#60850
George Neuner <gneuner2@comcast.net> writes:
> Copying is similar to marking in that it jumps around, but copying
> eliminates the need to sweep afterward.

I remember that GHC's generational GC is tuned so that the most frequent
copy operations are in blocks small enough to fit in the CPU L2 cache,
256K or whatever.  I expect that's typical of modern GC's but I haven't
been on top of things.

Fwiw SPITBOL has something like a generational mark-sweep GC that it
says it got from Lisp 2.0.  Lisp 2.0 is now otherwise completely obscure
from what I can tell.  Old objects get compacted down to a region called
the "sediment" which is not scanned in most later GC operations, if I
remember it right.  There are occasional bigger GC's where the sediment
also gets scanned.  It seems like a cool idea but I haven't investigated
it that much.

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

#60881

FromLawrence D’Oliveiro <ldo@nz.invalid>
Date2026-06-14 00:58 +0000
Message-ID<110kucd$3a32m$4@dont-email.me>
In reply to#60875
On Sat, 13 Jun 2026 13:30:31 -0700, Paul Rubin wrote:

> I remember that GHC's generational GC is tuned so that the most
> frequent copy operations are in blocks small enough to fit in the
> CPU L2 cache, 256K or whatever.

That “or whatever” is a bit of a problem though, isn’t it?

Also, it’s pointless to break up sequential data access into blocks
small enough to fit into the cache, if they’re only going to be read
once in the cache before being replaced by the next block. Caches are
all about speeding up repeated accesses to the same data.

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

#60891

FromPaul Rubin <no.email@nospam.invalid>
Date2026-06-14 01:46 -0700
Message-ID<87jys17bms.fsf@nightsong.com>
In reply to#60881
Lawrence D’Oliveiro <ldo@nz.invalid> writes:
>> CPU L2 cache, 256K or whatever.
> That “or whatever” is a bit of a problem though, isn’t it?

It's a compiled system and the runtime is aware of the machine
architecture, including the cache size.

> Caches are all about speeding up repeated accesses to the same data.

No I don't think so.  Cache is fast memory.  If you write a value to
cache and then never access it again, that operation is still faster
than writing it to ram, or (worse) to disk.

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

#60906

FromGeorge Neuner <gneuner2@comcast.net>
Date2026-06-15 06:59 -0400
Message-ID<1alv2lpue9vhmus2fk7fkc7r04gplmkub7@4ax.com>
In reply to#60891
On Sun, 14 Jun 2026 01:46:19 -0700, Paul Rubin
<no.email@nospam.invalid> wrote:

>Lawrence D’Oliveiro <ldo@nz.invalid> writes:
>>> CPU L2 cache, 256K or whatever.
>> That “or whatever” is a bit of a problem though, isn’t it?
>
>It's a compiled system and the runtime is aware of the machine
>architecture, including the cache size.
>
>> Caches are all about speeding up repeated accesses to the same data.
>
>No I don't think so.  Cache is fast memory.  If you write a value to
>cache and then never access it again, that operation is still faster
>than writing it to ram, or (worse) to disk.

But remember that when a (still valid) cache line is replaced, the
data must be pushed to a higher level of cache, and ultimately written
out to memory.  These mechinations use up memory system bandwidth that
might have gone to doing something else.

E.g., almost no runtime system bothers to invalidate the cache lines
belonging to freed stack frames.  Because of context switching, quite
a bit of cache bandwith can get taken up moving data that logically
has been abandoned.


I liked the idea of "backless memory" .. in-cache-only processing ...
promoted by the Mill.  No other architecture works that way and I was
sorry to see it fail.

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

#60909

FromPaul Rubin <no.email@nospam.invalid>
Date2026-06-15 12:25 -0700
Message-ID<87ldcf61yd.fsf@nightsong.com>
In reply to#60906
George Neuner <gneuner2@comcast.net> writes:
> But remember that when a (still valid) cache line is replaced, the
> data must be pushed to a higher level of cache, and ultimately written
> out to memory.  These mechinations use up memory system bandwidth that
> might have gone to doing something else.

Yeah there seems to be no way to invalidate data cache without flushing
it.  Web search finds several people looking for ways to do it and it
just isn't there.  But, if you write a cached location, then overwrite
the location before the cache is flushed, the value you originally wrote
doesn't get written out.  Dunno if that helps.  It looks like ARM has a
mechanism for it, though the instructions are privileged:

https://developer.arm.com/documentation/den0042/0100/Caches/Invalidating-and-cleaning-cache-memory

I might sometime look into whether RISC-V has anything like that.

x86 ironically enough has a way to invalidate lines of the instruction
cache, but not the data cache.  You're supposed to use it if you write
self-modifying code.  Zomg.

In a semispace GC, I guess on the output side, you really do want to
push out the cached stuff you have written.  On the input side you could
potentially optimize by overlapping some cache loads using the x86
PREFETCHW instruction, but maybe the stuff you want is already in cache.

Anyway, that was for Haskell, which generates garbage by the bucketful.
I don't know if it's similar for Lisp.  Lawrence D. mentioned optimizing
Java programs by avoiding allocation, and I know that Lisp was like that
too, at least once upon a time.  Thus things like NCONC and NREVERSE,
the reviled LOOP macro destructively appending to lists, etc.  Scheme
tried to cultivate a more immutable style and I don't know what that
cost in GC overhead.

Someone mentioned observing GC using up to 30% of a Lisp program's cpu
cycles but usually not more.  That's consistent with what I've seen with
GHC.

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

#61029

FromLawrence D’Oliveiro <ldo@nz.invalid>
Date2026-06-28 07:47 +0000
Message-ID<111qjho$3f7de$8@dont-email.me>
In reply to#60891
On Sun, 14 Jun 2026 01:46:19 -0700, Paul Rubin wrote:

> Lawrence D’Oliveiro <ldo@nz.invalid> writes:
>>
>> Caches are all about speeding up repeated accesses to the same
>> data.
>
> No I don't think so.

You don’t “think”?

> Cache is fast memory.

Of limited size. Not nearly enough to contain all the live objects in
the heap (in realistic cases). As it fills up, contents have to be
dumped to the next, slower, level of memory. So bulk transfers, which
pretty much by definition are going to larger than any RAM cache, are
inevitably going to be bottlenecked by the speed of the slowest memory
in the hierarchy, which is main RAM.

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

#60853

Fromtfb <no_email@invalid.invalid>
Date2026-06-11 17:42 +0000
Message-ID<110es1g$1kk17$1@dont-email.me>
In reply to#60839
Lawrence D´Oliveiro <ldo@nz.invalid> wrote:
> 
> 
> 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.
>

Um, that is not how copying GCs (which is almost certainly most modern
Lispoid GCs) work.  At all.

A naïve copying GC starts from some known roots and traces (and copies) all
objects reachable from those roots.  It never touches dead objects: once an
object is dead (has no references) it is never touched again by the GC.

The trick (one of the tricks) is then to arrange things so that programs
with very large amounts of live data do not result in the GC taking forever
and requiring a large amount of memory for the copy.  Hence generational
GCs.

Very old GCs, GCs which need to support languages with rigid ideas of where
objects are in memory, or GCs which need to be able to cope with tiny
available memory, may still do mark-and-sweep rather than copying.  This
(needing to support interfaces to primitive languages) is (I am pretty
sure) why LispWorks, say, still has a GC which can do mark and sweep for
some parts of memory.


-- 
www.tfeb.org/computer/

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

#60855

FromLawrence D’Oliveiro <ldo@nz.invalid>
Date2026-06-12 00:16 +0000
Message-ID<110fj4q$1r13s$5@dont-email.me>
In reply to#60853
On Thu, 11 Jun 2026 17:42:08 -0000 (UTC), tfb wrote:

> A naïve copying GC starts from some known roots and traces (and
> copies) all objects reachable from those roots. It never touches
> dead objects: once an object is dead (has no references) it is never
> touched again by the GC.

That memory has to be marked as free for reallocation somehow. That
will be where the cache-thrashing comes in, no escaping it.

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

#60858

Fromtfb <no_email@invalid.invalid>
Date2026-06-12 12:34 +0000
Message-ID<110guci$26cjr$1@dont-email.me>
In reply to#60855
Lawrence D´Oliveiro <ldo@nz.invalid> wrote:
> 
> That memory has to be marked as free for reallocation somehow. That
> will be where the cache-thrashing comes in, no escaping it.
> 

It does not.  Once the live data has been copied from the area of memory it
is free, and new allocation may take place there.  You really need to think
about how a copying GC works.


-- 
www.tfeb.org/computer/

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

Page 7 of 11 — ← Prev page 1 … 5 6 [7] 8 9 … 11  Next page →

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

csiph-web