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 7 of 10 — ← Prev page 1 … 5 6 [7] 8 9 10 Next page →
| From | Lawrence D’Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2026-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]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2026-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]
| From | George Neuner <gneuner2@comcast.net> |
|---|---|
| Date | 2026-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]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2026-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]
| From | tfb <no_email@invalid.invalid> |
|---|---|
| Date | 2026-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]
| From | Lawrence D’Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2026-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]
| From | tfb <no_email@invalid.invalid> |
|---|---|
| Date | 2026-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]
| From | Lawrence D’Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2026-06-13 00:11 +0000 |
| Message-ID | <110i789$2iqm8$7@dont-email.me> |
| In reply to | #60858 |
On Fri, 12 Jun 2026 12:34:26 -0000 (UTC), tfb wrote: > 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. 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.
[toc] | [prev] | [next] | [standalone]
| From | George Neuner <gneuner2@comcast.net> |
|---|---|
| Date | 2026-06-13 04:06 -0400 |
| Message-ID | <qk1q2l97mg28cqchb6bnlmsmuggu7bahst@4ax.com> |
| In reply to | #60862 |
On Sat, 13 Jun 2026 00:11:54 -0000 (UTC), Lawrence D´Oliveiro <ldo@nz.invalid> wrote: >On Fri, 12 Jun 2026 12:34:26 -0000 (UTC), tfb wrote: > >> 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. > >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. In most systems there are multiple caches backing one another. Typical desktop now has 3 levels, and server CPUs have 5..8 levels. I think you need to learn more about how multi-level caching works. In multitasking systems it is pretty much guaranteed that a (non-interrupt) context switch will result in losing everything the switched-out thread had in 1st level cache. By the time the thread regains control, many context switches may have occurred and data in 2nd level and higher caches may be lost as well. [Aside, context switching will trash the branch predictor tables as well, so when a particular thread regains control, everything the predictor knew about its branching behavior is gone and must be relearned. This - more than anything else - is why switched in threads are slow to begin.] In hierarchical GC, the size of the "birthing" area where new allocations are made typically is sized based on the 1st level cache. It is very fast to collect because most new allocations die quickly, and collecting leaves copies of many of the surviving objects still in cache (at 2nd level if not 1st). Also in threaded systems with hierarchical GC, often each thread has its own private heap which can be collected by the thread itself whenever necessary (ie. no context switch to a collector). Copying GC also compacts the live set in the new location, which means that fetches may bring multiple objects that are soon to be used. E.g., copying collection can make discontiguous list nodes or array elements contiguous in their new location.
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2026-06-13 13:37 -0700 |
| Message-ID | <87h5n689d5.fsf@nightsong.com> |
| In reply to | #60867 |
George Neuner <gneuner2@comcast.net> writes: > In hierarchical GC, the size of the "birthing" area where new > allocations are made typically is sized based on the 1st level cache. > It is very fast to collect because most new allocations die quickly, Compilers can also do escape analysis and can often avoid heap-allocating short-lived objects at all. Plus they can often unbox primitive-type values if the default representation is boxed. I'm pretty sure CPython has never attempted something like that. No idea about PyPy or other implementations. Python was traditionally a scripting wrapper around a bunch of C libraries, with pure interpreter performance not being that important in its own right. Of course it has gradually become more important and gotten more attention.
[toc] | [prev] | [next] | [standalone]
| From | ram@zedat.fu-berlin.de (Stefan Ram) |
|---|---|
| Date | 2026-06-13 21:25 +0000 |
| Message-ID | <Python-20260613221523@ram.dialup.fu-berlin.de> |
| In reply to | #60876 |
Paul Rubin <no.email@nospam.invalid> wrote or quoted: >Compilers can also do escape analysis and can often avoid >heap-allocating short-lived objects at all. Plus they can often unbox >primitive-type values if the default representation is boxed. > >I'm pretty sure CPython has never attempted something like that. No >idea about PyPy or other implementations. Python was traditionally a >scripting wrapper around a bunch of C libraries, with pure interpreter >performance not being that important in its own right. Of course it has >gradually become more important and gotten more attention. Well, what Python does have with regard to unboxing are array classes that store values unboxed. But this is more for memory efficiency. FWIW: CPython 3.15 is about 60 percent faster than CPython 3.10. In the list of modifications below, only "Immortal Objects" seems to be directly related to garbage collection though. | Python 3.11 | | Specializing Adaptive Interpreter Optimizes execution by dynamically | replacing generic bytecodes with type-specific opcodes for repetitive | tasks. | | Faster Startup Caches code objects inside Frozen imports to skip | standard module initialization overhead. | | Cheaper Stack Frames Minimizes memory usage and layout sizes for | Python frame allocations. | | Inlined Function Calls Bypasses the traditional C stack overhead | during basic internal Python function calls. | | Zero-Cost Exceptions Allocates zero runtime performance overhead to | code executing within a try block when no exception occurs. | | Python 3.12 | | Comprehension Inlining List, dict, and set comprehensions are | compiled directly inline, eliminating single-use function object | creation overhead. | | Per-Interpreter GIL Enables isolated execution across | sub-interpreters by equipping each with a unique Global Interpreter | Lock (GIL). | | Immortal Objects Skips reference-count modifications for global, | persistent runtime entities. | | Eager Async Tasks Adds asyncio.eager_task_factory() to conditionally | bypass event-loop scheduling for a 2x to 5x performance boost. | | Fast Protocol Checks Accelerates standard isinstance() evaluations | against runtime-checkable protocols by up to 20 times. | | Python 3.13 | | Experimental Free-Threaded Build Offers a specialized configuration | to run Python with the GIL completely disabled for parallel multi-core | scaling. | | Copy-and-Patch JIT Introduces an experimental Just-In-Time (JIT) | compiler framework to establish future native code compilation | pathways. | | Mimalloc Integration Adds Microsoft's high-performance memory | allocator to optimize internal runtime threads. | | Stripped Docstrings Discards excessive indentation space within | runtime docstrings to reduce overall .pyc memory footings. | | Python 3.14 | | Tail-Call Interpreter Implements a dedicated tail-call configuration | using modern compilers to deliver 3-5% base speedups across execution | frames. | | Deferred Annotations Postpones active evaluation of standard type | hints until explicit runtime inspection is initiated. | | Zero-Overhead Debugging Adds a native external execution protocol to | hook profilers without causing standard runtime delay. | | Python 3.15 | | Lazy Imports Built-in Provides native PEP 810 lazy imports to | optimize initial startup speeds across heavy applications. | | Tachyon High-Frequency Profiler Features a highly optimized, | zero-overhead statistical sampling profiler ready for active | production instances. | | Native Frame Pointers Enables native architecture frame pointers by | default to speed up eBPF tools and system tracing. | | Upgraded JIT Pipeline Substantially enhances the core assembly of | the experimental JIT compilation tier.
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2026-06-13 15:26 -0700 |
| Message-ID | <87zf0y6pr4.fsf@nightsong.com> |
| In reply to | #60878 |
ram@zedat.fu-berlin.de (Stefan Ram) writes: > CPython 3.15 is about 60 percent faster than CPython 3.10. That change list is quite interesting though some of it is cringy. I havem't really been following Python changes and even my newest installations (Debian Trixie) are still on 3.13. I wish we had a way for a running Python image to snapshot itself, like traditional Lisps did, maybe using something based on CRIU. Emacs Lisp initially did this with a Unix hack that it called unexec(), that eventually became too hard to maintain and was replaced with something more ad hoc. But it seems deficient of OS's to not support anything like that.
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D’Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2026-06-14 05:37 +0000 |
| Message-ID | <110lem9$3dqkh$2@dont-email.me> |
| In reply to | #60879 |
On Sat, 13 Jun 2026 15:26:39 -0700, Paul Rubin wrote: > I wish we had a way for a running Python image to snapshot itself, > like traditional Lisps did ... They didn’t care much for version control in those days though, did they? How do you compare two snapshots to see what’s different?
[toc] | [prev] | [next] | [standalone]
| From | antispam@fricas.org (Waldek Hebisch) |
|---|---|
| Date | 2026-06-15 01:34 +0000 |
| Message-ID | <110nkrq$2810q$2@paganini.bofh.team> |
| In reply to | #60886 |
Lawrence D’Oliveiro <ldo@nz.invalid> wrote:
> On Sat, 13 Jun 2026 15:26:39 -0700, Paul Rubin wrote:
>
>> I wish we had a way for a running Python image to snapshot itself,
>> like traditional Lisps did ...
>
> They didn’t care much for version control in those days though, did
> they?
>
> How do you compare two snapshots to see what’s different?
The the same problem as comparing binaries. And simplest solution
is to record source version used to produce snapshot (or binary).
--
Waldek Hebisch
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D’Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2026-06-15 05:43 +0000 |
| Message-ID | <110o3er$4okg$2@dont-email.me> |
| In reply to | #60900 |
On Mon, 15 Jun 2026 01:34:52 -0000 (UTC), Waldek Hebisch wrote: > Lawrence D’Oliveiro <ldo@nz.invalid> wrote: >> >> How do you compare two snapshots to see what’s different? > > The the same problem as comparing binaries. And simplest solution is > to record source version used to produce snapshot (or binary). So, given a binary, how do you know which source version was used to produce that?
[toc] | [prev] | [next] | [standalone]
| From | antispam@fricas.org (Waldek Hebisch) |
|---|---|
| Date | 2026-06-15 11:23 +0000 |
| Message-ID | <110onb8$2gi2l$2@paganini.bofh.team> |
| In reply to | #60902 |
Lawrence D’Oliveiro <ldo@nz.invalid> wrote:
> On Mon, 15 Jun 2026 01:34:52 -0000 (UTC), Waldek Hebisch wrote:
>
>> Lawrence D’Oliveiro <ldo@nz.invalid> wrote:
>>>
>>> How do you compare two snapshots to see what’s different?
>>
>> The the same problem as comparing binaries. And simplest solution is
>> to record source version used to produce snapshot (or binary).
>
> So, given a binary, how do you know which source version was used to
> produce that?
As I wrote record source version. Typically done by embedding
git hash of the source tree in the binary. Look at embedded
hash and you know.
--
Waldek Hebisch
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D’Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2026-06-16 00:23 +0000 |
| Message-ID | <110q52l$o45a$8@dont-email.me> |
| In reply to | #60908 |
On Mon, 15 Jun 2026 11:23:22 -0000 (UTC), Waldek Hebisch wrote: > Lawrence D’Oliveiro <ldo@nz.invalid> wrote: >> >> On Mon, 15 Jun 2026 01:34:52 -0000 (UTC), Waldek Hebisch wrote: >> >>> Lawrence D’Oliveiro <ldo@nz.invalid> wrote: >>>> >>>> How do you compare two snapshots to see what’s different? >>> >>> The the same problem as comparing binaries. And simplest solution >>> is to record source version used to produce snapshot (or binary). >> >> So, given a binary, how do you know which source version was used >> to produce that? > > As I wrote record source version. Typically done by embedding git > hash of the source tree in the binary. Look at embedded hash and you > know. How do you verify that hash?
[toc] | [prev] | [next] | [standalone]
| From | antispam@fricas.org (Waldek Hebisch) |
|---|---|
| Date | 2026-06-16 03:29 +0000 |
| Message-ID | <110qfvg$2q2b6$2@paganini.bofh.team> |
| In reply to | #60914 |
Lawrence D’Oliveiro <ldo@nz.invalid> wrote:
> On Mon, 15 Jun 2026 11:23:22 -0000 (UTC), Waldek Hebisch wrote:
>
>> Lawrence D’Oliveiro <ldo@nz.invalid> wrote:
>>>
>>> On Mon, 15 Jun 2026 01:34:52 -0000 (UTC), Waldek Hebisch wrote:
>>>
>>>> Lawrence D’Oliveiro <ldo@nz.invalid> wrote:
>>>>>
>>>>> How do you compare two snapshots to see what’s different?
>>>>
>>>> The the same problem as comparing binaries. And simplest solution
>>>> is to record source version used to produce snapshot (or binary).
>>>
>>> So, given a binary, how do you know which source version was used
>>> to produce that?
>>
>> As I wrote record source version. Typically done by embedding git
>> hash of the source tree in the binary. Look at embedded hash and you
>> know.
>
> How do you verify that hash?
What you mean by verify? Are you concerned with malicious actors
changing binaries?
--
Waldek Hebisch
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D’Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2026-06-16 04:59 +0000 |
| Message-ID | <110ql74$sea1$1@dont-email.me> |
| In reply to | #60916 |
On Tue, 16 Jun 2026 03:29:54 -0000 (UTC), Waldek Hebisch wrote: > Lawrence D’Oliveiro <ldo@nz.invalid> wrote: >> >> On Mon, 15 Jun 2026 11:23:22 -0000 (UTC), Waldek Hebisch wrote: >> >>> Lawrence D’Oliveiro <ldo@nz.invalid> wrote: >>>> >>>> On Mon, 15 Jun 2026 01:34:52 -0000 (UTC), Waldek Hebisch wrote: >>>> >>>>> Lawrence D’Oliveiro <ldo@nz.invalid> wrote: >>>>>> >>>>>> How do you compare two snapshots to see what’s different? >>>>> >>>>> The the same problem as comparing binaries. And simplest >>>>> solution is to record source version used to produce snapshot >>>>> (or binary). >>>> >>>> So, given a binary, how do you know which source version was used >>>> to produce that? >>> >>> As I wrote record source version. Typically done by embedding git >>> hash of the source tree in the binary. Look at embedded hash and >>> you know. >> >> How do you verify that hash? > > What you mean by verify? Confirm that it was in fact the commit used to create that snapshot. > Are you concerned with malicious actors changing binaries? You might say that. I couldn’t possibly comment ...
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2026-06-16 15:10 -0700 |
| Message-ID | <875x3i5e72.fsf@nightsong.com> |
| In reply to | #60917 |
Lawrence D’Oliveiro <ldo@nz.invalid> writes: >> Are you concerned with malicious actors changing binaries? > You might say that. I couldn’t possibly comment ... There's such a thing as signed binaries though they're usually associated with vendors trying to thwart legitimate users. Anyway nothing stops you from doing that. The snapshots we're discussing though involves creating a binary the usual way from source code, then running that binary for a while (e.g. to load modules), and then dumping the memory region to save a reloadable image. Obviously those images could also be version controlled and/or signed. I don't think it's commonplace to do that in practice.
[toc] | [prev] | [next] | [standalone]
Page 7 of 10 — ← Prev page 1 … 5 6 [7] 8 9 10 Next page →
Back to top | Article view | comp.lang.lisp
csiph-web