3 ms·

Awesome to see the contributed back their custom allocator that lets you allocate from a fixed block: https://github.com/dropbox/rust-alloc-no-stdlib https://gi

Awesome to see the contributed back their custom allocator that lets you allocate from a fixed block: https://github.com/dropbox/rust-alloc-no-stdlib https://github.com/dropbox/rust-alloc-no-stdlib Solid stuff from the looks of it.

gregwtmtno 10y ago
That's going to be really great for embedded projects.
saidajigumi 10y ago
Now I have a huge hankering to whip up a frame-based allocator, as used to be popular in game and graphics programming. For those unfamiliar, the idea is that you segregate allocation of memory objects of different sizes into their own fixed blocks. This provides a means to control memory fragmentation, and avoids hitting the typically slow system allocator with a lot of small allocations/deallocations. Fancy frame allocators would actually use a fairly standard malloc-style interface, but transparently place allocations of different sizes in their own regions. The allocator would internally use the slow system malloc to create and expand the fixed blocks it uses for its own allocations. During development, the frame allocator would be used to profile and optimize the actual object allocation sizes being made. E.g. sometimes it might make sense to pad some objects to consolidate the number of allocation-size regions. As the project progresses, the initial block allocations for each allocation size would be adjusted so that the system malloc was called very infrequently, usually only at application startup.
- Manishearth 10y ago
  It might be possible that jemalloc already does this? Rust uses it by default, and while I don't recall the specifics jemalloc does a bunch of things in userspace wrapped around malloc that make it better than malloc. Rust makes it easy to swap out the allocator too, so I'd love to see an allocator lib specifically focused on size management :)
  - Jweb_Guru 10y ago
    Yes, this is precisely how jemalloc works.
    - vvanders 10y ago
      Does jemalloc allow you to report telemetry and feed that back into the initial pool sizes? That's what makes the gamedev oriented allocators interesting. FWIW a "Frame allocator" was always a block of memory where malloc returned pointer into the block and advanced the pointer. At the end of rendering a frame you just reset the pointer to the start of the block. The downside is you need to guarantee that nothing in has a lifetime longer than a frame, something Rust should be good at :). I think what the GP is referring to is a pooling allocator that pools similar sized allocations.
      - Jweb_Guru 10y ago
        > Does jemalloc allow you to report telemetry and feed that back into the initial pool sizes? That's what makes the gamedev oriented allocators interesting. Not AFAIK. There are a lot of optimizations it's quite difficult to do with dynamic pool sizes, which aren't worthwhile in the general case.
    - rayiner 10y ago
      And OS X's magazine allocator, in addition to probably dozens of others. Segregated-fit allocators are probably the dominant method.

gregwtmtno 10y ago

That's going to be really great for embedded projects.

saidajigumi 10y ago

Now I have a huge hankering to whip up a frame-based allocator, as used to be popular in game and graphics programming. For those unfamiliar, the idea is that you segregate allocation of memory objects of different sizes into their own fixed blocks. This provides a means to control memory fragmentation, and avoids hitting the typically slow system allocator with a lot of small allocations/deallocations. Fancy frame allocators would actually use a fairly standard malloc-style interface, but transparently place allocations of different sizes in their own regions. The allocator would internally use the slow system malloc to create and expand the fixed blocks it uses for its own allocations. During development, the frame allocator would be used to profile and optimize the actual object allocation sizes being made. E.g. sometimes it might make sense to pad some objects to consolidate the number of allocation-size regions. As the project progresses, the initial block allocations for each allocation size would be adjusted so that the system malloc was called very infrequently, usually only at application startup.

Manishearth 10y ago
It might be possible that jemalloc already does this? Rust uses it by default, and while I don't recall the specifics jemalloc does a bunch of things in userspace wrapped around malloc that make it better than malloc. Rust makes it easy to swap out the allocator too, so I'd love to see an allocator lib specifically focused on size management :)
- Jweb_Guru 10y ago
  Yes, this is precisely how jemalloc works.
  - vvanders 10y ago
    Does jemalloc allow you to report telemetry and feed that back into the initial pool sizes? That's what makes the gamedev oriented allocators interesting. FWIW a "Frame allocator" was always a block of memory where malloc returned pointer into the block and advanced the pointer. At the end of rendering a frame you just reset the pointer to the start of the block. The downside is you need to guarantee that nothing in has a lifetime longer than a frame, something Rust should be good at :). I think what the GP is referring to is a pooling allocator that pools similar sized allocations.
    - Jweb_Guru 10y ago
      > Does jemalloc allow you to report telemetry and feed that back into the initial pool sizes? That's what makes the gamedev oriented allocators interesting. Not AFAIK. There are a lot of optimizations it's quite difficult to do with dynamic pool sizes, which aren't worthwhile in the general case.
  - rayiner 10y ago
    And OS X's magazine allocator, in addition to probably dozens of others. Segregated-fit allocators are probably the dominant method.