In comp.lang.c Michael S <already5chosen@yahoo.com> wrote:
> On Tue, 5 Mar 2024 22:58:10 -0000 (UTC)
> Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
>
>> On Tue, 5 Mar 2024 11:11:03 +0200, Michael S wrote:
>>
>> > On Tue, 5 Mar 2024 01:54:46 -0000 (UTC)
>> > Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
>> >
>> >> Discord did some benchmarking of its back-end servers, which had
>> >> been using Go, and decided that switching to Rust offered better
>> >> performance.
>> >
>> > - for big and complex real-world back-end processing, writing
>> > working solution in go will take 5 time less man hours than writing
>> > it in Rust
>>
>> Nevertheless, they found the switch to Rust worthwhile.
>
> I read a little more about it.
> https://discord.com/blog/why-discord-is-switching-from-go-to-rust
>
> Summary: performance of one of Discord's most heavy-duty servers
> suffered from weakness in implementation of Go garbage collector. On
> average the performance was satisfactory, but every two minutes there
> was spike in latency. The latency during the spike was not that big
> (300 msec), but they stilled were feeling that they want better.

....

> I have few questions about the story, most important one is whether the
> weakness of this sort is specific to GC of Go, due to its relative
> immaturity

I'm sure it is. 300ms is terrible.

> or more general and applies equally to most mature GCs on the
> market, i.e. J2EE and .NET.

Continuously-compacting concurrent collectors like those available for
Java aim for less than 10ms, and often hit 1ms. You have to stop each
thread briefly to scan its stack and do a few other things, but that's
all.

Andrew.

On 06/03/2024 14:18, Michael S wrote:
> On Wed, 6 Mar 2024 13:50:16 +0000
> bart <bc@freeuk.com> wrote:

>> Whoever wrote this short Wikipedia article on it got confused too as
>> it uses both Ada and ADA:
>>
>> https://simple.wikipedia.org/wiki/Ada_(programming_language)
>>
>> (The example program also includes 'Ada' as some package name. Since
>> it is case-insensitive, 'ADA' would also work.)
>>
>
> Your link is to "simple Wikipedia". I don't know what it is
> exactly, but it does not appear as authoritative as real Wikipedia
>
> https://en.wikipedia.org/wiki/Ada_(programming_language)
>
>> Here's also a paper that uses 'ADA' (I assume it is the same
>> language):
>>
>> https://www.sciencedirect.com/science/article/abs/pii/0166361582900136
>>
>
> The article published 1982. The language became official in 1983.
> Possibly, in 1982 there still was a confusion w.r.t. its name.

It would have been know it was named after a person. (I think Lovelace
would have been better though.)

>> Personally I'm not bothered whether anyone uses Ada or ADA. Is 'C'
>> written in all-caps or only capitalised? You can't tell!
>>
>
> If only ADA, written in upper case, was not widely used for something
> else...

I don't know what that is without looking it up. In a programming
newsgroup I expect ADA to be the language.

BTW it's a good thing that C, written in upper case, can never be
confused with anything else...

bart <bc@freeuk.com> writes:
[...]
> Whoever wrote this short Wikipedia article on it got confused too as
> it uses both Ada and ADA:
>
> https://simple.wikipedia.org/wiki/Ada_(programming_language)

Fixed.

[...]

--
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 3/6/24 09:18, Michael S wrote:
> On Wed, 6 Mar 2024 13:50:16 +0000
> bart <bc@freeuk.com> wrote:
....
>> Whoever wrote this short Wikipedia article on it got confused too as
>> it uses both Ada and ADA:
>>
>> https://simple.wikipedia.org/wiki/Ada_(programming_language)
>>
>> (The example program also includes 'Ada' as some package name. Since
>> it is case-insensitive, 'ADA' would also work.)
>>
>
> Your link is to "simple Wikipedia". I don't know what it is
> exactly, but it does not appear as authoritative as real Wikipedia

Notice that in your following link, "en" appears at the beginning to
indicate the use of English. "simple" at the beginning of the above link
serves the same purpose. "Simple English" is it's own language, closely
related to standard English. Read the corresponding Wikipedia article
for more details.

On 06/03/2024 14:38, bart wrote:
> On 06/03/2024 14:18, Michael S wrote:

>> If only ADA, written in upper case, was not widely used for something
>> else...
>
> I don't know what that is without looking it up. In a programming
> newsgroup I expect ADA to be the language.

Here's an interesting pic:

https://upload.wikimedia.org/wikipedia/commons/5/50/AdaLovelaceplaque.JPG

Notice the upper-case name.

bart <bc@freeuk.com> writes:
>On 06/03/2024 14:38, bart wrote:
>> On 06/03/2024 14:18, Michael S wrote:
>
>>> If only ADA, written in upper case, was not widely used for something
>>> else...
>>
>> I don't know what that is without looking it up. In a programming
>> newsgroup I expect ADA to be the language.
>
>Here's an interesting pic:
>
>https://upload.wikimedia.org/wikipedia/commons/5/50/AdaLovelaceplaque.JPG
>
>Notice the upper-case name.

Given that the entire name is in all uppercase, and it's not referring
to the computer language, what is your point, if any?

On 2024-03-06, James Kuyper <jameskuyper@alumni.caltech.edu> wrote:
> On 3/6/24 09:18, Michael S wrote:
>> On Wed, 6 Mar 2024 13:50:16 +0000
>> bart <bc@freeuk.com> wrote:
> ...
>>> Whoever wrote this short Wikipedia article on it got confused too as
>>> it uses both Ada and ADA:
>>>
>>> https://simple.wikipedia.org/wiki/Ada_(programming_language)
>>>
>>> (The example program also includes 'Ada' as some package name. Since
>>> it is case-insensitive, 'ADA' would also work.)
>>>
>>
>> Your link is to "simple Wikipedia". I don't know what it is
>> exactly, but it does not appear as authoritative as real Wikipedia
>
> Notice that in your following link, "en" appears at the beginning to
> indicate the use of English. "simple" at the beginning of the above link
> serves the same purpose. "Simple English" is it's own language, closely
> related to standard English.

Where is Simple English spoken? Is there some geographic area where
native speakers concentrate?

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

On 06/03/2024 20:50, Kaz Kylheku wrote:
> On 2024-03-06, James Kuyper <jameskuyper@alumni.caltech.edu> wrote:
>> On 3/6/24 09:18, Michael S wrote:
>>> On Wed, 6 Mar 2024 13:50:16 +0000
>>> bart <bc@freeuk.com> wrote:
>> ...
>>>> Whoever wrote this short Wikipedia article on it got confused too as
>>>> it uses both Ada and ADA:
>>>>
>>>> https://simple.wikipedia.org/wiki/Ada_(programming_language)
>>>>
>>>> (The example program also includes 'Ada' as some package name. Since
>>>> it is case-insensitive, 'ADA' would also work.)
>>>>
>>>
>>> Your link is to "simple Wikipedia". I don't know what it is
>>> exactly, but it does not appear as authoritative as real Wikipedia
>>
>> Notice that in your following link, "en" appears at the beginning to
>> indicate the use of English. "simple" at the beginning of the above link
>> serves the same purpose. "Simple English" is it's own language, closely
>> related to standard English.
>
> Where is Simple English spoken? Is there some geographic area where
> native speakers concentrate?
>

It is meant to be simpler text, written in simpler language. The target
audience will include younger people, people with dyslexia or other
reading difficulties, learners of English, people with lower levels of
education, people with limited intelligence or learning impediments, or
simply people whose eyes glaze over when faced with long texts on the
main Wikipedia pages.

On Wed, 6 Mar 2024 12:28:59 +0000
bart <bc@freeuk.com> wrote:

> On 06/03/2024 12:02, Michael S wrote:
> > On Tue, 5 Mar 2024 22:58:10 -0000 (UTC)
> > Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
> >
> >> On Tue, 5 Mar 2024 11:11:03 +0200, Michael S wrote:
> >>
> >>> On Tue, 5 Mar 2024 01:54:46 -0000 (UTC)
> >>> Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
> >>>
> >>>> Discord did some benchmarking of its back-end servers, which had
> >>>> been using Go, and decided that switching to Rust offered better
> >>>> performance.
> >>>
> >>> - for big and complex real-world back-end processing, writing
> >>> working solution in go will take 5 time less man hours than
> >>> writing it in Rust
> >>
> >> Nevertheless, they found the switch to Rust worthwhile.
> >
> > I read a little more about it.
> > https://discord.com/blog/why-discord-is-switching-from-go-to-rust
> >
> > Summary: performance of one of Discord's most heavy-duty servers
> > suffered from weakness in implementation of Go garbage collector. On
> > average the performance was satisfactory, but every two minutes
> > there was spike in latency. The latency during the spike was not
> > that big (300 msec), but they stilled were feeling that they want
> > better. They tried to tune GC, but the problem appeared to be
> > fundamental. So they just rewrote this particular server in Rust.
> > Naturally, Rust does not collect garbage, so this particular
> > problem disappeared.
> >
> > The key phrase of the story is "This service was a great candidate
> > to port to Rust since it was small and self-contained".
> > I'd add to this that even more important for eventual success of
> > migration was the fact that at time of rewrite server was already
> > running for several years, so requirements were stable and
> > well-understood.
> > Another factor is that their service does not create/free that many
> > objects. The delay was caused by mere fact of GC scanning rather
> > than by frequent compacting of memory pools. So, from the beginning
> > it was obvious that potential fragmentation of the heap, which is
> > the main weakness of "plain" C/C++/Rust based solutions for Web
> > back-ends, does not apply in their case.
>
> From the same link:
>
> "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.

> But you
> have to write your programs in a certain way to make it possible. The
> programmer has to help the language keep track of what owns what.
>
> So you will probably be able to do the same thing in another
> language. But Rust will do more compile-time enforcement by
> restricting how you share objects in memory.
>
>

On 3/6/2024 5:34 AM, David Brown wrote:
> On 05/03/2024 23:02, Chris M. Thomasson wrote:
>> On 3/5/2024 1:58 PM, Keith Thompson wrote:
>>> Kaz Kylheku <433-929-6894@kylheku.com> writes:
>>>> On 2024-03-05, Chris M. Thomasson <chris.m.thomasson.1@gmail.com>
>>>> wrote:
>>>>> On 3/5/2024 2:27 AM, David Brown wrote:
>>>>>> On 05/03/2024 08:08, Lawrence D'Oliveiro wrote:
>>>>>>> On Tue, 5 Mar 2024 00:03:54 -0600, Lynn McGuire wrote:
>>>>>>>
>>>>>>>> On 3/3/2024 11:43 PM, Lawrence D'Oliveiro wrote:
>>>>>>>>
>>>>>>>>> Did you know the life-support system on the
>>>>>>>>> International Space Station was written in Ada? Not something
>>>>>>>>> you would
>>>>>>>>> trust C++ code to, let’s face it.
>>>>>>>>
>>>>>>>> Most of the Ada code was written in C or C++ and converted to
>>>>>>>> Ada for
>>>>>>>> delivery.
>>>>>>>
>>>>>>> Was it debugged again? Or was it assumed that the translation was
>>>>>>> bug-
>>>>>>> free?
>>>>>>
>>>>>> With Ada, if you can get it to compile, it's ready to ship :-)
>>>>>>
>>>>> Really? Any logic errors in the program itself?
>>>>
>>>> Ariane 5 rocket incident of 1996: The Ada code didn't catch the
>>>> hardware
>>>> overflow exception from forcing a 64 bit floating-point value into a 16
>>>> bit integer. The situation was not expected by the code which was
>>>> developed for the Ariane 4, or something like that.
>>>
>>> A numeric overflow occurred during the Ariane 5's initial flight -- and
>>> the software *did* catch the overflow.  The same overflow didn't occur
>>> on Ariane 4 because of its different flight profile.  There was a
>>> management decision to reuse the Ariane 4 flight software for Ariane 5
>>> without sufficient review.
>>>
>>> The code (which had been thoroughly tested on Ariane 4 and was known not
>>> to overflow) emitted an error message describing the overflow exception.
>>> That error message was then processed as data.  Another problem was that
>>> systems were designed to shut down on any error; as a result, healthy
>>> and necessary equipment was shut down prematurely.
>>>
>>> This is from my vague memory, and may not be entirely accurate.
>
> That matches my recollection too.
>
>>>
>>> *Of course* logic errors are possible in Ada programs, but in my
>>> experience and that of many other programmers, if you get an Ada program
>>> to compile (and run without raising unhandled exceptions), you're likely
>>> to be much closer to a working program than if you get a C program to
>>> compile.  A typo in a C program is more likely to result in a valid
>>> program with different semantics.
>>>
>>
>> So close you can just feel its a 100% correct and working program?
>
> Didn't you notice the smiley in my comment?  It used to be a running
> joke that if you managed to get your Ada code to compile, it was ready
> to ship.  The emphasis is on the word "joke".
>

You jest whooshed over my head. Sorry! Humm, well, shit. ;^o

On 3/6/2024 5:31 AM, David Brown wrote:
> On 05/03/2024 23:34, Chris M. Thomasson wrote:
>> On 3/5/2024 2:11 PM, Keith Thompson wrote:
>>> "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes:
>>> [...]
>>>> ADA is bullet proof... Until its not... ;^)
>>>
>>> The language is called Ada, not ADA.
>>
>> I wonder how many people got confused?
>>
>
> Apparently you and Malcolm got confused.
>
> Others who mentioned the language know it is called "Ada".  I not only
> corrected you, but gave an explanation of it, in the hope that with that
> clarity, you'd learn.
>

ADA = nothing
Ada = the language of Ada

Got it.

On 3/6/2024 2:43 AM, David Brown wrote:
> On 05/03/2024 21:51, Chris M. Thomasson wrote:
>> On 3/5/2024 1:01 AM, David Brown wrote:
>>> On 04/03/2024 21:36, Chris M. Thomasson wrote:
>>>> On 3/4/2024 12:44 AM, David Brown wrote:
>>>>> On 03/03/2024 23:01, Chris M. Thomasson wrote:
>>>>>> On 3/3/2024 12:23 PM, David Brown wrote:
>>>>>>> On 03/03/2024 19:18, Kaz Kylheku wrote:
>>>>>
>>>>>>>> Embedded systems often need custom memory management, not
>>>>>>>> something that
>>>>>>>> the language imposes. C has malloc, yet even that gets disused
>>>>>>>> in favor
>>>>>>>> of something else.
>>>>>>>>
>>>>>>>
>>>>>>> For safe embedded systems, you don't want memory management at
>>>>>>> all. Avoiding dynamic memory is an important aspect of
>>>>>>> safety-critical embedded development.
>>>>>>>
>>>>>>
>>>>>> You still have to think about memory management even if you avoid
>>>>>> any dynamic memory? How are you going to mange this memory wrt
>>>>>> your various data structures needs....
>>>>>
>>>>> To be clear here - sometimes you can't avoid all use of dynamic
>>>>> memory and therefore memory management.  And as Kaz says, you will
>>>>> often use custom solutions such as resource pools rather than
>>>>> generic malloc/free.   Flexible network communication (such as
>>>>> Ethernet or other IP networking) is hard to do without dynamic memory.
>>>> [...]
>>>>
>>>> Think of using a big chunk of memory, never needed to be freed and
>>>> is just there per process. Now, you carve it up and store it in a
>>>> cache that has functions push and pop. So, you still have to manage
>>>> memory even when you are using no dynamic memory at all... Fair
>>>> enough, in a sense? The push and the pop are your malloc and free in
>>>> a strange sense...
>>>>
>>>
>>> I believe I mentioned that.  You do not, in general, "push and pop" -
>>> you malloc and never free.  Excluding debugging code and other parts
>>> useful in testing and developing, you have something like :
>>>
>>> enum { heap_size = 16384; }
>>> alignas(max_align_t) static uint8_t heap[heap_size];
>>> uint8_t * next_free = heap;
>>>
>>> void free(void * ptr) {
>>>      (void) ptr;
>>> }
>>>
>>> void * malloc(size_t size) {
>>>      const size_t align = alignof(max_align_t);
>>>      const real_size = size ? (size + (align - 1)) & ~(align - 1)
>>>                  : align;
>>>      void * p = next_free;
>>>      next_free += real_size;
>>>      return p;
>>> }
>>>
>>>
>>> Allowing for pops requires storing the size of the allocations
>>> (unless you change the API from that of malloc/free), and is only
>>> rarely useful.   Generally if you want memory that temporary, you use
>>> a VLA or alloca to put it on the stack.
>>>
>>
>> wrt systems with no malloc/free I am thinking more along the lines of
>> a region allocator mixed with a LIFO for a cache, so a node based
>> thing. The region allocator gets fed with a large buffer. Depending on
>> specific needs, it can work out nicely for systems that do not have
>> malloc/free. The pattern I used iirc, was something like:
>>
>> // pseudo code...
>> _______________________
>> node*
>> node_pop()
>> {
>>      // try the lifo first...
>>
>>      node* n = lifo_pop();
>>
>>      if (! n)
>>      {
>>          // resort to the region allocator...
>>
>>          n = region_allocate_node();
>>
>>          // note, n can be null here.
>>          // if it is, we are out of memory.
>>
>>          // note, out of memory on a system
>>          // with no malloc/free...
>>      }
>>
>>      return n;
>> }
>>
>> void
>> node_push(
>>      node* n
>> ) {
>>       lifo_push(n);
>> }
>> _______________________
>>
>>
>> make any sense to you?
>>
>
> I know what you are trying to suggest, and I understand how it can sound
> reasonable.  In some cases, this can be a useful kind of allocator, and
> when it is suitable, it is very fast.  But it is has two big issues for
> small embedded systems.
>
> One problem is the "region_allocate_node()" - getting a lump of space
> from the underlying OS.  That is fine on "big systems", and it is normal
> that malloc/free systems only ask for memory from the OS in big lumps,
> then handle local allocation within the process space for efficiency.
> (This can work particularly well if each thread gets dedicated lumps, so
> that no locking is needed for most malloc/free calls.)
>
> But in a small embedded system, there is no OS (an RTOS is generally
> part of the same binary as the application), and providing such "lumps"
> would be dynamic memory management.  So if you are using a system like
> you describe, then you would have a single statically allocated block of
> memory for your lifo stack.
>
> Then there is the question of how often such a stack-like allocator is
> useful, independent of the normal stack.  I can imagine it is
> /sometimes/ helpful, but rarely.  I can't think off-hand of any cases
> where I would have found it useful in anything I have written.
>
> As I (and others) have said elsewhere, in small embedded systems and
> safety or reliability critical systems, you want to avoid dynamic memory
> and memory management whenever possible, for a variety of reasons.  If
> you do need something, then specialise allocators are more common -
> possibly including lifos like this.
>
> But it's more likely to have fixed-size pools with fixed-size elements,
> dedicated to particular memory tasks.  For example, if you need to track
> multiple in-flight messages on a wireless mesh network, where messages
> might take different amounts of time to be delivered and acknowledged,
> or retried, you define a structure that holds all the data you need for
> a message.  Then you decide how many in-flight messages you will support
> as a maximum.  This gives you a statically allocated array of N structs.
>  Block usage is then done by a bitmap, typically within a single 32-bit
> word.  Finding a free slot is a just finding the first free zero, and
> freeing it is clearing the correct bit.
>
> There are, of course, many other kinds of dedicated allocators that can
> be used in other circumstances.
>

Fair enough. :^)

On 3/6/24 14:50, Kaz Kylheku wrote:
> On 2024-03-06, James Kuyper <jameskuyper@alumni.caltech.edu> wrote:
....
>> Notice that in your following link, "en" appears at the beginning to
>> indicate the use of English. "simple" at the beginning of the above link
>> serves the same purpose. "Simple English" is it's own language, closely
>> related to standard English.
>
> Where is Simple English spoken? Is there some geographic area where
> native speakers concentrate?

It's a constructed language, which probably has no native speakers. See
<https://en.wikipedia.org/wiki/Constructed_language>. Wikipedia has
articles in several constructed languages. The two biggest such
languages are Esperanto, with 350,598, and Simple English with 248,540.

On Wed, 6 Mar 2024 14:02:14 +0200, Michael S wrote:

> Another factor is that their service does not create/free that many
> objects. The delay was caused by mere fact of GC scanning rather than
> by frequent compacting of memory pools.

In other words, a GC language could not even cope reasonably with a light
memory-management load.

On Wed, 6 Mar 2024 12:28:59 +0000, bart wrote:

> This suggests the language automatically takes care of this. But you
> have to write your programs in a certain way to make it possible.

You are forced to by default, because if you don’t follow the rules,
that’s a compile-time error.

On Wed, 06 Mar 2024 14:30:58 +0000, aph wrote:

> Continuously-compacting concurrent collectors like those available for
> Java aim for less than 10ms, and often hit 1ms.

What ... a 1ms potential delay every time you want to allocate a new
object??

On 3/6/2024 5:46 PM, Lawrence D'Oliveiro wrote:
> On Wed, 06 Mar 2024 14:30:58 +0000, aph wrote:
>
>> Continuously-compacting concurrent collectors like those available for
>> Java aim for less than 10ms, and often hit 1ms.
>
> What ... a 1ms potential delay every time you want to allocate a new
> object??

GC can be a no go for certain schemes. GC can be fine and it has its place.

On 2024-03-07, Chris M. Thomasson <chris.m.thomasson.1@gmail.com> wrote:
> On 3/6/2024 5:46 PM, Lawrence D'Oliveiro wrote:
>> On Wed, 06 Mar 2024 14:30:58 +0000, aph wrote:
>>
>>> Continuously-compacting concurrent collectors like those available for
>>> Java aim for less than 10ms, and often hit 1ms.
>>
>> What ... a 1ms potential delay every time you want to allocate a new
>> object??
>
> GC can be a no go for certain schemes. GC can be fine and it has its place.

It is the situations where GC cannot be used that are niches that have
their place. Everywhere else, you can use GC.

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

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.

On 3/6/2024 6:37 PM, Kaz Kylheku wrote:
> On 2024-03-07, Chris M. Thomasson <chris.m.thomasson.1@gmail.com> wrote:
>> On 3/6/2024 5:46 PM, Lawrence D'Oliveiro wrote:
>>> On Wed, 06 Mar 2024 14:30:58 +0000, aph wrote:
>>>
>>>> Continuously-compacting concurrent collectors like those available for
>>>> Java aim for less than 10ms, and often hit 1ms.
>>>
>>> What ... a 1ms potential delay every time you want to allocate a new
>>> object??
>>
>> GC can be a no go for certain schemes. GC can be fine and it has its place.
>
> It is the situations where GC cannot be used that are niches that have
> their place. Everywhere else, you can use GC.
>

Touche! :^)

Lawrence D'Oliveiro wrote:

> On Sun, 3 Mar 2024 22:11:14 -0000 (UTC), Blue-Maned_Hawk wrote:
>
>> Lawrence D'Oliveiro wrote:
>>
>>> On Sun, 3 Mar 2024 08:54:36 -0000 (UTC), Blue-Maned_Hawk wrote:
>>>
>>>> I do not want to live in a web-centric world.
>>>
>>> You already do.
>>
>> That does not change the veracity of my statement.
>
> That doesn’t change the veracity of mine.

Then our collective fingertips have done nothing in their plasticsmacking.

--
Blue-Maned_Hawk│shortens to
Hawk│/
blu.mɛin.dÊ°ak/
│he/him/his/himself/Mr.
blue-maned_hawk.srht.site
FORE!

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

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.

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