sfbea

7 ms·

1. 1.▲
   by sfbea 3y ago

   Apologies, the benchmark is fine. The reason the system allocator is faster than I expected is because Linux's slab allocator takes over for especially small allocation sizes, and it's terrifically fast. I'm changing up my ra
2. 2.▲
   by sfbea 3y ago

   Your results caught me off guard. Particularly, the (linux) system allocator is too fast. I think the simplicity of the benchmark (allocating and immediately deallocating) might be causing issues... perhaps unwanted optimizations? I'm
3. 3.▲
   by sfbea 3y ago

   Because the glibc allocator is designed for hosted systems with threading (uses pthreads) and memory management utilities not found on bare metal/other smaller platforms. You shouldn't be using Talc where MiMalloc, Jemalloc, the g
4. 4.▲
   by sfbea 3y ago

   Thanks for opening the issue. The allocator looks pretty interesting. Happy to try add it to the benchmarks, although doing apples-to-apples tests with its limitations might not be possible without some changes.
5. 5.▲
   by sfbea 3y ago

   [Author of talc] Glad this feature is proving useful. Seeing this makes me think I should implement a better-looking Display implementation than the default Debug impl though. Something for the next update ^-^
6. 6.▲
   Talc: A faster no_std and WASM allocator for Rust(github.com)

   2 points by sfbea 3y ago|0 comments