On 8/18/22 1:16 AM, Ali Çehreli wrote:
On 8/17/22 19:27, Steven Schveighoffer wrote:
> On 8/17/22 10:09 PM, Ali Çehreli wrote:
>> > IIRC, your data does not need to be sequential in *physical memory*,
>> > which means you can use a ring buffer that is segmented instead of
>> > virtually ma
On 8/17/22 19:27, Steven Schveighoffer wrote:
> On 8/17/22 10:09 PM, Ali Çehreli wrote:
>> > IIRC, your data does not need to be sequential in *physical memory*,
>> > which means you can use a ring buffer that is segmented instead of
>> > virtually mapped, and that can be of any size.
>>
>> I t
On 8/17/22 10:09 PM, Ali Çehreli wrote:
> IIRC, your data does not need to be sequential in *physical memory*,
> which means you can use a ring buffer that is segmented instead of
> virtually mapped, and that can be of any size.
I thought about that as well. But I would like the sizes of bloc
On 8/17/22 18:31, Steven Schveighoffer wrote:
> 1. I highly recommend trying out the ring buffer solution to see if it
> helps. The disadvantage here is that you need to tie up at least a page
> of memory.
I started to think holding on to multiple pages of memory should not
matter anyway. If re
On 8/17/22 2:40 PM, Ali Çehreli wrote:
On 8/16/22 19:33, Steven Schveighoffer wrote:
Using a 16-byte block sounds like a good strategy at first because
nobody knows whether an array will get more than one element.
However, if my guess is correct (i.e. the first element of size of
16-bytes is
On 8/16/22 19:33, Steven Schveighoffer wrote:
> Everything in the memory allocator is in terms of pages. A pool is a
> section of pages. The large blocks are a *multiple* of pages, whereas
> the small blocks are pages that are *divided* into same-sized chunks.
Thank you. I am appreciating this d
On 8/16/22 4:53 PM, Ali Çehreli wrote:
On 8/16/22 12:31, Steven Schveighoffer wrote:
>
> No, it's based on 2 factors:
>
> 1. Is it a page-size-or-greater block?
I assume the length of the new block.
No, the length of the *existing* block.
Everything in the memory allocator is in terms of
On Tuesday, 16 August 2022 at 18:11:54 UTC, Ali Çehreli wrote:
```d
version (good) {
// Dropping front elements equaling 2048 bytes works.
// (Likely a GC magic constant.)
enum magic = 2048;
enum elementsPerPage = magic / S.sizeof;
if (arr.length == elementsPer
Thank you for the quick response.
On 8/16/22 12:31, Steven Schveighoffer wrote:
> On 8/16/22 2:11 PM, Ali Çehreli wrote:
>> Related to my DConf 2022 lightning talk, I am noticing that D
>> runtime's in-place array extension optimization is available only for
>> array data that are at certain memo
On 8/16/22 2:11 PM, Ali Çehreli wrote:
Related to my DConf 2022 lightning talk, I am noticing that D runtime's
in-place array extension optimization is available only for array data
that are at certain memory alignments.
No, it's based on 2 factors:
1. Is it a page-size-or-greater block?
2.
Related to my DConf 2022 lightning talk, I am noticing that D runtime's
in-place array extension optimization is available only for array data
that are at certain memory alignments.
I used the following program to test it. In addition to repeatedly
adding an element to an array,
- 'version =
11 matches
Mail list logo
