On Tue, 09 May 2023 17:03:18 GMT
scott@slp53.sl.home (Scott Lurndal) wrote:
>Muttley@dastardlyhq.com writes:
>>On Tue, 9 May 2023 18:17:57 +0200
>>Bonita Montero <Bonita.Montero@gmail.com> wrote:
>>>Am 09.05.2023 um 18:14 schrieb Muttley@dastardlyhq.com:
>>>
>>>> You'd still need to write your own allocator (which in turn would need
>>>realloc
>>>> internally so defeating the point) because the STL doesn't do reallocation,
>
>>>...
>>>
>>>A realloc() is the same as a further malloc(), copy and then free()
>>>of the old block. There's no difference if the container does that
>>>manually.
>>
>>No, it absolutely is not the same as that. It first inspects the current
>memory
>>block to see if it can be extended.
>
>Which is almost _never_ in the real world unless you're using
>a buddy allocator, which is wasteful of virtual address space
>(and if not paged, memory as well).

fenris$ cat t.c
#include <stdio.h>
#include <stdlib.h>

int main()
{ char *m = (char *)malloc(10000);
printf("%p\n",m);
printf("%p\n",(char *)realloc(m,10100));
return 0;
} fenris$ cc t.c; a.out
0x7fe976808800
0x7fe976808800
fenris$ uname -a
Darwin fenris 22.3.0 Darwin Kernel Version 22.3.0: Mon Jan 30 20:42:11 PST 2023;
root:xnu-8792.81.3~2/RELEASE_X86_64 x86_64

HTH

Muttley@dastardlyhq.com writes:
>On Tue, 09 May 2023 17:03:18 GMT
>scott@slp53.sl.home (Scott Lurndal) wrote:
>>Muttley@dastardlyhq.com writes:
>>>On Tue, 9 May 2023 18:17:57 +0200
>>>Bonita Montero <Bonita.Montero@gmail.com> wrote:
>>>>Am 09.05.2023 um 18:14 schrieb Muttley@dastardlyhq.com:
>>>>
>>>>> You'd still need to write your own allocator (which in turn would need
>>>>realloc
>>>>> internally so defeating the point) because the STL doesn't do reallocation,
>>
>>>>...
>>>>
>>>>A realloc() is the same as a further malloc(), copy and then free()
>>>>of the old block. There's no difference if the container does that
>>>>manually.
>>>
>>>No, it absolutely is not the same as that. It first inspects the current
>>memory
>>>block to see if it can be extended.
>>
>>Which is almost _never_ in the real world unless you're using
>>a buddy allocator, which is wasteful of virtual address space
>>(and if not paged, memory as well).
>
>fenris$ cat t.c
>#include <stdio.h>
>#include <stdlib.h>
>
>int main()
>{
> char *m = (char *)malloc(10000);
> printf("%p\n",m);
> printf("%p\n",(char *)realloc(m,10100));
> return 0;
>}
>fenris$ cc t.c; a.out
>0x7fe976808800
>0x7fe976808800
>fenris$ uname -a
>Darwin fenris 22.3.0 Darwin Kernel Version 22.3.0: Mon Jan 30 20:42:11 PST 2023;
> root:xnu-8792.81.3~2/RELEASE_X86_64 x86_64

Now try it after the app has been running for some time
doing thousands of allocations (e.g. for std::string).

Am 09.05.2023 um 19:10 schrieb Muttley@dastardlyhq.com:

> FFS, do try and keep up. Thats why I said you'd have to write your own.

Have a look at modern allocators like mimalloc, TCMalloc or jemalloc.
With that there's no in-place reallocation.

On 09/05/2023 9:21 am, Muttley@dastardlyhq.com wrote:
> On Mon, 8 May 2023 18:26:16 +0100
> Mr Flibble <flibble2@reddwarf.jmc.corp> wrote:
>> On 08/05/2023 4:49 pm, Muttley@dastardlyhq.com wrote:
>>> On Thu, 20 Apr 2023 16:59:59 +0200
>>> David Brown <david.brown@hesbynett.no> wrote:
>>>> If the data is big enough that you don't want it in your local frame,
>>>> you'll likely be using some kind of ownership class to handle the
>>>> resource and heap management in a clean RAII manner.
>>>
>>> ie globals in disguise. Which is fine, but don't pretend its some profoundly
>>> new paradigm.
>>
>> Globals in disguise? You really are a clueless idiot, nearly as bad as
>> Bonita.
>
> If the ownership object/singleton is available to the rest of the program and
> not just the function/object in question then its a global. I'm not sure what
> the issue is.

The "singleton" provides the resource allocation *service* however the
ownership object is the RAII class which is *not* available to the rest
of the program so it bares no resemblance whatsoever to a global variable.

/Flibble

On Tue, 09 May 2023 17:36:00 GMT
scott@slp53.sl.home (Scott Lurndal) wrote:
>Muttley@dastardlyhq.com writes:
>>int main()
>>{
>> char *m = (char *)malloc(10000);
>> printf("%p\n",m);
>> printf("%p\n",(char *)realloc(m,10100));
>> return 0;
>>}
>>fenris$ cc t.c; a.out
>>0x7fe976808800
>>0x7fe976808800
>>fenris$ uname -a
>>Darwin fenris 22.3.0 Darwin Kernel Version 22.3.0: Mon Jan 30 20:42:11 PST
>2023;
>> root:xnu-8792.81.3~2/RELEASE_X86_64 x86_64
>
>Now try it after the app has been running for some time
>doing thousands of allocations (e.g. for std::string).

So from "never" to after thousands of allocations. Goalpost moving, much?

Obviously if memory becomes fragmented then its less likely to happen but
the fact that it can happen at all means efficiency gains so whats your issue
with it?

On Tue, 9 May 2023 19:41:05 +0200
Bonita Montero <Bonita.Montero@gmail.com> wrote:
>Am 09.05.2023 um 19:10 schrieb Muttley@dastardlyhq.com:
>
>> FFS, do try and keep up. Thats why I said you'd have to write your own.
>
>Have a look at modern allocators like mimalloc, TCMalloc or jemalloc.
>With that there's no in-place reallocation.

How is that an advantage?

On Wednesday, 10 May 2023 at 09:16:31 UTC+1, Mut...@dastardlyhq.com wrote:
> On Tue, 9 May 2023 19:41:05 +0200
> Bonita Montero <Bonita....@gmail.com> wrote:
> >Am 09.05.2023 um 19:10 schrieb Mut...@dastardlyhq.com:
> >
> >> FFS, do try and keep up. Thats why I said you'd have to write your own.
> >
> >Have a look at modern allocators like mimalloc, TCMalloc or jemalloc.
> >With that there's no in-place reallocation.
> How is that an advantage?
>
It's not. It's just that the more modern allocator has some advantages over the
standard "free list and control block" allocator. But it doesn't have the advantage that
allocations can sometimes be extended cheaply. People must have found that, for
real programs, this is a price worth paying.

Am 10.05.2023 um 10:16 schrieb Muttley@dastardlyhq.com:

> How is that an advantage?

It's not a disadvantage.

On Wed, 10 May 2023 13:48:28 +0200
Bonita Montero <Bonita.Montero@gmail.com> wrote:
>Am 10.05.2023 um 10:16 schrieb Muttley@dastardlyhq.com:
>
>> How is that an advantage?
>
>It's not a disadvantage.

Yes, it is.

Am 10.05.2023 um 16:56 schrieb Muttley@dastardlyhq.com:

>> It's not a disadvantage.

> Yes, it is.

It's almost never a disadvantage, even more with C++23. With C++23
the allocator has an allocation_result which returns the actual size
of the assigned block, i.e. the allocation can return a larger size
than actually allocated.
With mimalloc, jemalloc and TCMalloc the requested is rounded up to
size has a power of two up to two pages. So there might be a small
advantage if the intial capacity of a vector or basic_string is ac-
tually slightly higher than requested.
With allocations beyond that size the allocation size is rounded up
to the next page size. That might also give a slight advantage but
this becomes smaller as long as the container becomes since the
"blend" is half the size of a page independently of the requested
allocation size.

On Wed, 10 May 2023 17:04:25 +0200
Bonita Montero <Bonita.Montero@gmail.com> wrote:
>Am 10.05.2023 um 16:56 schrieb Muttley@dastardlyhq.com:
>
>>> It's not a disadvantage.
>
>> Yes, it is.
>
>It's almost never a disadvantage, even more with C++23. With C++23
>the allocator has an allocation_result which returns the actual size
>of the assigned block, i.e. the allocation can return a larger size
>than actually allocated.
>With mimalloc, jemalloc and TCMalloc the requested is rounded up to
>size has a power of two up to two pages. So there might be a small

So they waste memory. Any idiot can write those sort of allocators. realloc()
is more closely integrated with the OS.

>to the next page size. That might also give a slight advantage but
>this becomes smaller as long as the container becomes since the
>"blend" is half the size of a page independently of the requested
>allocation size.

Sounds like a dumb way to do things unless you're writing an DBMS that will
be allocating huge amounts of memory on the fly. Or java, which just grabs
as much memory as it can on startup up to a specified limit.

Am 10.05.2023 um 18:00 schrieb Muttley@dastardlyhq.com:

> So they waste memory. ...

A slight amount because the internal fragmentation is not much.

> Sounds like a dumb way to do things unless you're writing an DBMS that will
> be allocating huge amounts of memory on the fly. ...

There's no perfect memory allocator. The three mentioned allocators
currently make the best compromise between blend and performance.

On 5/10/2023 2:07 AM, Malcolm McLean wrote:
> On Wednesday, 10 May 2023 at 09:16:31 UTC+1, Mut...@dastardlyhq.com wrote:
>> On Tue, 9 May 2023 19:41:05 +0200
>> Bonita Montero <Bonita....@gmail.com> wrote:
>>> Am 09.05.2023 um 19:10 schrieb Mut...@dastardlyhq.com:
>>>
>>>> FFS, do try and keep up. Thats why I said you'd have to write your own.
>>>
>>> Have a look at modern allocators like mimalloc, TCMalloc or jemalloc.
>>> With that there's no in-place reallocation.
>> How is that an advantage?
>>
> It's not. It's just that the more modern allocator has some advantages over the
> standard "free list and control block" allocator. But it doesn't have the advantage that
> allocations can sometimes be extended cheaply. People must have found that, for
> real programs, this is a price worth paying.

There is a way to implement realloc in a per-thread allocator but the
problem is that the sizes tend to be rather small to be able to do it
in-place. Its a tradeoff. So making a per-thread allocator generic is
not exactly "easy"...

Usually, at least in my per-thread allocators, we don't need to keep any
meta-data on a per-allocation basis. Instead we over allocate a super
block and aligned it on a large boundary. So, lets say we need to free a
block contained in said super block. We round the address down to the
large boundary. Then we can easily find a header structure to link the
freed block into a LIFO list. This means that the smallest a block can
be is sizeof(void*). There is no meta data that tells one how large a
block is. The requirement that a block be at least the size of a pointer
is to be able to use that space to be able to link it into the LIFO
contained in the header.

On Wed, 10 May 2023 18:19:12 +0200
Bonita Montero <Bonita.Montero@gmail.com> wrote:
>Am 10.05.2023 um 18:00 schrieb Muttley@dastardlyhq.com:
>
>> So they waste memory. ...
>
>A slight amount because the internal fragmentation is not much.
>
>> Sounds like a dumb way to do things unless you're writing an DBMS that will
>> be allocating huge amounts of memory on the fly. ...
>
>There's no perfect memory allocator. The three mentioned allocators
>currently make the best compromise between blend and performance.

Well thats your opinion. You may be right for some systems but I suspect
for common OS's with good memory management like Windows, Linux, MacOS etc
realloc() works quite nicely. If it was useless it wouldn't exist in the
first place.

Am 11.05.2023 um 10:13 schrieb Muttley@dastardlyhq.com:

> Well thats your opinion. ...

It's not my opition but all modern and performant memory allocators
are built nearly in the same way.

On Thu, 11 May 2023 13:43:49 +0200
Bonita Montero <Bonita.Montero@gmail.com> wrote:
>Am 11.05.2023 um 10:13 schrieb Muttley@dastardlyhq.com:
>
> > Well thats your opinion. ...
>
>It's not my opition but all modern and performant memory allocators
>are built nearly in the same way.

So what? They're all lowest common denominator. If you think allocating a
large number of unneeded pages and then managing the memory themselves
potentially causing page swapping slowdowns instead of simply extending the
current reserved segment is a good idea then there's a bridge for sale with
your name on it.

As I said, the only time its a good idea is if you know beforehand you're going
to need that memory very soon anyway such as in a DBMS.

Muttley@dastardlyhq.com writes:
>On Thu, 11 May 2023 13:43:49 +0200
>Bonita Montero <Bonita.Montero@gmail.com> wrote:
>>Am 11.05.2023 um 10:13 schrieb Muttley@dastardlyhq.com:
>>
>> > Well thats your opinion. ...
>>
>>It's not my opition but all modern and performant memory allocators
>>are built nearly in the same way.
>
>So what? They're all lowest common denominator. If you think allocating a
>large number of unneeded pages and then managing the memory themselves
>potentially causing page swapping slowdowns instead of simply extending the
>current reserved segment is a good idea then there's a bridge for sale with
>your name on it.
>
>As I said, the only time its a good idea is if you know beforehand you're going
>to need that memory very soon anyway such as in a DBMS.

I spent a fair amount of time in the Oracle RDBMS internals. They
never used realloc. Or malloc, for that matter.

The shared pools were using shmat (and later mmap) for allocation
and as soon as large pages (4MB on 32-bit, 2MB/1GB on 64-bit) were
available, they used mmap to allocate (the large pages, due to
alignment constraints in the MMU/TLB were statically reserved
when the system booted to ensure contiguity).

Am 11.05.2023 um 15:37 schrieb Muttley@dastardlyhq.com:

> So what? They're all lowest common denominator.

It is currently the best compromise between memory consumption and
performance. This cannot be supported on systems with extremely little
RAM, but the corresponding allocators are then much slower because
there's more synchronization.

> If you think allocating a large number of unneeded pages and then
> managing the memory themselves potentially causing page swapping
> slowdowns instead of simply extending the current reserved segment
> is a good idea then there's a bridge for sale with your name on it.

If you obtain pages from the kernel under Windows, no DRAM is assigned
to them directly, but only a corresponding amount of RAM is subtracted
from the swap, so that, in the event that the page has to be swapped
later, the corresponding swap is available. The memory for each page
reserved with MEM_COMMIT is then only actually allocated when the page
is first accessed; if necessary, swapping is then carried out. Under
Linux, the whole thing goes even further, or there no swap is deducted
at all, but the first time the page is accessed, either the application
is terminated if no memory could be allocated, or another application is
terminated so that the memory can be allocated. This is called
overcommitting and Windows only does this for stacks.

Bonita Montero <Bonita.Montero@gmail.com> writes:
>Am 11.05.2023 um 15:37 schrieb Muttley@dastardlyhq.com:
>
>> So what? They're all lowest common denominator.
>
>It is currently the best compromise between memory consumption and
>performance. This cannot be supported on systems with extremely little
>RAM, but the corresponding allocators are then much slower because
>there's more synchronization.
>
>> If you think allocating a large number of unneeded pages and then
>> managing the memory themselves potentially causing page swapping
>> slowdowns instead of simply extending the current reserved segment
>> is a good idea then there's a bridge for sale with your name on it.
>
>If you obtain pages from the kernel under Windows, no DRAM is assigned
>to them directly, but only a corresponding amount of RAM is subtracted
>from the swap, so that, in the event that the page has to be swapped
>later, the corresponding swap is available. The memory for each page
>reserved with MEM_COMMIT is then only actually allocated when the page
>is first accessed; if necessary, swapping is then carried out. Under
>Linux, the whole thing goes even further, or there no swap is deducted
>at all, but the first time the page is accessed, either the application
>is terminated if no memory could be allocated, or another application is
>terminated so that the memory can be allocated. This is called
>overcommitting and Windows only does this for stacks.

Linux only overcommits if the administrator configures it to
overcommit. It is very simple to disable overcommit at boot
if necessary for the desired workload.

The idea of overcommit originated in AIX, IIRC.

Am 11.05.2023 um 19:18 schrieb Scott Lurndal:

> Linux only overcommits if the administrator configures it to
> overcommit. ...

This is the default-behaviour which is almost never changed.

On Thu, 11 May 2023 16:06:51 GMT
scott@slp53.sl.home (Scott Lurndal) wrote:
>Muttley@dastardlyhq.com writes:
>>On Thu, 11 May 2023 13:43:49 +0200
>>Bonita Montero <Bonita.Montero@gmail.com> wrote:
>>>Am 11.05.2023 um 10:13 schrieb Muttley@dastardlyhq.com:
>>>
>>> > Well thats your opinion. ...
>>>
>>>It's not my opition but all modern and performant memory allocators
>>>are built nearly in the same way.
>>
>>So what? They're all lowest common denominator. If you think allocating a
>>large number of unneeded pages and then managing the memory themselves
>>potentially causing page swapping slowdowns instead of simply extending the
>>current reserved segment is a good idea then there's a bridge for sale with
>>your name on it.
>>
>>As I said, the only time its a good idea is if you know beforehand you're
>going
>>to need that memory very soon anyway such as in a DBMS.
>
>I spent a fair amount of time in the Oracle RDBMS internals. They
>never used realloc. Or malloc, for that matter.

Doesn't surprise me, Oracle is virtually an OS in its own right. It doesn't
(or didn't) usually use any of the built in filesystems either, prefering to
be given one or more raw partitions which it then did its own thing with. On
*nix anyway, don't know about Windows.

Am 12.05.2023 um 11:01 schrieb Muttley@dastardlyhq.com:

> Doesn't surprise me, Oracle is virtually an OS in its own right. ...

Oracle does nothing a kernel does.

> It doesn't (or didn't) usually use any of the built in filesystems
> either, prefering to be given one or more raw partitions ...

The data warehousing guide says the performance advantage of using
raw filesystems is 3% to 5% and using a normal filesytem has a lot
of advantages. I think almost any DBA choses a filesystem (I'm a
certified OCP-DBA).

Bonita Montero <Bonita.Montero@gmail.com> writes:
>Am 11.05.2023 um 19:18 schrieb Scott Lurndal:
>
>> Linux only overcommits if the administrator configures it to
>> overcommit. ...
>
>This is the default-behaviour which is almost never changed.

And you base your opinion on what experiences, exactly?

Am 12.05.2023 um 15:16 schrieb Scott Lurndal:
> Bonita Montero <Bonita.Montero@gmail.com> writes:
>> Am 11.05.2023 um 19:18 schrieb Scott Lurndal:
>>
>>> Linux only overcommits if the administrator configures it to
>>> overcommit. ...
>>
>> This is the default-behaviour which is almost never changed.
>
> And you base your opinion on what experiences, exactly?

It's required for forking software which is still common. Otherwise
you'd have to reserve a large amount of swap which is actually never
used.
And there's only one small discussion on Stack Exchange about that.

Bonita Montero <Bonita.Montero@gmail.com> writes:
>Am 12.05.2023 um 15:16 schrieb Scott Lurndal:
>> Bonita Montero <Bonita.Montero@gmail.com> writes:
>>> Am 11.05.2023 um 19:18 schrieb Scott Lurndal:
>>>
>>>> Linux only overcommits if the administrator configures it to
>>>> overcommit. ...
>>>
>>> This is the default-behaviour which is almost never changed.
>>
>> And you base your opinion on what experiences, exactly?
>
>It's required for forking software which is still common. Otherwise
>you'd have to reserve a large amount of swap which is actually never
>used.
>And there's only one small discussion on Stack Exchange about that.

Stack exchange? Not representative of production unix or linux system
operations, that's certain.