On 06/03/2024 04:43, Mr. Man-wai Chang wrote:
> On 5/3/2024 9:51 pm, Mr. Man-wai Chang wrote:
>> On 3/3/2024 7:13 am, Lynn McGuire wrote:
>>>
>>> "The Biden administration backs a switch to more memory-safe programming
>>> languages. The tech industry sees their point, but it won't be easy."
>>>
>>> No.  The feddies want to regulate software development very much.  They
>>> have been talking about it for at least 20 years now.  This is a very
>>> bad thing.
>>
>> A responsible, good progreammer or a better C/C++ pre-processor can
>> avoid a lot of problems!!
>
> Or maybe A.I.-assisted code analyzer?? But there are still blind spots...

I think AI could be used and give goods result but it is not ideal.
The advantage of AI it could understand patterns. Like the names init
and destroy could work as tips or patterns.

However, I think programming needs a formal language for contracts and
the static analysis needs to check them.
Also ideally is better contracts for the interface rather having to see
the body of the functions.

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.

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.

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

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