Blue-Maned_Hawk <bluemanedhawk@invalid.invalid> writes:
> Ben Bacarisse wrote:
>> Blue-Maned_Hawk <bluemanedhawk@invalid.invalid> writes:
>> <cut>
>>
>> Since you are clearly happy to post using UTF-8, can I urge you to fix
>> your sig so that it comes out looking right?
>
> Since it is my newsreader that is corrupting it, it is the fault of the
> newsreader, and therefore not within my jurisdiction of a problem to fix.

Nope. You continue to post illegible garbage in your sig, and it's
annoying. I would think it would bother you as well.

If there's a problem with your newsreader, have you reported it to the
maintainers? Have you considered using a different newsreader, or
finding a workaround, or changing your sig?

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Medtronic
void Void(void) { Void(); } /* The recursive call of the void */

Keith Thompson wrote:

> Blue-Maned_Hawk <bluemanedhawk@invalid.invalid> writes:
>> Ben Bacarisse wrote:
>>> Blue-Maned_Hawk <bluemanedhawk@invalid.invalid> writes:
>>> <cut>
>>>
>>> Since you are clearly happy to post using UTF-8, can I urge you to fix
>>> your sig so that it comes out looking right?
>>
>> Since it is my newsreader that is corrupting it, it is the fault of the
>> newsreader, and therefore not within my jurisdiction of a problem to
>> fix.
>
> Nope. You continue to post illegible garbage in your sig, and it's
> annoying. I would think it would bother you as well.

It does.

> If there's a problem with your newsreader, have you reported it to the
> maintainers? Have you considered using a different newsreader, or
> finding a workaround, or changing your sig?

The bugreporting system for the software does not allow anonymous
reports. I cannot use another newsreader. There is no workaround.
Changing my signature is not an option.

--
Blue-Maned_Hawk│shortens to
Hawk│/
blu.mɛin.dÊ°ak/
│he/him/his/himself/Mr.
blue-maned_hawk.srht.site
My signature used to have a cuss in it. One day, somebody quoted an
article of mine and included the signature, but censored the cuss.

On 2024-03-07, Blue-Maned_Hawk <bluemanedhawk@invalid.invalid> wrote:
> The bugreporting system for the software does not allow anonymous
> reports.

Use a fake identity?

> I cannot use another newsreader.

How so? What is the difference between you and people who use other
newsreaders? Is it genetic or environmental? Nature or nurture?

> Changing my signature is not an option.

Getting rid of a garbage signature that nobody can read is not
an option?

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca

On 07/03/2024 08:23, Kaz Kylheku wrote:
> On 2024-03-07, Blue-Maned_Hawk <bluemanedhawk@invalid.invalid> wrote:
>> The bugreporting system for the software does not allow anonymous
>> reports.
>
> Use a fake identity?
>
>> I cannot use another newsreader.
>
> How so? What is the difference between you and people who use other
> newsreaders? Is it genetic or environmental? Nature or nurture?
>
>> Changing my signature is not an option.
>
> Getting rid of a garbage signature that nobody can read is not
> an option?
>

I think Hawk│ is either woke or entitled.

On 06/03/2024 23:00, Michael S wrote:
> On Wed, 6 Mar 2024 12:28:59 +0000
> bart <bc@freeuk.com> wrote:
>
>>
>> "Rust uses a relatively unique memory management approach that
>> incorporates the idea of memory “ownership”. Basically, Rust keeps
>> track of who can read and write to memory. It knows when the program
>> is using memory and immediately frees the memory once it is no longer
>> needed. It enforces memory rules at compile time, making it virtually
>> impossible to have runtime memory bugs.⁴ You do not need to manually
>> keep track of memory. The compiler takes care of it."
>>
>> This suggests the language automatically takes care of this.
>
> Takes care of what?
> AFAIK, heap fragmentation is as bad problem in Rust as it is in
> C/Pascal/Ada etc... In this aspect Rust is clearly inferior to GC-based
> languages like Java, C# or Go.
>
Garbage collection does not stop heap fragmentation. GC does, I
suppose, mean that you need much more memory and bigger heaps in
proportion to the amount of memory you actually need in the program at
any given time, and having larger heaps reduces fragmentation (or at
least reduces the consequences of it).

On Thu, 7 Mar 2024 06:48:19 -0000 (UTC), Blue-Maned_Hawk wrote:

> Ben Bacarisse wrote:
>
>> Blue-Maned_Hawk <bluemanedhawk@invalid.invalid> writes:
>> <cut>
>>
>> Since you are clearly happy to post using UTF-8, can I urge you to fix
>> your sig so that it comes out looking right?
>
> Since it is my newsreader that is corrupting it, it is the fault of the
> newsreader,

I don't think that's the case. Here is a test post using the same
newsreader and something that is probably close to what you want in your
sig. (Yours is too messed up for me to work out exactly what you want it
to look like.)

> and therefore not within my jurisdiction of a problem to
> fix.

Pan is open source. You may not have the skills to fix it, but doing so
is in your jurisdiction (though I may have not understood what you mean by
that).

--
/blu.mɛin.dʰak/ | shortens to "Hawk" | he/him/his/himself/Mr.

On Thu, 7 Mar 2024 11:35:08 +0100
David Brown <david.brown@hesbynett.no> wrote:

> On 06/03/2024 23:00, Michael S wrote:
> > On Wed, 6 Mar 2024 12:28:59 +0000
> > bart <bc@freeuk.com> wrote:
> >
> >>
> >> "Rust uses a relatively unique memory management approach that
> >> incorporates the idea of memory “ownership”. Basically, Rust keeps
> >> track of who can read and write to memory. It knows when the
> >> program is using memory and immediately frees the memory once it
> >> is no longer needed. It enforces memory rules at compile time,
> >> making it virtually impossible to have runtime memory bugs.⁴ You
> >> do not need to manually keep track of memory. The compiler takes
> >> care of it."
> >>
> >> This suggests the language automatically takes care of this.
> >
> > Takes care of what?
> > AFAIK, heap fragmentation is as bad problem in Rust as it is in
> > C/Pascal/Ada etc... In this aspect Rust is clearly inferior to
> > GC-based languages like Java, C# or Go.
> >
> Garbage collection does not stop heap fragmentation. GC does, I
> suppose, mean that you need much more memory and bigger heaps in
> proportion to the amount of memory you actually need in the program
> at any given time, and having larger heaps reduces fragmentation (or
> at least reduces the consequences of it).
>

GC does not stop fragmentation, but it allow heap compaction to be
built-in part of environment. So, it turns heap fragmentation
from denial of service type of problem to mere slowdown, hopefully
insignificant slowdown.
I don't say that heap compaction is impossible in other environments,
but it is much harder, esp. in environments where pointers are visible
to programmer. The famous David Wheeler's quote applies here at full
force.
Also when non-GC environments chooses to implement heap compaction they
suffer the same or bigger impact to real-time responsiveness as GC.
So, although I don't know it for sure, my impression is that generic
heap compaction extremely rarely implemented in performance-aware
non-GC environments.
Performance-neglecting non-GC environments, first and foremost CPython,
can, of course, have heap compaction, although my googling didn't give
me a definite answer whether it's done or not.

Blue-Maned_Hawk <bluemanedhawk@invalid.invalid> writes:
>Keith Thompson wrote:

>The bugreporting system for the software does not allow anonymous
>reports. I cannot use another newsreader. There is no workaround.
>Changing my signature is not an option.

Ignoring your posts is probably the best option.

On 07/03/2024 12:44, Michael S wrote:
> On Thu, 7 Mar 2024 11:35:08 +0100
> David Brown <david.brown@hesbynett.no> wrote:
>
>> On 06/03/2024 23:00, Michael S wrote:
>>> On Wed, 6 Mar 2024 12:28:59 +0000
>>> bart <bc@freeuk.com> wrote:
>>>
>>>>
>>>> "Rust uses a relatively unique memory management approach that
>>>> incorporates the idea of memory “ownership”. Basically, Rust keeps
>>>> track of who can read and write to memory. It knows when the
>>>> program is using memory and immediately frees the memory once it
>>>> is no longer needed. It enforces memory rules at compile time,
>>>> making it virtually impossible to have runtime memory bugs.⁴ You
>>>> do not need to manually keep track of memory. The compiler takes
>>>> care of it."
>>>>
>>>> This suggests the language automatically takes care of this.
>>>
>>> Takes care of what?
>>> AFAIK, heap fragmentation is as bad problem in Rust as it is in
>>> C/Pascal/Ada etc... In this aspect Rust is clearly inferior to
>>> GC-based languages like Java, C# or Go.
>>>
>> Garbage collection does not stop heap fragmentation. GC does, I
>> suppose, mean that you need much more memory and bigger heaps in
>> proportion to the amount of memory you actually need in the program
>> at any given time, and having larger heaps reduces fragmentation (or
>> at least reduces the consequences of it).
>>
>
> GC does not stop fragmentation, but it allow heap compaction to be
> built-in part of environment.

No, GC alone does not do that. But heap compaction is generally done as
part of a GC cycle.

Heap compaction requires indirect pointers. That is to say, if you have
a struct "node" on your heap, your code does not use a "node *" pointer
that points to it. It has a "node_proxy *" pointer, and the
"node_proxy" struct points to the actual node. Heap compaction moves
the real node in memory, and updates the proxy with the new real
address, while the main program uses the same "node_proxy" address.
(These proxies, or indirect pointers, do not move during heap
compaction.) And the main program needs to be careful to access the
data via the proxy, and re-read the proxy after every heap compaction cycle.

This is not going to work well with a low-level and efficient language -
the extra accesses can be a significant burden for a language like C and
C++. But it can be fine for VM-based high-level languages, where the
overhead is lost in the noise, and where the VM knows when the heap
compaction has run and it needs to re-read the proxies.

> So, it turns heap fragmentation
> from denial of service type of problem to mere slowdown, hopefully
> insignificant slowdown.

For high-level VM based languages, that could be correct. But low-level
compiled and optimised languages are dependent on addresses remaining
valid, so heap compaction is not an option.

(An OS on a "big" system with an MMU can move memory pages around and
change the virtual to physical memory mapping to get more efficient use
of hierarchical virtual memory or to free up contiguous large page
areas. That is transparent to the user application code.)

> I don't say that heap compaction is impossible in other environments,
> but it is much harder, esp. in environments where pointers are visible
> to programmer. The famous David Wheeler's quote applies here at full
> force.
> Also when non-GC environments chooses to implement heap compaction they
> suffer the same or bigger impact to real-time responsiveness as GC.

Agreed.

> So, although I don't know it for sure, my impression is that generic
> heap compaction extremely rarely implemented in performance-aware
> non-GC environments.

I think that is likely.

> Performance-neglecting non-GC environments, first and foremost CPython,
> can, of course, have heap compaction, although my googling didn't give
> me a definite answer whether it's done or not.
>

CPython does use garbage collection, as far as I know.

Blue-Maned_Hawk <bluemanedhawk@invalid.invalid> writes:
> Keith Thompson wrote:
>> Blue-Maned_Hawk <bluemanedhawk@invalid.invalid> writes:
>>> Ben Bacarisse wrote:
>>>> Blue-Maned_Hawk <bluemanedhawk@invalid.invalid> writes:
>>>> <cut>
>>>>
>>>> Since you are clearly happy to post using UTF-8, can I urge you to fix
>>>> your sig so that it comes out looking right?
>>>
>>> Since it is my newsreader that is corrupting it, it is the fault of the
>>> newsreader, and therefore not within my jurisdiction of a problem to
>>> fix.
>>
>> Nope. You continue to post illegible garbage in your sig, and it's
>> annoying. I would think it would bother you as well.
>
> It does.

I believe you.

>> If there's a problem with your newsreader, have you reported it to the
>> maintainers? Have you considered using a different newsreader, or
>> finding a workaround, or changing your sig?
>
> The bugreporting system for the software does not allow anonymous
> reports. I cannot use another newsreader. There is no workaround.
> Changing my signature is not an option.

I don't believe you.

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Medtronic
void Void(void) { Void(); } /* The recursive call of the void */

On 2024-03-07, David Brown <david.brown@hesbynett.no> wrote:
> On 06/03/2024 23:00, Michael S wrote:
>> On Wed, 6 Mar 2024 12:28:59 +0000
>> bart <bc@freeuk.com> wrote:
>>
>>>
>>> "Rust uses a relatively unique memory management approach that
>>> incorporates the idea of memory “ownership”. Basically, Rust keeps
>>> track of who can read and write to memory. It knows when the program
>>> is using memory and immediately frees the memory once it is no longer
>>> needed. It enforces memory rules at compile time, making it virtually
>>> impossible to have runtime memory bugs.⁴ You do not need to manually
>>> keep track of memory. The compiler takes care of it."
>>>
>>> This suggests the language automatically takes care of this.
>>
>> Takes care of what?
>> AFAIK, heap fragmentation is as bad problem in Rust as it is in
>> C/Pascal/Ada etc... In this aspect Rust is clearly inferior to GC-based
>> languages like Java, C# or Go.
>>
> Garbage collection does not stop heap fragmentation. GC does, I
> suppose, mean that you need much more memory and bigger heaps in
> proportion to the amount of memory you actually need in the program at
> any given time, and having larger heaps reduces fragmentation (or at
> least reduces the consequences of it).

Copying garbage collectors literally stop fragmentation. Reachable
objects are identified and moved to a memory partition where they
are now adjacent. The vacated memory partition is then efficiently used
to bump-allocate new objects.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca

Blue-Maned_Hawk <bluemanedhawk@invalid.invalid> writes:

> Since it is my newsreader that is corrupting it, it is the fault of the
> newsreader, and therefore not within my jurisdiction of a problem to fix.

Looks broken here too and I damn do not care.

I just find all these replies the sig causes annoying. That'll be not
so easy to downscore. *sigh!*

Santarella, Easter-Bunny or FSM ... please bring the nigglers some
bottles of OmmmMMMmmmMMMmmm... and a new hobby!

--
I do not bite, I just want to play.

On 2024-03-07, David Brown <david.brown@hesbynett.no> wrote:
> On 07/03/2024 12:44, Michael S wrote:
>> GC does not stop fragmentation, but it allow heap compaction to be
>> built-in part of environment.
>
> No, GC alone does not do that. But heap compaction is generally done as
> part of a GC cycle.
>
> Heap compaction requires indirect pointers.

I believe, it doesn't, or doesn't have to. The garbage collector fixes
all the pointers contained in the reachable graph to point to the new
locations of objects.

If some foreign code held pointers to GC objects, that would be a
problem. That can usually be avoided. Or else, the proxy handles
can be used just for those outside references.

A simple copying garbage collector moves each object on the first
traversal and rewrites the parent pointer which it just chased
to point to the new location. Subsequent visits to the same object
then recognize that it has already been moved and just adjust the
pointer that had been traversed to reach that object. The forwarding
pointer to the new location can be stored in the old object;
most of its fields are no longer needed for anything.

The space required for the scheme can be regarded as equivalent
to fragmentation, but it's controlled.

The worst case exhibited by fragmentation (where the wasted space is
proportional to the size ratio of the largest to smallest object) is
avoided.

Now, copying collection is almost certainly inapplicable to C programs;
it's not something you "slide under" C, like Boehm. We have to think
outside of the C box. Outside of the C box, interesting things are
possible, like precisely knowing all the places that point at an
object.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca

In article <87wmqenid8.fsf@nosuchdomain.example.com>,
Leader Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
....
>I believe you.
....
>I don't believe you.

Leader Keith has spoken.

All must fall in line.

--
https://www.rollingstone.com/politics/politics-news/the-10-dumbest-things-ever-said-about-global-warming-200530/

RS contributor Bill McKibben lambasted this analysis in his 2007 book, Deep Economy.
It's nice to have microelectronics; it's necessary to have lunch, wrote McKibben.

On 3/6/24 22:06, Lawrence D'Oliveiro wrote:
> On Wed, 6 Mar 2024 19:27:24 -0500, James Kuyper wrote:
>
>> It's a constructed language, which probably has no native speakers.
>
> Not to be confused with Basic English, which was created, and copyrighted
> by, C K Ogden.

Simple English is the term used by Wikipedia for one of it's
language-specific subsets. One of it's requirements is that the articles
be written in Basic English as much as possible. See
<https://simple.wikipedia.org/wiki/Wikipedia:How_to_write_Simple_English_pages#Basic_English_and_VOA_Special_English>
for details.

On 3/7/24 03:15, Blue-Maned_Hawk wrote:
> Keith Thompson wrote:
....
>> If there's a problem with your newsreader, have you reported it to the
>> maintainers? Have you considered using a different newsreader, or
>> finding a workaround, or changing your sig?
>
> The bugreporting system for the software does not allow anonymous
> reports. I cannot use another newsreader. There is no workaround.
> Changing my signature is not an option.

Your software results in your signature being changed into the following:

"Blue-Maned_Hawk│shortens to
Hawk│/
blu.mɛin.dÊ°ak/
│he/him/his/himself/Mr.
blue-maned_hawk.srht.site
My signature used to have a cuss in it. One day, somebody quoted an
article of mine and included the signature, but censored the cuss."

As displayed on my system, that signature includes lots of capital 'A's
with tildes over them. Other people might be seeing something different,
depending upon how their systems are configured. Is that in fact what
you wanted your signature to look like?

If not, keeping your signature is also not an option. If all options are
blocked, what do you do? You'll have to figure a way to unblock one of
the options. I'm not sure what the obstacles are, but changing your
signature seems naively to be the easiest approach.

On Tue, 5 Mar 2024 22:01:01 -0800, Chris M. Thomasson wrote:

> On 3/5/2024 4:25 PM, Lawrence D'Oliveiro wrote:
>
> So, what is the right language to use?

Learn to use more than one.

On Wed, 6 Mar 2024 14:34:50 +0100, David Brown wrote:

> It used to be a running joke that if you managed to get your Ada code to
> compile, it was ready to ship.

That joke actually originated with Pascal. Though I suppose Ada took it to
the next level ...

On Thu, 7 Mar 2024 14:28:11 -0500, James Kuyper wrote:

> One of it's requirements is that the articles be written in Basic
> English as much as possible.

Interesting, because it was Ogden’s protectiveness of his copyright that
killed off any initial chance of Basic English taking off, back in the
day.

I guess that’s expired now.

On 3/7/2024 3:42 PM, Lawrence D'Oliveiro wrote:
> On Tue, 5 Mar 2024 22:01:01 -0800, Chris M. Thomasson wrote:
>
>> On 3/5/2024 4:25 PM, Lawrence D'Oliveiro wrote:
>>
>> So, what is the right language to use?
>
> Learn to use more than one.

Indeed, I do. Btw, are you an AI? Still not exactly sure why I think that.

On 07/03/2024 17:35, Kaz Kylheku wrote:
> On 2024-03-07, David Brown <david.brown@hesbynett.no> wrote:
>> On 06/03/2024 23:00, Michael S wrote:
>>> On Wed, 6 Mar 2024 12:28:59 +0000
>>> bart <bc@freeuk.com> wrote:
>>>
>>>>
>>>> "Rust uses a relatively unique memory management approach that
>>>> incorporates the idea of memory “ownership”. Basically, Rust keeps
>>>> track of who can read and write to memory. It knows when the program
>>>> is using memory and immediately frees the memory once it is no longer
>>>> needed. It enforces memory rules at compile time, making it virtually
>>>> impossible to have runtime memory bugs.⁴ You do not need to manually
>>>> keep track of memory. The compiler takes care of it."
>>>>
>>>> This suggests the language automatically takes care of this.
>>>
>>> Takes care of what?
>>> AFAIK, heap fragmentation is as bad problem in Rust as it is in
>>> C/Pascal/Ada etc... In this aspect Rust is clearly inferior to GC-based
>>> languages like Java, C# or Go.
>>>
>> Garbage collection does not stop heap fragmentation. GC does, I
>> suppose, mean that you need much more memory and bigger heaps in
>> proportion to the amount of memory you actually need in the program at
>> any given time, and having larger heaps reduces fragmentation (or at
>> least reduces the consequences of it).
>
> Copying garbage collectors literally stop fragmentation.

Yes, but garbage collectors that could be useable for C, C++, or other
efficient compiled languages are not "copying" garbage collectors.

> Reachable
> objects are identified and moved to a memory partition where they
> are now adjacent. The vacated memory partition is then efficiently used
> to bump-allocate new objects.
>

I think if you have a system with enough memory that copying garbage
collection (or other kinds of heap compaction during GC) is a reasonable
option, then it's unlikely that heap fragmentation is a big problem in
the first place. And you won't be running on a small embedded system.

On 08/03/2024 00:43, Lawrence D'Oliveiro wrote:
> On Wed, 6 Mar 2024 14:34:50 +0100, David Brown wrote:
>
>> It used to be a running joke that if you managed to get your Ada code to
>> compile, it was ready to ship.
>
> That joke actually originated with Pascal.

I didn't know that.

> Though I suppose Ada took it to
> the next level ...

It seems much more appropriate for Ada (though Pascal also had stricter
checking and stronger types than most other popular languages had when
Pascal was developed).

On Fri, 8 Mar 2024 08:25:13 +0100
David Brown <david.brown@hesbynett.no> wrote:

> On 07/03/2024 17:35, Kaz Kylheku wrote:
> > On 2024-03-07, David Brown <david.brown@hesbynett.no> wrote:
> >> On 06/03/2024 23:00, Michael S wrote:
> >>> On Wed, 6 Mar 2024 12:28:59 +0000
> >>> bart <bc@freeuk.com> wrote:
> >>>
> >>>>
> >>>> "Rust uses a relatively unique memory management approach that
> >>>> incorporates the idea of memory “ownership”. Basically, Rust
> >>>> keeps track of who can read and write to memory. It knows when
> >>>> the program is using memory and immediately frees the memory
> >>>> once it is no longer needed. It enforces memory rules at compile
> >>>> time, making it virtually impossible to have runtime memory
> >>>> bugs.⁴ You do not need to manually keep track of memory. The
> >>>> compiler takes care of it."
> >>>>
> >>>> This suggests the language automatically takes care of this.
> >>>
> >>> Takes care of what?
> >>> AFAIK, heap fragmentation is as bad problem in Rust as it is in
> >>> C/Pascal/Ada etc... In this aspect Rust is clearly inferior to
> >>> GC-based languages like Java, C# or Go.
> >>>
> >> Garbage collection does not stop heap fragmentation. GC does, I
> >> suppose, mean that you need much more memory and bigger heaps in
> >> proportion to the amount of memory you actually need in the
> >> program at any given time, and having larger heaps reduces
> >> fragmentation (or at least reduces the consequences of it).
> >
> > Copying garbage collectors literally stop fragmentation.
>
> Yes, but garbage collectors that could be useable for C, C++, or
> other efficient compiled languages are not "copying" garbage
> collectors.
>

Go, C# and Java are all efficient compiled languages. For Go it was
actually a major goal.

> > Reachable
> > objects are identified and moved to a memory partition where they
> > are now adjacent. The vacated memory partition is then efficiently
> > used to bump-allocate new objects.
> >
>
> I think if you have a system with enough memory that copying garbage
> collection (or other kinds of heap compaction during GC) is a
> reasonable option, then it's unlikely that heap fragmentation is a
> big problem in the first place. And you won't be running on a small
> embedded system.
>

You sound like arguing for sake of arguing.
Of course, heap fragmentation is relatively rare problem. But when you
process 100s of 1000s of requests of significantly varying sizes for
weeks without interruption then rare things happen with high
probability :(
In case of this particular Discord service, they appear to
have a benefit of size of requests not varying significantly, so
absence of heap compaction is not a major defect.
BTW, I'd like to know if 3 years later they still have their Rust
solution running.

07.03.2024 17:36 David Brown kirjutas:
>
> CPython does use garbage collection, as far as I know.
>

AFAIK CPython uses reference counting, i.e. basically the same as C++
std::shared_ptr (except that it does not need to be thread-safe).

With reference counting one only knows how many pointers there are to a
given heap block, but not where they are, so heap compaction would not
be straightforward.

Python also has zillions of extensions written in C or C++ (all of AI
related work for example), so having e.g. heap compaction of Python
objects only might not be worth of it.

On 08/03/2024 13:41, Paavo Helde wrote:
> 07.03.2024 17:36 David Brown kirjutas:
>>
>> CPython does use garbage collection, as far as I know.
>>
>
> AFAIK CPython uses reference counting, i.e. basically the same as C++
> std::shared_ptr (except that it does not need to be thread-safe).

Yes, that is my understanding too. (I could be wrong here, so don't
rely on anything I write!) But the way it is used is still a type of
garbage collection. When an object no longer has any "live" references,
it is put in a list, and on the next GC it will get cleared up (and call
the asynchronous destructor, __del__, for the object).

A similar method is sometimes used in C++ for objects that are
time-consuming to destruct. You have a "tidy up later" container that
holds shared pointers. Each time you make a new object that will have
asynchronous destruction, you use a shared_ptr for the access and put a
copy of that pointer in the tidy-up container. A low priority
background thread checks this list on occasion - any pointers with only
one reference can be cleared up in the context of this separate thread.

>
> With reference counting one only knows how many pointers there are to a
> given heap block, but not where they are, so heap compaction would not
> be straightforward.
>
> Python also has zillions of extensions written in C or C++ (all of AI
> related work for example), so having e.g. heap compaction of Python
> objects only might not be worth of it.
>