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 103 — 18 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? 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? George Neuner <gneuner2@comcast.net> - 2026-06-11 05:27 -0400
Re: Resources to learn common lisp? steve g <sgonedes1977@gmail.com> - 2026-06-10 12:24 -0400
Re: Resources to learn common lisp? George Neuner <gneuner2@comcast.net> - 2026-06-11 05:57 -0400
Re: Resources to learn common lisp? 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? 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? 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-12 12:42 +0000
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? 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? 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? 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? 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? Paul Rubin <no.email@nospam.invalid> - 2026-06-14 13:14 -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? 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 3 of 6 — ← Prev page 1 2 [3] 4 5 6 Next page →
| From | Lawrence D’Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2026-06-13 00:13 +0000 |
| Message-ID | <110i7bu$2iqm8$8@dont-email.me> |
| In reply to | #60860 |
On Fri, 12 Jun 2026 13:06:44 -0000 (UTC), tfb wrote: > ... isn't it the case that early machines often ran either with the > GC disabled or without one at all because it wasn't working yet? I recall hearing that the machines would typically run OK for a day or two before they ran out of memory. Instead of GC, you just rebooted. > The D-machines used reference counting, and the Medley release had a > pretty competent (pre-ANSI) CL environment. So that's a CL which > used (uses, even) reference counting, Did it do multithreading?
[toc] | [prev] | [next] | [standalone]
| From | tfb <no_email@invalid.invalid> |
|---|---|
| Date | 2026-06-13 07:25 +0000 |
| Message-ID | <110j0lm$2otbu$1@dont-email.me> |
| In reply to | #60863 |
Lawrence D´Oliveiro <ldo@nz.invalid> wrote: > > Did it do multithreading? > Interlisp-D did and you could call Interlisp from CL (and vice versa), so yes. I mean, you can just try it out: the Medley Interlisp project is extremely active. https://interlisp.org -- www.tfeb.org/computer/
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D’Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2026-06-13 08:25 +0000 |
| Message-ID | <110j45f$2pomq$1@dont-email.me> |
| In reply to | #60865 |
On Sat, 13 Jun 2026 07:25:42 -0000 (UTC), tfb wrote: > Lawrence D´Oliveiro <ldo@nz.invalid> wrote: >> >> On Fri, 12 Jun 2026 13:06:44 -0000 (UTC), tfb wrote: >>> >>> The D-machines used reference counting, and the Medley release had a >>> pretty competent (pre-ANSI) CL environment. So that's a CL which >>> used (uses, even) reference counting, >> >> Did it do multithreading? >> > Interlisp-D did and you could call Interlisp from CL (and vice > versa), so yes. So they must have had some kind of global lock to ensure the reference counts stayed correct, like Python’s soon-to-be-extinct GIL? > I mean, you can just try it out: the Medley Interlisp project is > extremely active. https://interlisp.org I searched for “threading” and “multithread”, and found nothing.
[toc] | [prev] | [next] | [standalone]
| From | tfb <no_email@invalid.invalid> |
|---|---|
| Date | 2026-06-13 08:46 +0000 |
| Message-ID | <110j5do$2q7dn$1@dont-email.me> |
| In reply to | #60868 |
Lawrence D´Oliveiro <ldo@nz.invalid> wrote: > > So they must have had some kind of global lock to ensure the reference > counts stayed correct, like Python’s soon-to-be-extinct GIL? I don't know. That stuff was all in microcode I think. And unlike Python it wasn't someone's 'my first big program' so chances are it was quite a lot cleverer. > > I searched for “threading” and “multithread”, and found nothing. > Lisps have traditionally called what Unixoid languages call 'threads' 'processes'. Chapter 23 of the manual. -- www.tfeb.org/computer/
[toc] | [prev] | [next] | [standalone]
| From | tfb <no_email@invalid.invalid> |
|---|---|
| Date | 2026-06-13 08:52 +0000 |
| Message-ID | <110j5nr$2qajs$1@dont-email.me> |
| In reply to | #60870 |
tfb <no_email@invalid.invalid> wrote: > Chapter 23 of the manual. 22, sorry. -- tfeb.org/computer/
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D’Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2026-06-14 05:57 +0000 |
| Message-ID | <110lfsf$3dqkh$7@dont-email.me> |
| In reply to | #60871 |
On Sat, 13 Jun 2026 08:52:11 -0000 (UTC), tfb wrote: > tfb <no_email@invalid.invalid> wrote: >> >> Chapter 23 of the manual. > > 22, sorry. The table of contents uses one numbering, the pages themselves use another!
[toc] | [prev] | [next] | [standalone]
| From | Nuno Silva <nunojsilva@invalid.invalid> |
|---|---|
| Date | 2026-06-15 10:10 +0100 |
| Message-ID | <110ofib$7l4s$2@dont-email.me> |
| In reply to | #60889 |
On 2026-06-14, Lawrence D’Oliveiro wrote: > On Sat, 13 Jun 2026 08:52:11 -0000 (UTC), tfb wrote: > >> tfb <no_email@invalid.invalid> wrote: >>> >>> Chapter 23 of the manual. >> >> 22, sorry. > > The table of contents uses one numbering, the pages themselves use > another! What was between §Compiler and §DWIM? It kind of looks like a Chapter 19 went missing? -- Nuno Silva
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D’Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2026-06-14 05:56 +0000 |
| Message-ID | <110lfr8$3dqkh$6@dont-email.me> |
| In reply to | #60870 |
On Sat, 13 Jun 2026 08:46:48 -0000 (UTC), tfb wrote:
> Lawrence D´Oliveiro <ldo@nz.invalid> wrote:
>
>> So they must have had some kind of global lock to ensure the
>> reference counts stayed correct, like Python’s soon-to-be-extinct
>> GIL?
>
> I don't know. That stuff was all in microcode I think. And unlike
> Python it wasn't someone's 'my first big program' so chances are it
> was quite a lot cleverer.
I would say not. Remember, multiprocessor machines were not exactly
common back then. So a multithreaded architecture with a global lock
would have been considered perfectly adequate on the hardware of the
time, since only a single thread could be executing at any point
anyway.
>> I searched for “threading” and “multithread”, and found nothing.
>
> Lisps have traditionally called what Unixoid languages call
> 'threads' 'processes'. Chapter 23 of the manual.
OK, found chapter 23. And page 23-11, which talks about “Global
Resources”: this makes it clear that concurrent “processes” (i.e.
threads) cannot safely share access to global objects without explicit
locking:
Two processes cannot both use the same global resource if there
can be a process switch in the middle of their use (currently this
means calls to BLOCK, but ultimately with a preemptive scheduler
means anytime). Thus, user code should be wary of its own use of
global variables, if it ever makes sense for the code to be run in
more than one process at a time. "State" variables private to a
process should generally be bound in that process; structures that
are shared among processes (or resources used privately but
expensive to duplicate per process) should be protected with
monitor locks or some other form of synchronization.
So no, they had no magical solution to the problem. Note that point
about the “process switch in the middle of their use” -- such a
qualification would only have meaning in the context of a uniprocessor
architecture.
[toc] | [prev] | [next] | [standalone]
| From | Alan Bawden <alan@csail.mit.edu> |
|---|---|
| Date | 2026-06-13 00:55 -0400 |
| Message-ID | <86v7bnrqe2.fsf@williamsburg.bawden.org> |
| In reply to | #60860 |
tfb <no_email@invalid.invalid> writes: > Alan Bawden <alan@csail.mit.edu> wrote: >> Other than those two entries, I don't see much else. > > I think the other thing would be the DYNAMIC-EXTENT declaration, although > that's more about language semantics than anything to do with storage > management. Yeah, that does admit that a Common Lisp implementation probably has both a stack and a heap, and that heap allocation is the norm. But since implementations are allowed to completely ignore DYNAMIC-EXTENT, an implementation remains free to do something completely different! > I didn't use LispMs until much later than you, but isn't it the case that > early machines often ran either with the GC disabled or without one at all > because it wasn't working yet? That would be an implementation (not yet of > CL of course) which had no storage reclamation. There must have been a time when the CONS machine (only one of which was ever built), had no working GC. I don't recall if that was still the case when I joined the project. When I joined, a lot of stuff still wasn't fully working. It was still common in those days to develop code using a compatability layer that ran in MacLisp! But by the time we built the first CADR machine, the GC was working. >> So I don't see anything preventing a Common Lisp or Java implementation from >> doing reference counting, or a Python implementation from _not_ doing >> reference counting. (what's Jython doing after all?) > > The D-machines used reference counting, and the Medley release had a pretty > competent (pre-ANSI) CL environment. So that's a CL which used (uses, > even) reference counting, You mentioned in another thread that Interlisp-D didn't handle cycles as well a you would have liked. I was suprised to read that, because if so, I would expect that those of us at MIT would have never stopped making fun of Interlisp-D for that! Was there some argument for why that wasn't really a problem that we all accepted at the time? Or have I just forgotten knowing that once... -- Alan Bawden
[toc] | [prev] | [next] | [standalone]
| From | tfb <no_email@invalid.invalid> |
|---|---|
| Date | 2026-06-13 07:43 +0000 |
| Message-ID | <110j1m8$2p63h$1@dont-email.me> |
| In reply to | #60864 |
Alan Bawden <alan@csail.mit.edu> wrote: > You mentioned in another thread that Interlisp-D didn't handle cycles as > well a you would have liked. I was suprised to read that, because if > so, I would expect that those of us at MIT would have never stopped > making fun of Interlisp-D for that! Was there some argument for why > that wasn't really a problem that we all accepted at the time? Or have > I just forgotten knowing that once... > I don't know. I was (am) in the UK which was a lot further from things then so I'm not sure how much of a problem it was. In the case I knew about there was some big parser which built a large (by the standards of then) structure with lots of circularities, which you needed to break before dropping it. I think lexical closures in CL leaked as well. I suspect Interlisp (which I don't know well as I always used the CL environment really) was careful not to build circular structure? If I remember I'll ask the Interlisp revival people. -- www.tfeb.org/computer/
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2026-06-13 13:09 -0700 |
| Message-ID | <87tsr68ao2.fsf@nightsong.com> |
| In reply to | #60857 |
Alan Bawden <alan@csail.mit.edu> writes:
> So I don't see anything preventing a Common Lisp or Java
> implementation from doing reference counting, or a Python
> implementation from _not_ doing reference counting. (what's Jython
> doing after all?)
MicroPython in fact uses GC. I would say that old-style Python de facto
assumed reference counting though. People would write:
def foo():
f = open(filename)
do some stuff
return
and rely on the file getting closed when its handle goes out of scope
and its refcount drops to 0. Python later (version 2.5) added "context
managers" aka the "with" statement, which is a type of RAII for stuff
like that. Basically a block of code wrapped in something like
unwind-protect, that initializes something (like a file handle) at the
beginning, and finalizes it in the cleanup action.
The Scheme standards just say the user program sees the illusion of
infinite memory.
There's a notion in the Python world that reference counting somehow
eliminates GC pauses. Of course that's naive, because of what happens
when a large collection gets released.
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D’Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2026-06-14 01:02 +0000 |
| Message-ID | <110kujv$3a32m$5@dont-email.me> |
| In reply to | #60873 |
On Sat, 13 Jun 2026 13:09:33 -0700, Paul Rubin wrote: > There's a notion in the Python world that reference counting somehow > eliminates GC pauses. Of course that's naive, because of what > happens when a large collection gets released. That’s equivalent to how C would handle it, anyway, and with similar performance. With the new free-multithreading architecture, you can pay the price for that wait on a separate thread, while the rest of your program continues on its merry way. Without the cache-hostile behaviour of a garbage collector.
[toc] | [prev] | [next] | [standalone]
| From | tfb <no_email@invalid.invalid> |
|---|---|
| Date | 2026-06-12 12:42 +0000 |
| Message-ID | <110gus7$26hn2$1@dont-email.me> |
| In reply to | #60842 |
steve g <sgonedes1977@gmail.com> wrote: > > you must be a newbie. > Oh dear oh dear. -- www.tfeb.org/computer/
[toc] | [prev] | [next] | [standalone]
| From | Stefan Monnier <monnier@iro.umontreal.ca> |
|---|---|
| Date | 2026-06-09 09:36 -0400 |
| Message-ID | <jwv5x3rg80j.fsf-monnier+comp.lang.lisp@gnu.org> |
| In reply to | #60825 |
> Lisp is purely garbage-collected though, isn’t it? Most languages (Lisp included) don't specify how and when unreachable objects are collected, as others pointed out. Actually, most languages don't even specify what counts as "unreachable" (Scheme being one of the exceptions). > Languages like Perl and Python try for a hybrid > reference-counted/garbage-collected approach, for speed and also more > deterministic memory usage in many common scenarios. Probably not "for speed": it takes a significant amount of work to make a reference-counting system that's competitive (speedwise) with a tracing GC, because there tend to be *many* refcount updates (and it gets worse if you support concurrency, where most of those updates need to be made atomic). === Stefan
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D’Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2026-06-10 00:06 +0000 |
| Message-ID | <110a9pp$ckmk$6@dont-email.me> |
| In reply to | #60838 |
On Tue, 09 Jun 2026 09:36:50 -0400, Stefan Monnier wrote: > On Tue, 9 Jun 2026 00:33:44 -0000 (UTC), Lawrence D’Oliveiro wrote: >> >> Languages like Perl and Python try for a hybrid >> reference-counted/garbage-collected approach, for speed and also >> more deterministic memory usage in many common scenarios. > > Probably not "for speed": it takes a significant amount of work to > make a reference-counting system that's competitive (speedwise) with > a tracing GC, because there tend to be *many* refcount updates (and > it gets worse if you support concurrency, where most of those > updates need to be made atomic). But those refcount updates are on live objects, which means they are more likely to reside in some level of CPU cache. Whereas a garbage collector, by design, is spending much of its time hitting long-dead objects, which would likely have long since disappeared from the cache. That’s going to add an order of magnitude or two to your execution time -- which is why we have caches in the first place.
[toc] | [prev] | [next] | [standalone]
| From | Stefan Monnier <monnier@iro.umontreal.ca> |
|---|---|
| Date | 2026-06-10 08:43 -0400 |
| Message-ID | <jwvqzmetvqw.fsf-monnier+comp.lang.lisp@gnu.org> |
| In reply to | #60839 |
>> Probably not "for speed": it takes a significant amount of work to >> make a reference-counting system that's competitive (speedwise) with >> a tracing GC, because there tend to be *many* refcount updates (and >> it gets worse if you support concurrency, where most of those >> updates need to be made atomic). > > But those refcount updates are on live objects, which means they are > more likely to reside in some level of CPU cache. > > Whereas a garbage collector, by design, is spending much of its time > hitting long-dead objects, which would likely have long since > disappeared from the cache. That’s going to add an order of magnitude > or two to your execution time -- which is why we have caches in the > first place. AFAIK, real-life usually disagrees with your analysis, which is why refcount is rarely used in practice for implementations of languages with automatic memory management. === Stefan
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D’Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2026-06-11 00:22 +0000 |
| Message-ID | <110cv4b$13kte$7@dont-email.me> |
| In reply to | #60845 |
On Tue, 09 Jun 2026 09:36:50 -0400, Stefan Monnier wrote: > On Wed, 10 Jun 2026 00:06:17 -0000 (UTC), Lawrence D’Oliveiro wrote: >> >> On Tue, 09 Jun 2026 09:36:50 -0400, Stefan Monnier wrote: >> >>> Probably not "for speed": it takes a significant amount of work to >>> make a reference-counting system that's competitive (speedwise) >>> with a tracing GC, because there tend to be *many* refcount >>> updates (and it gets worse if you support concurrency, where most >>> of those updates need to be made atomic). >> >> But those refcount updates are on live objects, which means they >> are more likely to reside in some level of CPU cache. >> >> Whereas a garbage collector, by design, is spending much of its >> time hitting long-dead objects, which would likely have long since >> disappeared from the cache. That’s going to add an order of >> magnitude or two to your execution time -- which is why we have >> caches in the first place. > > AFAIK, real-life usually disagrees with your analysis, which is why > refcount is rarely used in practice for implementations of languages > with automatic memory management. Feel free to show any performance measures that back up your claim -- particularly memory usage. I would say the only reason the Python approach hasn’t been done before now is because it’s hard to do -- pure brute-force GC has always simply been the path of least resistance.
[toc] | [prev] | [next] | [standalone]
| From | Stefan Monnier <monnier@iro.umontreal.ca> |
|---|---|
| Date | 2026-06-11 08:57 -0400 |
| Message-ID | <jwvjys5teuy.fsf-monnier+comp.lang.lisp@gnu.org> |
| In reply to | #60846 |
Lawrence D’Oliveiro [2026-06-11 00:22:36] wrote: > On Tue, 09 Jun 2026 09:36:50 -0400, Stefan Monnier wrote: >> On Wed, 10 Jun 2026 00:06:17 -0000 (UTC), Lawrence D’Oliveiro wrote: >>> On Tue, 09 Jun 2026 09:36:50 -0400, Stefan Monnier wrote: >>>> Probably not "for speed": it takes a significant amount of work to >>>> make a reference-counting system that's competitive (speedwise) >>>> with a tracing GC, because there tend to be *many* refcount >>>> updates (and it gets worse if you support concurrency, where most >>>> of those updates need to be made atomic). >>> >>> But those refcount updates are on live objects, which means they >>> are more likely to reside in some level of CPU cache. >>> >>> Whereas a garbage collector, by design, is spending much of its >>> time hitting long-dead objects, which would likely have long since >>> disappeared from the cache. That’s going to add an order of >>> magnitude or two to your execution time -- which is why we have >>> caches in the first place. >> >> AFAIK, real-life usually disagrees with your analysis, which is why >> refcount is rarely used in practice for implementations of languages >> with automatic memory management. > > Feel free to show any performance measures that back up your claim -- > particularly memory usage. How could memory usage measures back up my claim, which is about speed? === Stefan
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D’Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2026-06-12 00:16 +0000 |
| Message-ID | <110fj5r$1r13s$6@dont-email.me> |
| In reply to | #60854 |
On Thu, 11 Jun 2026 08:57:35 -0400, Stefan Monnier wrote: > Lawrence D’Oliveiro [2026-06-11 00:22:36] wrote: >> >> Feel free to show any performance measures that back up your claim >> -- particularly memory usage. > > How could memory usage measures back up my claim, which is about > speed? Yeah, too bad.
[toc] | [prev] | [next] | [standalone]
| From | antispam@fricas.org (Waldek Hebisch) |
|---|---|
| Date | 2026-06-15 01:15 +0000 |
| Message-ID | <110njmu$2810q$1@paganini.bofh.team> |
| In reply to | #60846 |
Lawrence D’Oliveiro <ldo@nz.invalid> wrote:
> On Tue, 09 Jun 2026 09:36:50 -0400, Stefan Monnier wrote:
>
>> On Wed, 10 Jun 2026 00:06:17 -0000 (UTC), Lawrence D’Oliveiro wrote:
>>>
>>> On Tue, 09 Jun 2026 09:36:50 -0400, Stefan Monnier wrote:
>>>
>>>> Probably not "for speed": it takes a significant amount of work to
>>>> make a reference-counting system that's competitive (speedwise)
>>>> with a tracing GC, because there tend to be *many* refcount
>>>> updates (and it gets worse if you support concurrency, where most
>>>> of those updates need to be made atomic).
>>>
>>> But those refcount updates are on live objects, which means they
>>> are more likely to reside in some level of CPU cache.
>>>
>>> Whereas a garbage collector, by design, is spending much of its
>>> time hitting long-dead objects, which would likely have long since
>>> disappeared from the cache. That’s going to add an order of
>>> magnitude or two to your execution time -- which is why we have
>>> caches in the first place.
>>
>> AFAIK, real-life usually disagrees with your analysis, which is why
>> refcount is rarely used in practice for implementations of languages
>> with automatic memory management.
>
> Feel free to show any performance measures that back up your claim --
> particularly memory usage. I would say the only reason the Python
> approach hasn’t been done before now is because it’s hard to do --
> pure brute-force GC has always simply been the path of least
> resistance.
On equvalent programs built from low-level operations 'sbcl'
routinely gets _much_ better performance than Python. 'sbcl'
has nice profiler which (among other) indicates how much time
is spent in garbage collector. Usually garbage collection
has modest impact on execution speed (say about 10-30%).
Of course, if program is consing like crazy, then cost of
garbage collection will grow. But if you try reference counting
you will spent even more time.
For Python cost of reference counting does not matter too much
simply because cost of interpretation is too big. To get good
speed in Python you want to pass work to C/C++ code which is
is not going to do either GC or reference counting.
Concerning least resistance: in languages like Perl or Python
vast majority of data structures is (or was) noncyclic. In
such case reference counting is easy to implement.
--
Waldek Hebisch
[toc] | [prev] | [next] | [standalone]
Page 3 of 6 — ← Prev page 1 2 [3] 4 5 6 Next page →
Back to top | Article view | comp.lang.lisp
csiph-web