Hacker News: dev_dwarf

New comment by dev_dwarf in "My personal C coding style as of late 2023"

dev_dwarf — Mon, 09 Oct 2023 23:02:12 +0000

You'll find by looking at their older posts that the author has actually written quite a lot of elisp.

New comment by dev_dwarf in "Arena allocator tips and tricks"

dev_dwarf — Wed, 27 Sep 2023 19:52:00 +0000

Your second paragraph doesn't make sense because the whole point of this type of allocation is to guarantee that you will reuse the same address space you just freed.

New comment by dev_dwarf in "Always Bump Downwards (2019)"

dev_dwarf — Tue, 19 Sep 2023 20:59:08 +0000

Thats an interesting idea. I'm not sure I'm sold on it v.s. just having two seperate allocators and growing them seperately. The arena allocators I use take advantage of virtual memory to grow which might change my perception of the tradeoffs involved, as I wouldn't typically need to resize one of my allocators (you can just aggressively over-reserve memory and then only commit what is actually used).

New comment by dev_dwarf in "Always Bump Downwards (2019)"

dev_dwarf — Tue, 19 Sep 2023 20:45:57 +0000

For the alignment parameter I agree.

New comment by dev_dwarf in "Always Bump Downwards (2019)"

dev_dwarf — Tue, 19 Sep 2023 18:51:29 +0000

Agreed. The question really is if you should demand the user to enforce that constraint on the size they pass to you, or if the function itself should signal an error in that case.

New comment by dev_dwarf in "Always Bump Downwards (2019)"

dev_dwarf — Tue, 19 Sep 2023 18:22:33 +0000

Nice. Seems to work for case you mentioned under my comment: https://godbolt.org/z/TYorcd8b6

New comment by dev_dwarf in "Always Bump Downwards (2019)"

dev_dwarf — Tue, 19 Sep 2023 18:03:52 +0000

Interesting point. I modified my example to test what you described. I had to play with the compilation flags to get the allocs to not be optimized out and to not panic when the integer overflow happens, but otherwise I didn't change the logic. I'm pretty sure my implementation is correctly handling the case you mention, evidenced by it returning a null pointer.

Link: https://godbolt.org/z/f1jGW6Pa3

Update: NVM, definitely not being handled correctly. https://godbolt.org/z/cMTe1o979

New comment by dev_dwarf in "Always Bump Downwards (2019)"

dev_dwarf — Tue, 19 Sep 2023 17:38:21 +0000

Ok, I get it now. It would add an extra ptr to the struct, but wouldn't be significant overhead.

I do wonder what benefit there is for you over just having two separate allocators, one for long term and one for short term. I imagine there could be benefits in very memory constrained scenarios.

New comment by dev_dwarf in "Always Bump Downwards (2019)"

dev_dwarf — Tue, 19 Sep 2023 17:09:34 +0000

This sounds like it would make the alloc logic much more complicated and branch-y, defeating the purpose of bumping down anyway, unless your implying some compile-time way to do this.

New comment by dev_dwarf in "Always Bump Downwards (2019)"

dev_dwarf — Tue, 19 Sep 2023 16:40:50 +0000

In the "bump up" version you could remove both the checked_add branches and replace them with a single check at the end, making the amount of branches the same.

Quick example: https://godbolt.org/z/rdv4qnrs8.

*edited to update the example, realized I messed up the comparison logic.