On 4/28/2024 5:05 PM, Lawrence D'Oliveiro wrote:
> On Fri, 8 Mar 2024 14:41:16 +0200, Paavo Helde wrote:
>
>> AFAIK CPython uses reference counting ...
>
> Combination of reference-counting as a first resort, with full garbage
> collection to deal with those less common cases where you have reference
> cycles. Trying to get the best of both worlds.
>
> The trouble with reference-counting is it impacts multithreading
> performance. However, the CPython developers have a scheme to deal with
> this, by making the reference counts a little less deterministic (i.e.
> there may be a slight delay before they become fully correct). I think
> this is a complicated idea, and it may take them some time to get it fully
> implemented.

Are you an AI?

On Sun, 10 Mar 2024 18:47:42 GMT, Scott Lurndal wrote:

> I've seen a lot of open source code
> that uses strdup without checking for failure and frequently
> "forgetting" to free the result.

I was looking at the systemd source code the other day, and came across a
lot of this sort of thing:

_cleanup_free_ char *link = NULL;

Now, what do you suppose “_cleanup_free_” does?

On 2024-04-29, Chris M. Thomasson <chris.m.thomasson.1@gmail.com> wrote:
> Are you an AI?

That entails two separable propositions; there is moderate evidence for
the one, scant for the other.

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

On 4/28/2024 6:58 PM, Kaz Kylheku wrote:
> On 2024-04-29, Chris M. Thomasson <chris.m.thomasson.1@gmail.com> wrote:
>> Are you an AI?
>
> That entails two separable propositions; there is moderate evidence for
> the one, scant for the other.
>

Are you a human?

If so, are you using AI?

If not, are you an AI?

Any better?

On 2024-04-29, Chris M. Thomasson <chris.m.thomasson.1@gmail.com> wrote:
> On 4/28/2024 6:58 PM, Kaz Kylheku wrote:
>> On 2024-04-29, Chris M. Thomasson <chris.m.thomasson.1@gmail.com> wrote:
>>> Are you an AI?
>>
>> That entails two separable propositions; there is moderate evidence for
>> the one, scant for the other.
>>
>
> Are you a human?
>
> If so, are you using AI?
>
> If not, are you an AI?
>
> Any better?

Rather, the separable propositions are:

- is it (A)rtificial; and
- is it (I)ntelligent

If you can confirm both, you have AI, but there are other possibilities.

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

In comp.lang.c Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
> On Fri, 8 Mar 2024 15:32:22 +0100, David Brown wrote:
>
>> And it will be tough on the cache as everything has to be copied and
>> moved.
>
> I think all kinds of garbage collector end up being tough on the
> cache. Because remember, they are doing things with lots of blocks
> of memory that haven’t been accessed recently, and therefore are not
> likely to be in the cache.

Not usually. Most garbage dies young, so the GC will be scanning
recently-allocated regions first. There's no strict need to scan old
regions unless the program starts to run short of memory. You might
have a periodic thread to do so, to reclaim some extra space.

Andrew.

On 29.04.2024 03:05, Lawrence D'Oliveiro wrote:
> On Fri, 8 Mar 2024 14:41:16 +0200, Paavo Helde wrote:
>
>> AFAIK CPython uses reference counting ...
>
> Combination of reference-counting as a first resort, with full garbage
> collection to deal with those less common cases where you have reference
> cycles. Trying to get the best of both worlds.
>
> The trouble with reference-counting is it impacts multithreading
> performance.

Maybe only in case of heavy contention. If there is little contention
and the reference counter is implemented as an atomic variable, there is
no measurable hit on performance. I know this because I was suspicious
myself and measured this recently.

Anyway, multithreading performance is a non-issue for Python so far as
the Python interpreter runs in a single-threaded regime anyway, under a
global GIL lock. They are planning to get rid of GIL, but this work is
still in development AFAIK. I'm sure it will take years to stabilize the
whole Python zoo without GIL.

However, the CPython developers have a scheme to deal with
> this, by making the reference counts a little less deterministic (i.e.
> there may be a slight delay before they become fully correct). I think
> this is a complicated idea, and it may take them some time to get it fully
> implemented.

Lawrence D'Oliveiro <ldo@nz.invalid> writes:

> I was looking at the systemd source code the other day, and came across a
> lot of this sort of thing:
>
> _cleanup_free_ char *link = NULL;
>
> Now, what do you suppose “_cleanup_free_” does?

It's a dark magic of GCC to automatically free the memory when pointer
goes out of scope.

On 4/28/2024 9:28 PM, Kaz Kylheku wrote:
> On 2024-04-29, Chris M. Thomasson <chris.m.thomasson.1@gmail.com> wrote:
>> On 4/28/2024 6:58 PM, Kaz Kylheku wrote:
>>> On 2024-04-29, Chris M. Thomasson <chris.m.thomasson.1@gmail.com> wrote:
>>>> Are you an AI?
>>>
>>> That entails two separable propositions; there is moderate evidence for
>>> the one, scant for the other.
>>>
>>
>> Are you a human?
>>
>> If so, are you using AI?
>>
>> If not, are you an AI?
>>
>> Any better?
>
> Rather, the separable propositions are:
>
> - is it (A)rtificial; and
> - is it (I)ntelligent
>
> If you can confirm both, you have AI, but there are other possibilities.
>

Touche! Thanks.

On 4/29/2024 2:45 AM, paavo512 wrote:
> On 29.04.2024 03:05, Lawrence D'Oliveiro wrote:
>> On Fri, 8 Mar 2024 14:41:16 +0200, Paavo Helde wrote:
>>
>>> AFAIK CPython uses reference counting ...
>>
>> Combination of reference-counting as a first resort, with full garbage
>> collection to deal with those less common cases where you have reference
>> cycles. Trying to get the best of both worlds.
>>
>> The trouble with reference-counting is it impacts multithreading
>> performance.
>
> Maybe only in case of heavy contention. If there is little contention
> and the reference counter is implemented as an atomic variable, there is
> no measurable hit on performance. I know this because I was suspicious
> myself and measured this recently.

All of the memory barriers and atomic ops in general reference counting
can become a rather big issue. Now, there are specialized types of
reference counting... Think of proxy reference counting. This can
amortize the counting and can give pretty good performance. Not as good
as RCU, but not that bad!

>
> Anyway, multithreading performance is a non-issue for Python so far as
> the Python interpreter runs in a single-threaded regime anyway, under a
> global GIL lock. They are planning to get rid of GIL, but this work is
> still in development AFAIK. I'm sure it will take years to stabilize the
> whole Python zoo without GIL.
>
>
> However, the CPython developers have a scheme to deal with
>> this, by making the reference counts a little less deterministic (i.e.
>> there may be a slight delay before they become fully correct). I think
>> this is a complicated idea, and it may take them some time to get it
>> fully
>> implemented.
>

paavo512 <paavo@osa.pri.ee> writes:
>On 29.04.2024 03:05, Lawrence D'Oliveiro wrote:
>> On Fri, 8 Mar 2024 14:41:16 +0200, Paavo Helde wrote:
>>
>>> AFAIK CPython uses reference counting ...
>>
>> Combination of reference-counting as a first resort, with full garbage
>> collection to deal with those less common cases where you have reference
>> cycles. Trying to get the best of both worlds.
>>
>> The trouble with reference-counting is it impacts multithreading
>> performance.
>
>Maybe only in case of heavy contention. If there is little contention
>and the reference counter is implemented as an atomic variable, there is
>no measurable hit on performance. I know this because I was suspicious
>myself and measured this recently.
>
>Anyway, multithreading performance is a non-issue for Python so far as
>the Python interpreter runs in a single-threaded regime anyway, under a
>global GIL lock. They are planning to get rid of GIL, but this work is
>still in development AFAIK. I'm sure it will take years to stabilize the
>whole Python zoo without GIL.

We use the python shim (SWIG) to run a multithreaded C++ application (well
over a hundred threads in some cases). It's only the calls back
into python that end up single threaded - the application itself happily
runs multithreaded (and never calls back into python at all).

i@fuzy.me writes:

> Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>
< > I was looking at the systemd source code the other day, and came across a
< > lot of this sort of thing:
< >
< > _cleanup_free_ char *link = NULL;
< >
< > Now, what do you suppose “_cleanup_free_” does?
>

I usually use void * , probably a struct of some sort for marking
garbage.

> It's a dark magic of GCC to automatically free the memory when pointer
> goes out of scope.

Try alloca - for stack loading; there is a garbage collector for C . The
Boehm-Demers-Weiser conservative can be used in place of malloc.

with gcc you can stack allocate with nested functions, like in object pascal.

``
A “nested function” is a function defined inside another function.
Nested functions are supported as an extension in GNU C, but are not
supported by GNU C++.

The nested function's name is local to the block where it is defined.
For example, here we define a nested function named ‘square’, and call
it twice:

foo (double a, double b)
{
double square (double z) { return z * z; }

return square (a) + square (b);
}

from the gcc info manual.
''

have fun; gcc is a greate compiler.